Tag Archives: stand-ups

The Perfect Agile/Scrum Stand-up

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.

Want to rock out your Agile team? Here are the e-books for you.

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.

Tyranny of the Tools

As an agile coach, it’s been both a privilege and a pain to watch groups of extremely smart people blow themselves up.

The sad thing is that you can explain how this is all going to happen, you can plead with them not to head down this path, yet they do it anyway. What could have been a kick-ass team instead becomes a boring slog down old project management road.

And it all begins with automation.

That may sound strange. After all, we’re technologists, damn it. Our job is to take repetitive manual jobs and make the computers do them, right?

When I train people, we use post-its and index cards. We use painter’s tape on a wall. If we have a token for work that is to be performed — a story or a task — we jot a title down and plop it on the wall. This is called visual process control. It’s the result of decades of research and experimentation.

Or to put it bluntly, when my wife wants me to mow the lawn, she can ask, she can email, or she can make a bright red note and stick it on the refrigerator where I have to look at it every time I get a snack. Guess which one gets results. Make me look at it — even when I’m doing something else — and I’ll figure out a way to make it go away.

We find that things we look at — even in a casual, off-hand manner — are the things we think about. We also find that as we see things, we work on them in our mind in the background. We make a lot more progress letting our subconscious mind work on things while we’re busy with more important stuff, like technology development.

Still, there’s nothing like the gleam in a programmer’s eye the first time he sees a story/kanban board and physical risk/issue list. Note cards! On a wall! It’s like 1960 or something in here!

Then the gears start turning. Watching, I feel a terrible sadness, as if thousands of man-hours all screamed out at once, then were suddenly silenced.

There’s a reason why there are 40-thousand software implementations of Scrum/Agile on the web. Everybody who’s ever sat in a team room looking at the wall wanted to “fix” it.

Obviously a spreadsheet could handle all these lists and totaling up of things. And it’s not too hard to make a replica of a storyboard using some HTML5 and AJAX tools. Heck, given a few days, we could make a thing of beauty out of this — and make it easier to use too! Hell, I could be adding and completing stories on my iPhone! Taking some old, cranky, ad-hoc system using bubble gum and bailing wire and replacing it with a database and a decent front-end? This is the entire point of modern life! This is what we do! Why suffer?


So then — if we’re lucky — somebody does up a spreadsheet. Then everybody has to update the spreadsheet. Notice how the focus has moved. Instead of sitting in a room doing other things while the status of our project beckons us on the wall, we’re sitting in our cubicles filling out a spreadsheet once a day. The focus is on remembering to update a tool, not thinking about the status of our project. The tool starts running the project. It becomes the central source for finding out things. Not the people.

If we’re not lucky somebody writes a check for a more “powerful” tool. “Powerful” Agile tools usually have all sorts of fields, checkboxes, and whiz-bangs. They promise all kinds of benefits for teams — track your actual time! Track code changes against tasks! Roll up dozens of projects in a single bound!

So the job becomes completing the tool. Stand up? Well, that’s a reason to verify the tool has everything updated. Sprint closing? A detailed check to make sure the tool is in sync. Retrospective? A time to talk about updates to the tool. Do we need new fields? New reports?

It’s not us working the project. It’s us working the tool. Meanwhile, we still have the project to deliver. Agile becomes just another way to micro-manage and control.

Of course, I’m no Luddite. I love tools — as a means to communicate. There’s no better way to look at a team from a distance (when you can’t actually walk into their team room) than some sort of easily accessible online tool. So the team still works like it always has, using bubble gum and bailing wire, and each day somebody takes the stuff on the board and transfers it to a tool. The tool is never used except my remote workers as a way to visit the team room.

This is all just extreme fantasy on my part, of course. I’ve never seen a company that bought a tool that didn’t end up servicing the tool instead of actually being Agile. But I continue to hope.

There are people who love tools. These are the people who build them, sell them, or have a full-time job to maintain them. To them, tools are the answer to everything. How could you not love something that organizes so much data so easily? Weird thing — these people are also not the people who are actually doing the work.

When we create Agile teams, we create teams of real, live people. That means our control and communication systems must be built around the qualities and capabilities of people, not robots. We are doing much more in a team room than simply transferring abstract pieces of metadata around about a project. We are gaining a common emotional understanding of the problems and the players, getting a deep feeling for what might go wrong and what we need to worry about, adjusting our work patterns, our communication techniques, and our problem solving skills to this particular team, this particular problem, in this particular situation. There’s a hell of a lot of things that don’t appear on the walls — but that the walls remind us of. An Agile team isn’t a team that moves stories across a wall. It’s a team that looks each other in the eye and talks about things the Product Owner wants and how they’re going to give it to them. It’s a team that munches down on hot dogs and the conversation reminds somebody of something important so they reach up to add a new task on the wall. The stories, walls, and data are all just props to facilitate ubiquitous in-person human interaction. We take the ubiquitous in-person human interaction part out of it, we’ve killed the very thing we’re trying to improve.

If you’re looking for more balance and traction in your Agile team, take a look at the book I wrote on beign a ScrumMaster.

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.