"His brand is bad: my brand is good." Isn't it well past time we got over that kind of thinking? I'll take a good idea from anywhere. So should you.
You’re interested in having projects that are more successful. At least you should be. You may well find great value in Scrum, or XP, or Lean, or Kanban, or DSDM, or whatever. I hope you do. Keep your eye on the ball, however. The point for you shouldn’t be to do Scrum or XP or whatever: it should be to do as many things as you can to be more successful, and as few as you can that get in the way. Those ideas can come from anywhere, and the better you and your team want to be, the wider the range of ideas you need to consider.
When you look for help or training, however, you find yourself dealing with companies and individuals. These people often have a preferred style of “Agile”, a preferred set of approaches and practices. Everyone is like that: it’s perfectly natural. However, these companies and individuals also have selling to do. They want you to buy their training, their coaching, their ideas. This, too, is natural.
Unfortunately for you, the selling can get in the way of your learning. Too often, the advertising and comments from these people try to tear down the other guy, to make their own offering look better. This is tragic, because there are good ideas everywhere. If their tearing down the other guy turns you off, as it does me, you may miss the good ideas that are lurking under the venom. If you buy into their story about the other guy, you may miss the good ideas that he has to offer.
Either way, you lose. Either way, the industry loses, because good ideas are what we need.
Your practice needs to be one of continual improvement. You’ll find yourself in places where some ideas will help, others will hurt, and very many seem to make no difference. If you choose your ideas from a larger pool of notions, you’re more likely to find one that helps.
One essential aspect of Agile is to reflect on what has gone before, and to adjust what we do to make things better. This is central to all those ideas about maintaining a constant rate of progress, to working together effectively, to delivering software in small increments, and so on.
In Scrum terms, the team must “inspect and adapt”.
[The point of this article is synthesis, adopting good ideas from wherever we find them. This particular idea happens to be very nicely expressed in Scrum. This is not a game of Scrum over Your Favorite Method: it's a game of Find an Acorn, Take It Home.]
What does “inspect and adapt” mean? It means we pay frequent attention to what is going on, and we look for ways to improve how we’re doing. We change our process. We change what we do. We adapt.
To adapt, we must choose what to try. Not all choices are equally good. Sometimes it’s not easy to tell. Often we have to try something, assess how it goes, then adapt again. Let’s look at an example.
Tasks Piling Up
Perhaps in our team we notice that there are always a bunch of important tasks that are not getting done. This isn’t good and we must fix it. What’s going on?
We’re not all the same: you are good at one kind of thing, and I’m good at another. It is natural for us to focus on our kind of work. Maybe you do the GUI work, and I do the database work. Dave over there does the testing.
In our planning meetings, we divide the stories or features up into what are we call “technical tasks”. You grab the GUI ones, I grab the database ones, Dave grabs the testing ones … when you and I are finally ready for him to test something. When all the programming tasks for a story are done, we integrate, Dave starts his testing tasks, finds problems, we fix them, and voila! story done!
Often, by which I mean almost always, it doesn’t quite work out that way. We get to the end of the iteration or Sprint or deadline, and we have lots of tasks done, but not many stories. Often I’ll see teams with 90 percent of their tasks done, but only twenty-five percent of the stories done, or even fewer. And it’s not just testing, either. We may find that we have lots of tasks done but many stories aren’t even ready to be tested!
We aren’t doing well, so we inspect: we have a retrospective. The cause of our problem may not be obvious. Some possible causes include:
- Maybe some technical tasks are necessary, but no one likes to do them. So people do other valuable things, but none of the stories get done because no one works on the nasty bits.
- Maybe we have lots of GUI changes, not much database. I get all "my work" done, but you can't get all "your work" done. This could happen on a week-to-week basis, or it could be generally true.
- Maybe we do things in different orders. You worked on A, B, then C. You completed A and B, and didn't quite get your C work done. Meanwhile, I worked on C, then B, then A, and didn't quite get my A work done. Two-thirds of the tasks are done, but only one story ever gets to Dave to be tested.
- Maybe you and I code like demons. We get "our part" of A and B and C done, and dump them on Dave. Dave does a little testing on each, but at the end of the Sprint, none of them are working well enough.
These causes may call for different solutions. We might need another GUI person. We might need to “swarm” on stories, all working on first one, then the next. We might need to put more focus on the nasty tasks, maybe even doing them first. We might need more testers. Depending on how well we have identified the problem, and how creative we are about solutions, we may do better, about the same, or worse.
We are trying things without knowing quite what will happen. This is natural: our world looks like this:
We start in that middle drab yellow area. We have imperfect knowledge of what’s around us, just guesses. Red is bad. Green is good. Yellow is about the same.
Heading off to the east, things get harder and harder. But if we stick with it a while, we come upon a lovely green area of improvement! If we head north instead, we have to slog but at least things don’t get worse. West is interesting: it looks good, but if continue for long we get in trouble.
How could that happen? Well, let’s consider Dave and the testing. We programmers code stuff up, get it to compile, check it a little, integrate it, and hand it to Dave, our tester. Dave tests away, files bugs, and we fix them. Meanwhile we code other things. We notice that Dave is overloaded, because many stories are “done but not tested”. Going west means “hire another tester”.
Too often, “hire another tester” patches over the issue but is not sustainable. In incremental development, we need to retest the software that has already been written, to be sure we didn’t break it in building newer features. So the testing load increases, increases, increases. So our “hire another tester” strategy results in needing more and more testers. This is simply not sustainable: as Chet Hendrickson puts it, sooner or later we run out of parking spaces for testers.
We need scouts. We need a better map.
Because we don’t have a map of the territory, we don’t know where we are, and we surely don’t know where to go. Other people have been here, though, and found ways to assess the path, and good paths to take. We need their help.
It might also be that we didn’t even recognize the right problem: it often happens that we are blind to things going on around us. A raw approach of “inspect and adapt” can miss the problem, or miss the solution, especially if we have to make everything up.
We need to borrow all the tools we can to assess the situation, and to get the best ideas possible to do when we hit our kind of terrain. In other words, we need good diagnosis skills to see what’s wrong, and we need good decision skills when we decide what to do. How well we do at those things depend on the quality of our tools and ideas. We need to be open to tools and ideas from anywhere!
Let’s look at alternative ideas about finding and diagnosing our task problem, and how to fix it:
Diagnosing the Problem
A “pure Scrum” approach might have the team drawing a “burn down” chart, showing tasks done versus time. Here’s a free example from Wikipedia:
This chart may well show regular progress toward completion, at some smooth rate. What it doesn’t show is that more and more of the tasks not done are testing tasks. Until a retrospective, the team might not even be aware of what’s happening! Even then, many of the team members may be saying “I got my part done”. This may be true, but to someone who wants features, not tasks, it’s not very helpful.
(In the Kate Oneal story, Slices, Kate says: “Features are what we’re trying to buy and features are how we measure our progress. If I came into your feature store today, planning to buy five features, there just wouldn’t be any on the shelf to buy. I’d have to go home without features, and your feature store would have to run for another week with no revenue …”. Kate has it right: part done is Not Done.)
The “official” Scrum answer isn’t helping us find this problem as well as it might, much less fix it. It turns out there is a good idea waiting to be borrowed from Kanban: the task board. Here’s one from Mike Cohn. Click the link for Mike’s full article.
To maintain a task board, the team puts all the tasks on cards, and creates a board showing all the important states that a task might be in. To Do is one. Done is another. Usually, on a task board, we don’t break out things like GUI or Database: instead, we’ll just have In Process. Aboard like this can help, a bit. We might notice that early in the Sprint, none of the testing tasks are In Process. We ask why, and the answer is “There isn’t anything to test yet. “ This seems plausible enough. Later on, all the testing is In Process, and all the GUI and Database tasks are moved to “Done”, or to “Waiting for Test” if we were clever enough to have that state.
Watching the task board, we have a chance to see what’s going on sooner. We might otherwise need to wait for a retrospective to have a chance to notice that we are blocking on testing.
A team that limits itself to one name brand, Scrum in this case, may not discover a task board, because they know that task boards are not part of “our method”. Nonetheless, the task board, which a team might hear about as part of some other discipline, perhaps Kanban, would be very helpful to them.
What we have noticed is that there is an idea, that we heard about from the Kanban side of things, that is useful. We don’t need to repudiate everything we know about whatever we were doing before–Scrum in this case–in order to pick up a good idea from Kanban. We don’t have to buy into a whole alternate worldview and start wearing Kanban t-shirts. We have work to do here. We’ll just build the darn task board.
And, if we’re wise, we’ll look more deeply into the knowledge space around ideas we find. The task board doesn’t stand alone–it may not even be sourced in Kanban. It’s used there because it works will with Kanban’s other ideas. What are they? How can they help us.
Same thing if we find a useful idea from Lean or any other realm of thought. Let’s appropriate it into our world … and let’s look more deeply at that world. Ideas are not fenced in. Ideas relate to each other. Let’s observe what we can, use what we can, and think about it all.
Synthesis: "Yes, And". Not "Either/Or".
For our projects to be successful, we need to draw from the whole world of ideas, not just from one little part of it. So when someone starts ranting about Scrum or Kanban or Lean or XP being “the way”, let’s not drop everything and adopt a new way of walkin’ and a new way of talkin’. Just look over there, find good ideas, and bring them into our own world.
Listen to all the gurus and vendors. Are they pushing Scrum, Lean, Kanban, or XP, or something else you don’t know all about? Great! Listen! There are good ideas there. But as they try to help you, are they also trying to tear down some other process? Don’t listen to that, that’s just their fear talking. Your success is about what you do, and you won’t get extra credit for sticking with just one brand. You’ll get extra credit for building the best process you can.
In the end, it’s about your world anyway. You’re here to be effective, not here to be Pure Scrum or Pure Lean or Pure Kanban. Effective. That’s the point.