agilethinking.net Blog

I am in Buenos Aires for ten days, running CSM courses and Games Workshops at the Ágiles 2008 conference.  It is an amazing experience, and a great honor to be here at the first Latin American Agile conference, and I’d love to wax lyrical about everything I feel being here, all the wonderful people I have met, and those I have renewed acquaintance with from previous visits.  But that is not why I am writing this blog.

I am writing here to process an interaction which I found unsettling.  There are a few guest speakers here from the USA including Mary Poppendieck and Micah Martin.  It surprised and disappointed me that both Mary and Micah used the final panel discussion of the conference to publicly denounce Scrum as “insufficient for building software”, and deride the CSM certificate as being useless.

Micah bemoaned the fact that the last Agile conference (in Toronto) had been “taken over” by Scrum Masters, and made the comment that teams “did not need a Scrum Master to tell them what to do”.  Luckily many attendees at this event were differently informed than Micah in their understanding of the role.  I talked quietly off-panel with him afterwards to explain that 1) I agreed with him: teams do not need Scrum Masters to tell them what to do, and 2) that he had completely misrepresented the role.  Micah was willing to listen and hear.  In his other panel comments Micah said many memorable and insightful things about software craftsmanship that I happily agree with.  In fact, I think that he and I are 90% aligned in our thinking.

More disturbing was Mary Poppendieck’s attitude towards Scrum.  I would actually describe it as hostile, and when I tried to engage her in dialog about it later at the reception she (unlike Micah) seemed unwilling to listen but chose instead to talk at me.  She claimed again that Scrum was insufficient, that it had the wrong roles, that it targeted dysfunctional companies (well, yes!), and that she disliked it because she spent 90% of her time cleaning up after bad Scrum implementations (she then went on to say she never worked in dysfunctional companies, which seems somewhat inconsistent with the earlier clean-up statement).

Then Mary singled out Jeff Sutherland as an exception, claiming he doesn’t do Scrum the way everyone else does, as he enforces all necessary software development practices, has a lead engineer in the team, does architecture up front, and has a Scrum Master who codes 90% of the time. In essence he runs “the Toyota process”.  I am not stating facts here, just repeating the gist of the conversation.  I concluded that in Mary’s opinion only Jeff Sutherland (and those trainers who work directly “for” him) understand what Scrum is, or ought to be: i.e. Sutherland-Scrum rather than Schwaber-Scrum.  The rest of us are charlatans.

It was a very uncomfortable, and one-sided conversation, and a little surreal given the joy and openness of the conference up to that moment; it seemed that every question or comment I offered was taken as an attack.  I was seeking a crack in the wall of resistance to initiate a dialog with Mary, but I did not find one.  Dave Nicolette, also present at the table had more luck, perhaps because he is not a Scrum Trainer.  Dave actually did a skillful and patient job of attempting to offer some balance to the conversation.

Disparaging and mocking comments about Scrum and CSM certification were also made during and following the Agile2008 conference in Toronto by some of the key speakers.  There appears to be a trend here, one which I find ugly and sad.  It is no surprise when people new to Scrum misunderstand it — it is difficult to fully grasp its full implication, but it is very surprising and disturbing that people deeply involved in the Agile movement show such a lack of understanding of the true nature of Scrum, to the point where they feel the need to publicly denounce it.

As I thought about all of this later in the evening, I recalled a comment Mary made during the panel today, immediately following my suggestion that reflection was essential and teams need to run regular retrospectives if they are to improve.  Mary enthusiastically retreived the microphone from me and said something like “as the voice of opposition here I have to say that I don’t agree with Scrum retrospectives.  I have my teams meet for a couple of hours every week to focus on process improvement, using ‘plan-do-check-act’ and other scientifically proven process improvement formulas” (I am paraphrasing).

It occurred to me that maybe Mary was a process-focused person, and was not considering, or particularly interested in human factors.  Retrospectives in Scrum (for me, and many I know) begin with individual improvement, personal development if you like.  Good process follows.  Perhaps this is a key difference between Lean and Scrum: Lean is about efficient process; Scrum is about effective people.

I am sure the preceding statement will call forth loud objections, but I am grasping at straws here, trying to make sense of why someone as intelligent, experienced and well-respected as Mary Poppendeick would need to publicly disparage a beautifully elegant Agile framework proven to be so successful for so many organizations.  It doesn’t make sense to me.

Why is Agile Software Development becoming a competition for some?  Why must Scrum lose for Lean to win?  This is not the presidential election.  We are all seeking the same goals, and it is the diversity of thought, the rich, chaotic mix of ideas that will help us achieve those goals.  There is no “one truth”.

I’d love to help get the focus away from competition and back onto collaboration.  If you have any suggestions toward this end, please add your thoughts here.

N.B. this blog post naturally represents only my perspective.  It is a gut response, wholly subjective, and therefore not “truth”.  I’d be happy for anyone else present during the panel discussion or the following reception, especially those mentioned by name, to add their own perspective.

This entry is the third in a series of three, which describe the workshops I facilitated at Agile 2008.  The full description/original submission of this session can be seen on the Agile 2008 submissions board: Operating on the Creative Edge: Applying Improvisation Techniques in Agile. 

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.

Scrum is not some newfangled, flash-in-the pan methodology for software development (it isn’t a methodology at all, but that is off-topic for this blog).  Scrum is a very small part of a greater movement in the business world, and perhaps the world of organizations in general.  We are at the beginning of a true Kuhnian paradigm shift away from a mechanistic way of thinking and towards a human one, a living one.  The theory underlying this world-view is known as Complexity Science, and in particular the study of Complex Adaptive Systems (CAS).

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.

Guided by a discussion on the Scrum Trainers list I just read Jeff Sutherland’s latest blog, Shock Therapy: Bootstrapping Hyperproductive Scrum, where he quotes the words of Scott Downey, the MySpace Scrum coach, describing his Scrum bootstrapping techniques.

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 entry is the second in a series of three, which describe the workshops I facilitated at Agile 2008.  The full description/original submission of this session can be seen on the Agile 2008 submissions board: Fashion Cycle. 

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.

In early August I was at the Agile2008 conference in Toronto, Canada.  I was privileged to run three workshops there, and in the process of writing up the sessions for the Agile2008 wiki, I decided to feed them into my blog.  My blog needs feeding.  This entry is the first of three.

__________________

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.

Many Scrum practitioners these days are working hard to come up with the best way to make Scrum work in distributed (usually off-shore) environments. There are many articles being written on this topic, and many submissions to the major Scrum and Agile conferences. They all say something similar, we know that co-location is ideal, but the reality is… and then go on to offer “solutions” (read work-arounds) for the non-ideal, real world situation where team members are scattered around the globe.

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

“Scaling agile is the last thing you want to do” — Martin Fowler [ref]

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

On a recent scrumdevelopment thread about changing Scrum (here) Dave Barrett wrote:

“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.

An open letter to Jim Highsmith

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)