This was the second year at Agile that Jim York and I collaborated on an Improv-led session.  In our work as coaches and trainers we have found the improv mindset to be an essential tool for Scrum teams, moving them swiftly towards deep and productive collaboration, without fear.

The session has been written up for the Agile2008 site and is available to download as a PDF from here: Operating on the Creative Edge — PDF.  In the document we describe many (not all) of the exercises we ran, and describe briefly the purpose of the work.

Both Jim and I have trained with the Improv artist and actor Matt Smith.  Here is an extract from Matt’s web site, where the parallels with what we are asking from Scrum team members can clearly be seen.

“I studied improvisation so that I could become funny on stage in front of people. What I learned from the training was quite different. I learned to: listen, honor, be accountable, be positive, move things forward, stay present, reincorporate, empathize, reflect.  And I learned to surrender: my agenda, negativity, judgment, control, anticipation, pre-determinate listening.  More than readying me for the stage, it improved my life!”

If you live on the NW coast of the USA I highly recommend you attend one of Matt’s workshops.  They are mind-altering.

_____________

A word of warning: although the PDF document may be of interest to many, it is highly advisable you do not attempt to run the exercises described unless you have yourself experienced them.  Words are too easy to misinterpret.  Only by being in these exercises can you truly comprehend them.  If you are interested in introducing these ideas to your organization contact Jim or me directly, or better yet contact Matt Smith.

A book that does an excellent job of discussing this shift of thinking and behaving in the business world, and one I recommend to upper managers and change agents in the organizations I work with, is Surfing the Edge of Chaos, by Pascale, et al.   The authors offer advice to business leaders of how to turn their companies into “agile and adaptable ‘living systems’ that achieve long-term vitality and sustainability in a swiftly evolving environment”.  The book is peppered with real-life examples of major business entities (e.g. Shell and Sears) who have harnessed complex, adaptive behaviors for profit and employee happiness.

One organization recently founded to promote these ideas and practices in the field of healthcare (but since expanded to other fields) is the Plexus Institute.  The words below, extracted from the Plexus Institute’s web site, offer an overview of this new way of being.

” […] Whatever their value in the past, mechanistic principles alone are inadequate for the complexity and change we face today. Clearly, we need a new way of looking at work and organizations of all types.

Such a world-view has in fact emerged; it is known as complexity science. At its core, this intellectual revolution is transforming our understanding of life, its structures, dynamics and its care, while providing new principles for making sense of what is most fundamental in our lives: our relationships with other people and our environment.

Such understandings give us powerful new ways of thinking about and acting on issues which span human concern, from such seemingly disparate domains as ecological preservation, childhood education and executive leadership. As such, it is relevant to everyone. Already, some business, community and government leaders are embracing the ideas emerging from complexity science, but they remain a minority.

[…]  What is complexity science? Very simply, it is science’s most recent attempt to explain how order and novelty emerge in the world. (As such it is the intellectual successor to systems theory and chaos theory.) The traditional view of the natural world was made up of machine-like entities that you could understand by taking them apart and examining the components.

Much has been learned about nature by this approach. But the vast majority of nature is not amenable to being understood in this way, because most of nature is made up of what complexity scientists call non-linear, complex adaptive systems. Such systems are created by a number of diverse and independent agents that are constantly changing and interacting with each other. In complex adaptive systems, a study of the parts surely produces an incomplete understanding of the whole. Examples of these systems include ant colonies, ecosystems, and human organizations.

It’s worth making a distinction here between complex and complicated. An internal combustion engine is complicated, with many different components. But it is not complex because knowing what the parts are and how they function permits you to know what the system as a whole does.

The defining feature of complex adaptive systems is emergence: the order that emerges through the interactions of components in complex systems is “greater than - and different from - the sum of the parts,” to use a familiar phrase. Complex systems therefore have a large degree of unpredictability. But more than that, the emergent collective order in turn influences the behavior, or interactions, of the parts. Feedback loops exist at every level. Such systems are constantly adapting and evolving.

[There are] two important properties of complex systems. First, that complexity arises from a deep simplicity. Second, that the order of the whole system flows from distributed control, that is from interactions among individuals, not from central control. In organizations, one way to think about this phenomenon, called self-organization, is to remember what happens in times of crisis. People take on tasks where they see the need, often breaking the normal rules of operation, often doing things they don’t normally do. People achieve amazing feats, which they often rank among the most rewarding experiences of their work lives. Leaders often find it difficult to give up a measure of control, because it is part of their identity as leaders. But those who do find that their people tap into their latent talent, and do far more than they, or anyone, ever imagined. This is the power of a complexity perspective in organizations.

This perspective does not say that leaders simply have to sit back, give up control, and wait for unpredictable miracles. Instead, it argues that leaders must help create conditions that unleash the talent distributed among their people. It is a model of leader as cultivator rather than controller.

[…]  One final property of complex adaptive systems that is relevant to organizations is as follows: when the interactions among the agents are enhanced, the adaptability and creativity of the system is also enhanced.

In human organizations, this translates to agents being people, and interactions being relationships generated by conversations. Enhancing people’s ability to interact and to develop enhances the adaptability of the organization. Complexity scientists have also observed that a diversity of agents in the system serves to enhance this adaptability and creativity even further. In organizations, this means inviting a diversity of experience and perspectives.”

The full article can be read here: The Plexus Story.

My intention here (using mostly borrowed words) is to show that Scrum is a naturally evolving way of thinking and behaving.  It has a solid theoretical and scientific foundation and is at the cutting edge of current systems thinking.  As such, Scrum needs to be taken very seriously by any software company hoping to stay in business and compete in a world that is changing faster than ever before.  Mechanics cannot keep up; heavy-handed, hierarchical, command-driven organizations are the lumbering dinosaurs of the business world, grinding innovation to a halt.  To thrive today we need the speed of the human mind, the immediacy of eye contact and physical touch, and the creativity of the collaborative spirit, unleashed through trust and self-organization.

There is something about the approach that disturbs me.  Jeff uses terms like “forceful and mandatory” to describe his preferred Scrum implementations.  He uses the term compliance.  On the Scrum Trainers list he throws out the term “wishy-washy” to disregard current Scrum implementations.  It is difficult to speak up in opposition to the founder of a movement, especially when the espoused ideas appear so compelling.  Jeff Sutherland is smart, experienced and well respected, but on this issue I feel a sense of discomfort, so here goes…  Is “hyper-productive” what we are seeking?  What does that mean anyway?  It sounds silver, and bullet-shaped.

What Jeff Sutherland and Scott Downey are describing is forced compliance to a process.  Is that what Scrum is?  I didn’t think so.  It isn’t what I seek.  It isn’t why I joined this gang.  What happened to empowerment, to choice, to innovation, to collaboration?  Is all of that now discarded as wishy-washy?  Is it relegated to the dreaded realm of touchy-feely… or worse, reserved for the exclusive use of these “hyper-productive” teams endorsed by the Scrum elite?  What does this mean?

I fear the concept of hyper-productivity, represented by Shock Therapy, will run rough-shod over the essential human values of enjoyment and passion, and the empowering feeling of self-organization, fueled by trust.  And it concerns me.

I am not doing what I do for the sake of hyper-productivity, I am doing it for the sake of freedom, for the sake of advocacy, for a sense of ownership and a sense of self.  I guess it could be argued that Scott’s approach leads to such empowerment, over time.  I have heard that argument before, years and years ago: happy people don’t produce good software, the act of producing good software makes people happy.  The idea has merit, on the surface, but I didn’t believe it then, and I don’t believe it now.  I have not seen it bear fruit, and I think it is a temporary solution. A quick fix.  People are worth more than compliance to solutions.

My feeling, my core belief, is that change has to begin within the individual for it to have any true meaning and long-term sustainability, for it to really matter.  Trouble is, I have no metrics to prove this.  Jeff and Scott have metrics.  My gut tells me they are questionable, but I am hard pushed to find a coherent argument to sustain an opposing viewpoint.  Process metrics are simple; people metrics (ones that represent the real truth of feeling) are harder to uncover.

I could be completely wrong here, but I don’t feel like standing by and letting “Shock Therapy” be the default way forward for Scrum.  Empathy and compassion as agents of change need an advocate too.  I’ll be that advocate.

Shock Therapy was used to “cure” drug addicts between the 1940’s and 1980’s.  It had limited success.  Today, a gentler, more spiritual approach is followed.  It takes longer, but yields a more effective, and longer-term recovery.  It is altogether kinder.

Based on what I have read, I would not hire Scott Downey to transform an organization.  I would look to someone with a more human and less mechanical heart.   Change is so vital to this industry, it cannot possibly be represented by process alone.

This session, a mashup of Scrum, Artful Making and Project Runway was an attempt to see how people would work in a non-software environment given some vague, but hopefully enthusiastic requirements.  I believe that a Scrum approach to any new product development is natural, and even inevitable.  It is predefined process that prevents us following a natural, meandering path to an innovative and imaginative solution.  It is the urge to be in control and a fear of failure that forces us to demand answers up front rather than allowing a solution to unfold, organically.  Having software developers and project managers create fashion clothing was a way to avoid the old ways of thinking.  This was new territory.

To begin the session I described the four Artful Making principles of Release, Collaboration, Ensemble and Play and summarized these as big posters on the wall.   I then introduced the Stacey Diagram, focusing on the fact that the project we were about to embark on existed in the complex space, i.e. the requirements were sketchy and we were working with new technology (needles, thread, sewing machines, fabric…).  I briefly outlined the principles of an empirical process and stressed the importance of reflection to inspect and adapt.  We set an iteration time of thirty minutes and then began the projects.

There were two teams of 6/7 people.  Each team had two customers, Alan and Stacia with Team A and Samira and Kate with Team B.  Team A were to make two outfits, one for each customer, while Team B focused on a single outfit for Samira.  Kate’s role became that of an advisor and customer consultant on the empirical process, as Samira had limited experience of this way of working.

Each team was obliged to use the Agile2008 conference tee shirt as part of their outfit.  There were no other boundaries.

As much as possible I did not enforce any Scrum practices, but let the teams find their own way.  Naturally, this being Agile2008, most participants had some experience of this way of working, but even so it came to light that this was tough.  The empirical approach is natural, but it requires discipline to make it optimal.  Lyssa Adkins has written about her experience of being on one of the teams on her blog, cricketwing.

Of course, the customers changed their minds frequently, rejected ideas, came up with new ones and in collaboration with the teams ultimately came up with solutions that were both practical and satisfying.  By the end of the session we did indeed have three outfits.  Stacia’s one was a little rushed at the end and probably lacked some quality, but the other two were entirely satisfactory.  Samira’s off-the-shoulder dress and accessories, made from four conference and corporate tee-shirts was probably the most successful outfit.  Samira wore it to the banquet on the final day, to many a complimentary comment.

Enjoy the pictures — and click to view the full size versions.

__________________

Scale Back: Small is Beautiful.  The full description/original submission can be seen on the Agile2008 submissions board, here.  The intent of this session was to have an antidote to all the “let’s scale agile up to the enterprise” submissions (there were many).  In all the bigger-is-better discussions an essential question was not being asked: Why?  If Agile is about simplifying software process, maybe making it bigger is the wrong approach.  How about we make it smaller?  This is our starting point for this session.

I chose the 30-minute time slot for this session, as it was the shortest available session slot.  If small really is beautiful, let’s put out money where our mouth is.  My intention for this session was to come up with The Proclamation of Small Ideas, a statement created collaboratively by all those present.  I expected maybe a dozen people to show.

In actuality we had about 30-35 people attend this session.  Can consensus work with such a large group in such a small space of time?  Well, surprisingly, yes.  And this is how.

Session Mechanics

1. Introduction   We are trying to scale Agile up, without first optimizing it at the single-team level.  This is a big mistake.  We end up with watered down, half-hearted Agile.  It would seem that our desire to complicate things and define futures that show how smart we are, overrides the common sense, keep-it-simple principles required by this new paradigm.  Let’s focus back on making one team the absolute best it can be, and then let scaling happen by itself, through emergence rather than by upfront design.  I wrote a blog post about this a few months previously:  Scaling Scrum: The Alcoholic Perspective.

2. Discovery — The Game “35”  Each person has an index card.  On the card they write down a single statement to express why keeping Agile small is important to them.  Once all have written we get on our feet (getting on our feet is a magical part of any workshop… it is an awakening).  Mill around the room, swapping cards as fast as you can until all the cards are effectively mixed up.  Then at the command of the facilitator, stop.  Find a partner (note: this exercise requires an even number of people; if you are the facilitator either join in or ask someone to drop out to make the number an even one).  In your pairs read the two cards you have and come to an agreement about which best expresses your own values.  Score the cards using a total of 7 points.  In other words, divide seven between the two cards, with the higher number going to the card that best expresses your values.  The division will either be 7/0, 6/1, 5/2 or 4/3.  There are no half values.  Write the appropriate number on the back of each card.  Once all pairs have done this, mill around again, swapping cards and on the “stop” command find a new partner.  Repeat this five times.  The highest score any card could receive is 35.  Hence the name.  After five rounds, have people add up the total  of the numbers on the back of the cards.  Then count down from 35.  We selected the top four cards and shared the contents with everyone.  This leads us into the next phase.

Writing The Proclamation  The room was naturally divided into five tables of around 6-7 persons at each.  In these groups, take the top four statements (which I have now transcribed to a whiteboard for visibility) and create a single statement that expresses these values.  Write this on an index card.  After 3 minutes, stop.  Pass your card to the next table (rotate all cards).  New table: rewrite the statement, fine-tuning and eliminating waste.  I’d have liked to have done this four times, but we were running out of time.  Instead we stopped after one pass, and a spokesperson read out the edited statement.  Then we voted.  Each table read the statement and each person (with eyes closed) raised their hand if it expressed their values.  Each person could vote multiple times.  I tallied the votes, and one of the five statements was a clear winner.  The Proclamation of Small Ideas: this was it…

keep agile small
because passionate
collaborative individuals
produce simple results

Everyone in the room agreed that this statement captured the intent of their own feelings.  There was consensus.  Each person copied the statement out twice, on separate index cards and committed to giving one away to a conference attendee who was not present.  Spread the passion.  The session took 30 minutes and 37 seconds.  James Lyndsay graciously gave us those 37 seconds from his part of the session.

It was encouraging to me how many people showed up to the workshop… how many had a genuine concern that Agile was becoming bloated.  I had a number of interesting conversations following this session, and I hope some of the participants will read this and add their thoughts.

Next up… Fashion Cycle: Agile 2008 meets Project Runway.

It is interesting how the phrase “the real world” is used almost as a weapon to wield against the idealist: yes, it is all very well to say that teams should be co- located but that is not how people actually work in the real world. We seem to forget that reality is not something that is imposed on us. Reality isn’t just there; we create it. The phrase “the real world” is akin to the phrase “it’s just the way we do things around here”. Both should be challenged with a healthy dose of skepticism and a steady barrage of “why” questions. Just because it is, doesn’t mean it has to be.

Distributed teams are not teams; they are at best a collection of people who communicate regularly. But communication is not collaboration; it is a poor relation, weak and insipid in comparison. A distributed team cannot create the kind of energy that comes from human eye contact, from shared spontaneous laughter, from physical touch. True collaboration requires all five senses, not just a voice over the telephone, or a second-hand video image. And email… don’t even go there. Distributed teams require managers, and thus can never be truly self-organizing. Time differences and delayed response times inevitably slow down conversation, hold up decisions and ultimately cripple agility. Distributed teams can never be truly Agile. So let’s stop pretending.

Step back for a moment, and rather than assume we have to take Scrum to anyone who asks for it, let’s look at an alternative. Try a thought experiment: if all Scrum coaches refused to work with organizations who insist on having distributed teams, what would happen? My guess is that those companies would all go under very soon, proving the ridiculousness of the distributed team model. These companies are requesting Scrum exactly because they are struggling, yet they are rarely willing to remodel themselves in an Agile way. They want it all: cheap labor and high yield. Not so different from third world child labor industries. Maybe we should simply say no. No, we are not going to support this madness. Force-fitting Scrum into such environments may keep them afloat a little longer, but ultimately they are headed for failure. The model is ugly, painful and undignified, it undermines human relationships and is certainly sub-optimal.

Scrum believes in fast failure: “Scrum will help you fail in thirty days or less”, said Ken Schwaber in his oft-quoted elevator conversation. Our job as Agilists should be to speed up the failure of the distributed team model, not to prolong its agony. Once the organizations that support it are dead, we can begin building new kinds of companies, democratic companies modeled on true Agile principles: ideal ones, not half-hearted ones. The sooner that happens the better.

To whet your appetite here are a few articles about companies that embrace co-location, self-organization and democracy:

Kind of like Kindergarten — Menlo Innovations

Engines of Democracy — The General Electric plant in Durham, NC

Who’s in charge here? No one — Semco, Brazil

Everybody wants to scale Scrum. It seems like one of the first questions asked on many CSM courses. Day one, 11am: Yes, but how can I make this work with 5,000 people across 27 world-wide locations? Well, perhaps you can begin by listening for the next 1.8 days.

Too many people want quick solutions to hugely complex problems before understanding the basics. Learn about Scrum, I mean really learn, before jumping to impossible scenarios and expecting Scrum to have pat answers. Software engineers are bright people, sometimes too bright. We praise those who can leap ahead with their thinking, who skip steps; we look to them as the smartest of us all. But Scrum does not benefit from step-skipping, it benefits more from a one-foot-in-front-of the-other approach, embodying learning along the way.

I believe Scrum to be self-scaling. By that, I mean that Scrum contains all the elements required for handling complexity: self-organization, empiricism, prioritization and timeboxing. Scaling Scrum does not benefit from interference, but rather from support and understanding. Develop a deep and thorough appreciation of the Scrum principles and practices. This will allow you (as manager, director, Scrum Master) to step back and allow scaling to happen according to Scrum principles, rather than to fit your own perceived patterns of what is right. Don’t attempt to influence the change, but gently guide it to meet specific organizational and team needs. In other words, get out of the way.

There is an interesting parallel for self-organized scaling from the world of self-help groups that I’d like to briefly introduce here. In 1935 Bill Wilson and Dr Bob Smith formed a group in Akron, Ohio to help alcoholics like themselves recover from the obsession, or disease of alcoholism. From this small, self-organized group (there were no therapists, counselors or leaders) grew an entire, world-wide movement now known as Alcoholics Anonymous. How did this happen? How were a bunch of drunks able to apply the principles of self-organized scaling to their movement without someone being in charge? The answer is that the solution emerged slowly and according to need.

Bill Wilson eventually moved back to New York, and being unable to attend meetings of his newly formed Akron group he began a second, local group. This group grew too, and a similar thing happened. Groups formed from a common beginning according to the needs (usually geographical) of the members. Groups dissolved too, when the need was no longer there. Eventually someone had the idea that a set of guiding principles would be useful to give an overall sense of cohesion to the disparate groups and thus the “12 Traditions” of AA were established by a loose collective of people from many different groups. Among the guiding principles in these “traditions” are the following:

• Our leaders are but trusted servants; they do not govern
• Each group should be autonomous except in matters affecting other groups or AA as a whole
• Each group has but one primary purpose — to carry its message to the alcoholic who still suffers

It will easily be seen how such principles can apply to the scaling of Scrum:

• Our leaders are but trusted servants; they do not govern (no change there)
• Each Team should be autonomous except in matters affecting other Teams or the organization as a whole.
• Each Team has but one primary purpose — to build an increment every iteration and deliver it to the Product Owner (who is possibly suffering!)

There are other AA principles that could perhaps be applied to the nurturing and development of individuals or to the design of an Agile organization. The full text of the 12 Traditions can be seen here.

It may be argued that this example is too far removed from the world of software to be useful. Perhaps you are thinking that recovering alcoholics are not responsible for deadlines and deliveries. But think again. Without AA many of those alcoholics would be dead. Avoiding death is probably the best deadline of all. There is certainly a sense of urgency that permeates AA meetings. It is a last refuge for many. This is it: we recover together or we die alone. Don’t be too quick to dismiss the parallel here on the argument of non-relevance. As they say in the rooms of AA: look for the similarities, not the differences.

Subscribe to this blog

I think that [Agile Software Development with Scrum] is just as relevant today as it was when Ken wrote it. We still use 30 day Sprints, an Excel spreadsheet for burndown charts, track in hours and estimate in Ideal Developer days. And it works just fine thank you.

I think I understand why people feel the need to embellish Scrum: it’s just too simple. However, it doesn’t need embellishment, and keeping focused on the basics is probably the key to success.

There are two ways of “embellishing” Scrum; one is to add things, the other is to remove things.  Both need to be handled with care.  I tend to agree that the simplicity of Scrum is its strength and I’m wary when people say we need to add roles, or define the process more clearly.

One the other hand I am all for seeking out and removing waste, so if I find that certain practices in “original” Scrum don’t add value I will not use them. I found that with hours-tracking.  There are other ways to know if the work is on track for a sprint, simpler ways that require no tracking at all from developers.  Anything that allows a developer to be free to create seems like a valuable thing.  The responsibility of updating work is still there, the commitment to completion is still there, it is just much simpler.

The danger of this “stripping away” approach is that people begin to think along the lines of, Oh the daily Scrum doesn’t add value it’s just a waste of time, let’s drop it.  Which is a very, very bad idea.  So when can a Scrum practice be safely dropped?  I think the simple answer is: when it is not being dropped to mask a dysfunction.  Of course, when people say let’s drop this or that Scrum practice they are not aware that their actions are hiding the real issues.  This is where experience comes into it.  An experienced Scrum practitioner can assess the value of a particular practice, weigh it against any downside, such as loss of transparency, and make an informed choice.  (Every choice of course can be revisited at the next retrospective.)

There is also a big difference between dropping Scrum practices and breaking the Scrum framework, and understanding that difference is also something that comes with experience.  When we remove a practice we can safely do so if we retain the value that practice was providing.  As an example, just dropping IDD and not estimating would be unwise, but replacing it with story points is smart; it retains the value that estimation provides and brings better opportunity for dialog along with it.

I general I am all in favour of simplifying any process, and opposed to making things more complex, or worse, more complicated.  Adding things to Scrum usually results in complication.  Removing things can result in simplicity, but only if it is done wisely and with a good understanding of Scrum principles and values, otherwise the result will be confusion and a return to whatever was in place before Scrum came along (which we can safely assume was not good).

Just a few late-night thoughts, before I head off to New York again.

Dear Jim,

No More Self-Organizing Teams by Jim Highsmith
Cutter Consortium article, 9/13/2007

I read this article with interest. I am an anarchist at heart, and yes, I believe in grass-roots revolution as a way to fundamentally change the way we think about building software. I use my anarchistic tendencies to help people to reconceive ideas. It is a powerfull and energizing tool.

Anarchism¹ has had a useful role to play in the history of democracy in the world. I think it also has (i.e. has had and continues to have) a useful role to play in the Agile space. Let’s not discard it so quickly. Jesus of Nazareth was an anarchist. So was Gandhi. Both initiated great change.

The danger of your article, is that managers will jump on it to utterly dismiss the concept of self-organization. Look at the title of the article, look at the name you have in the Agile space. Many people will not even read the words beyond the first sentence… “I’ve been thinking recently that the term ’self-organizing’ has outlived its usefulness in the agile community and needs to be replaced”. That would be tragic.

The way you used the duck-suit analogy (i.e. calling anarchism self-organizing is like putting a duck-suit on a chicken) was offensive and dismissive of a great number of good people creating magic in staid, crippled, half-dead corporations by injecting the passion of self-organization. Please be careful with your words; they carry a lot of weight. Self-organization may well be misunderstood, and I agree with you that it often is, but that is not cause to dismiss it out of hand. Seek to enlighten rather than to appease.

Self-organization is a key principle of Agile. The concept is utterly essential to changing the way people in the software industry think about their value system, and about how they work together across organizational tiers.

Good self-organization does not exclude leadership, and does not, as you imply only allow for situational leadership. The need for a leader, and more importantly the type of leader, should emerge from the need of the team, not be imposed ahead of time, or indeed at any time. People outside of the team are less well positioned to know what the team requires. Teams should request leaders. Well-functioning self-organized teams do that. I have seen it. It is healthy behavior.

I don’t think I fundamentally disagree with your sentiment: leaders drive teams to success, I was just saddened by the way you said it, and how inevitably it will be (mis)interpreted.

Sincerely,
Tobias

¹ I use the term anarchism as defined by the American Heritage College Dictionary: “Rejection of all forms of coercive control and authority” and by other non-inflammatory sources, many of which can be found in the Wikipedia entry for anarchism. In particular this quote by L. Susan Brown helps clarify the true meaning of the idea: “While the popular understanding of anarchism is of a violent, anti-State movement, anarchism is a much more subtle and nuanced tradition then a simple opposition to government power. Anarchists oppose the idea that power and domination are necessary for society, and instead advocate more co-operative, anti-hierarchical forms of social, political and economic organisation.” (The Politics of Individualism, p. 106)

Argument 1: Estimating in hours allows a developer to measure his estimate against his actual, and use that data to improve his estimates in future.

This is true, and it works very well if a project has only a single developer working on it, or has more than one developer but they are all essentially working alone, on different parts of a system — a common model in a “build-by-layers” approach to system development.

Problems arise however when we introduce the concept of cross functional teams working on “slices” of a system. What is a team-hour? Is it the whole team working for one hour together, or is it the average time it would take one team member to do the work? Already we are beginning to talk in abstract time, not real time. One team member may be twice as fast as most others, through familiarity with the system and/or greater experience; does one hour to him mean the same as it means to others? Clearly not. “One hour” becomes a confusing unit of measurement in such cases. It is also the case that different team members have different responsibilities. How do we find a unit of time appropriate across documentation, UI design, coding and testing. How does each team member measure the time other team members will take for their part of the work on the story? You’ll see that this quickly becomes completely unmanageable.

Some Scrum/Agile teams use hour estimates at the task level, with the assumption that a single developer will work on each task; this seems reasonable as the tasks are divided across skill boundaries, such as server-side, database, testing, etc. In this case Argument 1 seems to hold good: developers should estimate in hours at a task level and then improve their estimates by measuring estimates against actuals. Unfortunately this argument breaks down again as soon as we recognize that the best code creation, and the best testing is done in pairs. Again, what does one hour mean? A pair hour or an hour for one of the pair? What if we don’t know in advance (as we probably should not) who will pair with whom and on what? Who gives the hour estimates? Everybody? Just one person? Which person?

In general, I find the practice of estimating task time to be massive, wasteful overhead. Tasks should be small; they should move across the task board in a single working day. End of story. The focus of estimation should be at the story level.

Argument 2: Our customers/product owners don’t understand story points; they need to know how many hours developers are working so they know how much the work will cost.

I hope anyone reading this can see the immediate flaw in this argument: micro-management. Product Owners have no business knowing how many hours each developer is working. It breaks encapsulation and it breaks self-organization. Actually, it breaks pretty much everything. Customers are not buying developer hours, they are buying software. Their focus needs to be on how much software they can expect in an iteration; their measurement needs to be on comparing actual software delivered against expected (promised?) delivery.

Story points help set expectations here. Very soon after beginning iterative development using a size measure to estimate, customers will be able to see the capacity of the team: this team can deliver 40 units of software per iteration, therefor let me prioritize 40 units’ worth of features for the next iteration, with a few extra units in reserve. It is beautifully simple. A customer is welcome to map story points to cost (it will be approximate). He should not care about how many hours it took to make the software.

Argument 3: Story Points will map to time anyway, very soon we’ll see that (e.g.) one story point is worth 2.5 hours, so it is better to skip the intermediate step and just measure in hours.

This is a flawed argument, and assumes a team never gets better. Truly self-organized teams always get better. When a new team starts, it may be safe to say that (e.g.) one story point is worth 2.5 hours, but as the team improve their development and teamwork skills, as the code base is salvaged from the big mud hole it has been in for the past months or years and rises majestically to a state of elegance, and as the team use regular reflection to improve their process, the value of a single story point will change. It may come to be valued at only 2 hours, because time is being used more efficiently. Now instead of 40 story points in an iteration the team can take on 50 story points.

More story points per sprint means that the customer will be getting more software. The cost of this software will not go down; the team building it will be making greater profits for the company. That’s business. The customer is happy — happier, in fact — he is getting the software he needs at the price he expects to pay, but getting it faster. Everyone is happy.

Imagine if the customer was measuring time. He would expect his software to get cheaper as the team got better; what used to take twenty hours to build now only takes ten hours, because the developers have put time into creating a good infrastructure and developing good practices. This does not seem right. The benefits, at the very least should be equally shared between provider and customer. A time-based estimation model will not allow for that without (apparent) steep price increases.

A measure of size allows a team to show they are creating more value for money. We can draw big visible charts to show this. A measure of time will never show this, because there are always a fixed number of working hours in an iteration.

Argument 4: Story Points don’t allow you to improve your estimation techniques.

Actually, they do. Sometimes when clients ask me how this works, or why it works, I tell them it is magic. This is not so far from the truth. I have never really figured out quite why or how it works. But it does. Teams do get better at estimating. A simple velocity chart that maps two points for each iteration, i.e. estimated points and actual points, will begin to show the points converging over time, and not that much time either. Of course the shorter the iterations, the quicker this improvement will be apparent. I always recommend iteration lengths of one week or two weeks. Never longer.

And to be clear, the two points don’t just get closer together because teams are committing to less and less each time. The average value of points delivered goes up over time. This latter, it may be argued, is because teams begin making bigger and bigger estimates. I can see that would be a temptation, but because the team starts collecting historical data (sometimes even just at a gut-level) they self-correct for this, using their data as a baseline for future measurement. Remember, good software developers want to build good software, and they want to do it fast and efficiently. Suspicion doesn’t have much of a home in an Agile environment.

I am sure there are other (and perhaps better) arguments to favour measures of size over measures of time, and I’d love to hear them here. I’d also be interested to hear opposition to my arguments; healthy debate on this topic is welcomed.