When people first arrive in Agile/Scrum, one of the first things they ask is “Doesn’t Agile mean we don’t need requirements?” followed by a close second of “Scrum is too rigid. We definitely don’t want something so restricting”
It seems like you’re either a cowboy or a Nazi. There are no in-betweens.
It’s like this: Agile is all about dynamic process tailoring. That means, yes, that teams control the degree of paperwork and process they need to accomplish. But it’s also like this: there are some “recipes” that the community has found over and over again that work. You’d be a complete fool to ignore them.
What happens with high-performing teams is that they have very few things they do that are defined and reproducible. But for those very few things, they are very disciplined. Being Agile, strangely enough, means being extremely disciplined about a very few things and leaving the rest of the details to make up as you go along.
The crux of all this ambivalence is, in my opinion, the stand-up. Since nothing proves a point like actually seeing it, in the video that follows, note the following things:
- It happens quickly. Stand-ups are high-energy. People are standing-up, moving around. Nobody is sitting in their chair with their head in their notebook or cellphone.
- Nobody is reporting to anybody. This isn’t a status report. There are no questions and answers.
- We point at the things we are doing. It’s all about Visual Process Control. That means the things you are doing are publicly visible, they represent status at any time, and they are manipulable.
- Decisions are made after the stand-up. The stand-up is a game of identifying tokens: what has happened, what is going to happen, what obstacles individuals are facing. After the tokens are all identified, the “real” work begins: the tokens are resolved. Technical discussions and ad-hoc discussions begin.
- There is no Project Manager. If you can look at a stand-up and find a project manager, it’s a bad stand-up. Stand-ups are about team commitments, risks, and issues. Not roles.
- Everybody is in the same room. Body language and other non-verbal communication channels count. A lot. Everybody isn’t standing around talking into a PolyCom.
- It’s scalable. If done correctly, team stand-ups scale very easily. A manager could attend several stand-ups each day, get a close-up view of how the entre program is going, and still have most of the day free for coordination and planning activities.
- The team is small. You can’t have an Agile team with 30 people on it. Do not do this. It does not work.
- The story board is not that complicated. This is about the limit of complexity for a story board that I am comfortable with. Past this is drudgery. If your storyboard has the colors of a Christmas tree and a sufficient number of post-its to draw a 40-foot picture of Godzilla, you’re over-complicating things. Stop that.
- It’s a problem-solving exercise. Immediately after the stand-up is over, the Product Owner talks to anybody with questions or problems and works them out.
- We work out problems visually. Notice how they pull the story/task over to the flip-pad and work through the problem? See how the options and structures are all presented visually? Here’s a tip: doodling or drawing structures and flow on paper has about a hundred times more effectiveness that trying to write it down or vocally discuss it. Model things.
- Big Picture is not present. Nobody is looking at long-range issues. Nobody is talking about things happening 4 months from now. Nobody is tapping their foot and asking “are you through yet?” The entire thing works on local optimization. That means that inside of sprints teams locally optimize to finish their commitments. It’s only at the boundary of sprints — demos, retros, and IPAs — that the big picture is important.
Finally, notice it doesn’t match the video. The perfect Agile/Scrum stand-up demonstration does not exist. Teams are different. Everybody has to adapt. As I said in the beginning, Agile is all about adapting. The point is to try things the “best” way — as the community has determined them — and then adapt for your particular situation. That way you don’t miss out on anything, and you also have good reasons for the way you’ve adapted.If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.