What About Accountability?

One of my favorite lines ever was delivered to me by a pretty senior guy I was working with a few years back. I was pretty new to this whole agile thing and was struggling to understand how I could ever run a predictable project without my Gaant chart and a weekly status report. He said to me… look Mike, agile is about uncertainty… you just get what you get when you get it.

That was a far cry from how my teams had been operating in the past. I was more in favor of the line… you do what I tell you to do when I tell you to do it. That had always worked in the past and I really couldn’t figure out why this situation was any different. In no way was I prepared to leave my project in the hands of a team that was unable to commit.

It’s been a few years since that conversation, but I hear that sentiment echoed by many of the teams I’ve worked with since. Somehow, some of us in the agile community think that agile is about getting started and coding until you are done… with little planning in between. What happened to commitment? What happened to accountability?

Like most things in life, the truth lies in between these two perspectives. Agile is designed to deal with uncertainty. When uncertainty is part of the equation, no amount of up front planning is going to give us a plan impervious to change. On the other hand, moving forward with no planning is irresponsible. The business is entitled to have some idea of what they are going to get… and when they are going to get it.

After all, they are the ones paying the bills.. right?

The bridge between chaos and predictability is velocity. Velocity measures the throughput of the team. In other words, how much work they are able to get done iteration over iteration. I should probably go into more detail on velocity here but I am assuming you probably have been introduced to the concept. Click here if you need more info.

As an agile project manager, I don’t really care about the units of velocity or even the actual number. That is specific to the team. What I do care about is that the number is useful. The team must be able to use that number to determine how much work they can do during the upcoming iteration. I also care about trends. Is the velocity increasing or decreasing. Have we centered around a specific number or is the metric varying widely iteration over iteration?

While ever increasing velocity is ideal… at a minimum I just need to be able to use past performance as an reliable indicator of future performance. It gives me insight into the health of the project.

Things brings me to my point about accountability.

An agile team is an empowered team. The team is empowered to do the estimate. The team can decide how much to bring into the iteration. The team can decide how the software is built. The team can decide how they organize themselves. The team can decide to break the work into tasks… they can decide not to. The team can decide who works on what.

The trade-off for all this empowerment is accountability. For agile to work, we need teams that can make and meet commitments. We need teams that are striving toward a stable velocity iteration over iteration. We need teams that value predictability. I am not going to tell the team what to do or how to do it, but they need to be able to deliver what they say they are going to deliver.

Period.

The team is accountable for knowing what they can do two weeks out… if we can’t commit two weeks out, we are screwed.