Agile is not...

It was a great week at the Agile 2010 conference and it's very exciting to see that we're almost moving to an age of Agile pragmatism - what some will call post-modern Agile. It's often surprising to me how many misgivings and naivety gets attached to Agile. As Agile gets more and more mainstream, conferences such as Agile 2010 set the ground for the community to converge and discover best of breed approaches. I was fortunate to meet many interesting people and I must say the talks I went to, lived up to a very high standard as well. I've picked up a bunch of reflections from the conference and from those I want to quickly write up what I think Agile is absolutely not and I'd love to hear from you if you think I'm wrong.

Agile is not about wasteful process
We never do things for the sake of doing things. Every piece of work we do needs to seek out some value for the customer. As we get better at doing agile, we need to question ourselves about the value of pretty much everything we do. For example one of the biggest wastes I see are in agile iteration planning meetings (IPMs). In traditional IPMs, the entire team gets together and discusses the stories they'll play in the upcoming iteration. They then re-estimate all the stories, task them out individually and then place the individual tasks on the card wall. This takes ages for the meeting to get over. I question the value of reestimating stories -- if you don't have an estimate for your story then there's no reason why it should be in scope for the iteration. If you do have an estimate for the story and none of the assumptions from the time of the estimate have changed, then why reestimate?

I feel similarly about groups of people tasking out user stories - there's no better example of design by committee than this. Ideally we should be performing activities just-in-time, otherwise we just create inventory on our card walls. IMO the best time to task out a story is when a pair of developers picks it up from the card wall and starts to work on it.

In a similar manner, I feel that teams need to be a lot more efficient about retrospectives. Retrospectives are valuable when the team has meaningful discussions about the problems they're facing. However most retrospectives seem to spend most of their time just brainstorming issues. I can say that for many retrospectives I've facilitated - so I'm not free of blame! A team that really cares about continuous improvement needs to generate retrospective discussion items continuously. In the recent past, I've tried to initiate the brainstorm much ahead of the actual retrospective meeting, so the team has a prioritised list of issues they'd like to discuss. I've used tools like Google Wave (soon to be discontinued) and Google Moderator for this. This makes the retrospective meeting itself hugely productive and we get a lot more done by way of discussion.

These are just examples of waste we create on projects and that we can easily avoid -- I've generally observed that if I feel hugely uncomfortable about an activity or feel it's a 'necessary evil', there's definitely waste somewhere. That's a sign to refactor our team processes.

Agile is not about indiscipline
"Agile is about doing things that make our life simple. That doesn't mean that doing these things itself is easy." - Akash Bhalla, ThoughtWorker

I love that quote by my colleague Akash. We often mistake the fluidity of agile practices for a lack of discipline. As it turns out, Agile requires significantly more discipline and team commitment than traditional projects. The idea is a to practice good habits to an extreme. So just because we have user stories, doesn't mean that we don't track conversations related to them. User stories are a placeholder for conversations, but when those conversations do happen, we need to be diligent in tracking them. The card wall is everyone's responsibility, not just the project managers. It takes great discipline to be responsible for updating the status of your work on the card wall. That's our commitment to our team. In a similar manner Agile teams need to be fanatical about communication. Very often the lack of colocation becomes an excuse for not communicating frequently. Yet there are some of us who ensure that we communicate so frequently and with such a high degree of quality, that distribution almost never seems like an issue. This again needs discipline, because it means that apart from doing the easy part of communicating with our colocated team-mates, we also take the pain to communicate with those at a different site.

Agile is not about a lack of vision
Agile isn't all about eliciting a bunch of stories and delivering them in blind incremental fashion. We talk about delivering stories in the order of highest priority for the customer, but the fact is that a customer is making very poor guesses when looking at a flat list of user stories. Somewhere someone needs to spend time discovering the big picture of the project with the customer. This means seeing the project as a whole while iterating through development by delivering increments that slice through all streams of functionality. This is why Jeff Patton's story mapping approach is so popular for being able to envision your product. It tells the story of the application, though even that is only a step in the larger scheme of product discovery. The user experience of the application can't happen at a story level. Somewhere, someone needs to set the vision for the application's user experience so the entire team has a vision for what they're developing towards. As Jeff says, "Discovery and delivery are inseparable." Stories in isolation deliver no value - they deliver value as part of shippable software and the team needs to have a collective vision of what each shippable increment will do. As the product owner on ThoughtWorks University, this is what I set expectations for with my development team.

Agile shouldn't be about dogma
Last but not the least, agile is not about dogma. As I've expressed earlier agile is all about delivering value to the customer. We often become very dogmatic about practices when the practices really are only a means to an end. For example, I feel that standup meetings don't HAVE TO BE a standard practice on an Agile team, especially across distributed teams. If it's about communicating status, then the team's card wall should do that on a continuous basis. If the card wall isn't up-to-date, then that's a huge smell. If it's about removing blockers, then that should happen continuously as well - that's the reason why we sit at one table, in a team room. If it's about public commitment, then again, that should happen continuously by communicating across the table as often as we can. In a time where we can use tools like Yammer to create a continuous stream of information about a project, I tend to think of standups as ceremony for the sake of ceremony and IMO, an outdated practice.

In a similar manner, we need to overcome the dogma that for effective collaboration, you need colocation. For effective collaboration what you really need is the discipline and the passion to communicate. Folks like Keith Voos and Bill Krebs have provided empirical evidence to prove that we have reached a point where technology can help bridge geographical distances. So, the next time we feel we're being prescriptive with our process, we need to think again and ask ourselves if we're going through a practice only because that's the way we did it in the past. The world is evolving and so should Agile.

---

I'm no Agile guru. In fact, at the conference I introduced myself as an Agile nobody. I do however have strong views about practicing Agile effectively through my association with ThoughtWorks in India and with ThoughtWorks University. I may be wrong in what I've said on the blog and one way or the other, I'd love to hear your thoughts. Do let me know by dropping a comment or two on this post.