Saturday, March 27, 2010

bad agile estimation

Depending on how you define the term, I have been on at least five and as many as seven agile software teams. Two were brilliant; two were poisonous; the rest were just flaky. A big part of the poison stems from not understanding how to do agile estimation.

This is part of a message that showed up on a mail list I lurk on:

I'm working with a team that does great work. They are skilled and
work well together.

They also average about 50% or less in meeting their sprint
commitments. And don't seem to mind.

"There's a lot to do we just didn't get to it all."
"We'll do that in the next sprint."
"Yeah, that's not working yet."

These are the kinds of statements during the sprint or in the retrospectives.

How do I help this team look at the problem to solve it, instead of
just living with it?

Since the list name has the word "Scrum" in it, I will assume this person is a Scrum Master.

The first misunderstanding here is to know that all estimations are wrong. But when we do estimation in an agile way, we find over time that as we come to share a consistent idea of what a "point" means, that our estimations will be consistently wrong in the same way. This allows us to plan with a high degree of accuracy.

So if you have a agile team that consistently estimates 20 points per sprint and achieves 10 points per sprint, then the capacity of the team is 10 points, and 10 points is the figure you need to use for planning purposes.

The term "meeting their sprint commitments" bothers me a lot. For one thing, insisting that a team complete more stories than the capacity of the team can support is a well-known recipe for technical debt and poor quality. For another thing, it's not "their" sprint commitments, it is our sprint commitments. Finally, I object to describing this situation as "a problem" for the team to look at.

Remember what the job of the Scrum Master is? The Scrum Master has only one job on the team: to remove impediments. If there is a business reason to achieve a consistent velocity of 15 points instead of 10 points, then the Scrum Master should examine the situation for impediments to remove, not try to force the team to meet some sort of imaginary capacity in order to satisfy the requirements of what is essentially an old-style Gantt chart.

Thursday, March 25, 2010

Artful Making

I never read business books, I mean I NEVER read business books. But after Marlena Compton read my chapter in Beautiful Testing, she recommended that I read Artful Making by Rob Austin and Lee Devin, subtitled "What Managers Need to Know About How Artists Work".

I've been writing about creating artistic software for some time now, but with a copyright of 2003, this book pre-dates my endeavors and I was surprised not to have heard of it.

Austin and Devin are professors at Harvard, Austin of business and software, Devin of theater. Early in the book they recount how they began the conversation that led to writing the book:

We were surprised to discover common patterns and structures in our separate domains... Some recent ideas and methods in software development, especially in the so-called "agile" community, seemed almost identical to theater methods. As this became more obvious, an idea dawned on business professor Rob: These artists are much better at this than we are. (emphasis NOT mine)

They cite four qualities of artful making: Release, Collaboration, Ensemble, and Play. They address all of these qualities well except for Ensemble, of which more in a moment...

They devote a significant portion of the book to distinguishing knowledge work from industrial work, which is very much worth reading. Then they assuage managers' concerns about security, uncertainty, and fiscal responsibility.

I have three criticisms of the book. One is based purely on my own personal biases, another is a gaping hole in their argument, one that does not get the attention it deserves. The third is more or less wishful thinking on my part.

First, this is not a book for practitioners. This is a book for executives who wander by the agile team room and wonder why it's so noisy and the floor is covered with index cards and there is a box of Lucky Charms on the table and the scrum master is wearing a viking hat. It does not tell you how to do artful making, it only tells you what artful making looks like.

Second, the book glosses over two very important points related to actual practice. The first one is explicit, in the conclusion, discussing the quality of Ensemble, they say "An ensemble at work on a project is a group that exhibits the quality of Ensemble". They admit the tautology, but they have very little to say about how to foster or even recognize the quality of Ensemble in a group. The second point that gets even less attention than "ensemble" is talent. It is impossible to succeed at artistic performance without a talented group of performers. I assume it is difficult for managers to acknowledge that their workers lack talent; and it is very difficult to define what makes one person talented and another not; but I found the lack of discussion of the talent of those doing the work somewhat disturbing.

Finally, and ultimately, the book does not go far enough. On page 40 there is a graphic with the title "Characteristics of Artful Making in Agile Software Development and Play Making" with a lot of common practices. What I would much rather see is a graph entitled "Artistic Performance" listing common practices of Theater, Dance, Music, and Software Development. I'm going to keep working on that graph.