I was working with an Agile program doing planning last week, and we were all busy creating our release plans and beginning to scope out our product backlog. Every team was using big visible indicators of work, usually post-it notes and blotter paper.
Except one. As we started socializing our work, talking about dependencies and identifying opportunities to refactor, one team came up and presented their backlog on the projector using a spreadsheet. Everybody stopped while one person went down each line, item-by-item, for 100 items.
This kind of meeting, where somebody grabs a projector and folks stare at a wall for hours, is one of my pet peeves. But these guys were new and I saw it as an opportunity to coach them later on. I timeboxed their presentation to limit the damage, then we all managed to complete.
At the end of the day, when we were getting feedback, I got quite a surprise! The group who didn’t physically work with their backlog thought that all this post-it and physical stuff was so much rework. Why not everybody just complete their work ahead of time and we could all show it on a projector? Ten teams, all with hundreds of items on spreadsheets to go down line by line, all day long.
They also thought the 3 hours we spent doing the same work took too long! Go figure.
I had to come up with a respectful way to tell them that this is a bad idea.
“You know, the way you think about backlogs, a big hunk of data to be created and managed, is not actually the way they work. The wonderful skills you have as a programmer or analyst are actually not applicable here. The goal here is not to work with the data, it’s to work with what is between your ears. Your brain. We are optimizing the transfer of information using humans, not computers. That means that there’s a whole new set of rules to deal with.”
I don’t think they got it, but most of the other teams knew what was going on and had my back. So it worked out.
But there is a teachable moment here. As technologists we are used to moving data around on machines. This is a completely different universe from optimizing the behavior of people to understand and attack a problem. People are not computers.
There are a lot of little consequences from this. For instance, people can only compare so many items at a time, so we usually limit comparisons to 2 or 3 items. People can only remember so many items in a meeting, so we limit our lists to 20 or 30 items. People read more by body language than by words, so we put them physically together while planning. People are more likely to make good tough decisions early in the day, before they reach “decision fatigue”, so we front-load the work. And so on.
Some of this stuff, of course, is unproven pscyho-babble. Some is not. What the Agile community has been doing is empirically testing these various theories to see which ones work well and which ones do not. As practitioners we have a big list of “games” and principles the games are built on. We add some in, see how the team reacts, then adapt. That’s why Agile is different from other methodologies. Agile is a marketing term around best practices for iterative and incremental development. That vagueness is its strength, but it can also drive newbies nuts. It is entirely different from the kind of yes-no, off-on boolean logic most of us deal with in our jobs everyday.
Or to paraphrase a famous presidential campaign, it’s the people, stupid.
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