Agile Thoughts

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

It surprises me, but I have recently come across a few people in the Agile field who prefer estimating in “real time” over estimating in size (e.g. story points); I have even heard statements such as: the most advanced implementations of Agile use real time estimates, because it offers the most powerful benefits. My gut feeling has always told me otherwise, but I found that I didn’t have a well-thought out argument beyond, erm… read Mike Cohn’s book, which in the event of a real-time discussion is not very helpful, and even so does not address all of the arguments I have been hearing against size-based estimation. This blog post is my attempt to clarify my own thoughts on this matter. I focus on four specific arguments in favour of time measurement, and attempt to counter those arguments.

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.

In teaching Scrum during the past year, and working with organizations in a consulting/training capacity I have found more and more that some of the principles as outlined in the two Scrum books are out-dated and unhelpful. I teach what I know works and what I see as being appropriate; there are slight differences in each context of course, but there are certain practices I have found to be effective, all of which differ from standard Scrum practices; some would be considered radically different, which leads to the difficult question, the title of this essay: when is Scrum not Scrum?

1. Product Owners are part of the team.
Having a hard separation between PO and team is unhelpful; it causes rifts and exacerbates the “them and us” culture. I discarded the distasteful “pigs and chickens” terminology a long time ago, and now encourage teams to incorporate the Product representative (not owner) into the daily meetings and the retrospective as well as the planning and review meetings. To do this successfully requires a different mindset from everyone involved, so the style of training and adoption needs to change accordingly. This is not trivial.

2. Two-week Sprints
Thirty days for a sprint may have been appropriate twelve years ago when Scrum was developed. Today it is far too long. It is also true (from my experience) that teams are incapable of planning a thirty-day sprint effectively. It is overwhelming. Most teams I have tried it with nail the first part of the sprint, but allow the second part to be vague and muddy. They get exhausted by the eight-hour meeting, and simply find the time frame too long to plan effectively. A thirty day time frame also means a customer change request can take up to 60 days to be completed; that is far too long.

3. Tasks are not measured in hours
Insisting on hours breakdown and having each team member continually update hours remaining on a task is often perceived as a sneaky, micro-management approach. In my experience team members find this practice frustrating and meaningless. Long ago I moved towards encouraging team members to break all tasks down as small as possible. A task must be completed in a single working day or it is considered an impediment, and should be marked as such. This approach serves two purposes: firstly, ease and accuracy of burndown (burndown on tasks rather than hours, making the whole process binary: a task is done or it is not done) and secondly it raises impediments which developers themselves may not see. For example, an incomplete task may be in that state because a developer was called off into some long and meaningless meeting, but because “that is the way we work around here” this is not seen as an impediment. Physical markers on tasks (e.g. stickers on task cards) show the truth of what is happening.

4. Use of Taskboards rather than spreadsheets
The Scrum books, and many CSM courses promote the use of spreadsheets to track the sprint. This is really horrible. Spreadsheets hide information, and they lie. The best way to create transparency is to display everything on Big Visible Charts. The interactive, collaborative nature of taskboards lends itself to the Scrum process, like no electronic tool ever can. Taskboards can work with distributed teams too, by having proxy updates (via telephone) and sharing photographs of the board on a wiki — every day.

5. Backlogs on the wall
Again, moving away from spreadsheets. At least the next 3-4 sprints worth of stuff should be displayed on 3×5 cards on the wall of the team room so the team can get look-ahead time. Backlogs much longer than that, containing anything more than placeholder items (reminders) can be thought of as wasteful, in any case. The less time we give to thinking ahead in detail on features that may never see the light of day the better.

6. Estimation Meetings
Estimation is done before the first sprint, and then on a regular basis during each sprint. I have found that a 1-2 hour meeting about 2-3 days before the end of a sprint is the ideal time. Estimates are done in Story Points, as described in Mike Cohn’s books (not “ideal developer days” as described in the Scrum books). The estimation meeting is an integral part of a successful cycle. Having the backlog on the wall ensures developers have continual look-ahead time, thus keeping the estimation meetings short.

7. Insistence on Agile Engineering practices
It isn’t enough to assume because a team is “doing Scrum” that engineering practices will begin to change. They won’t. And they don’t. It is essential to introduce some core practices such as unit testing, early acceptance test specification, componentized design, continuous refactoring and pairing from the start. This doesn’t mean the practices will all be undertaken immediately, but the importance of such practices must be stressed. Scrum itself says nothing about such practices, and that tends to give organizations a sense that Scrum is easy to do, and can simply (as many of it’s proponents state) wrap around existing engineering practices. I have seen this approach fail too often to have any faith that it is true. Intuitively even, it seems likely to not be true.

8. The Scrum Master role is not always necessary
An effective self-organizing team is exactly that: self-organizing. Leadership emerges from the team when the key Agile principles are adhered to. The Scrum Master role becomes superfluous in a healthy Agile organization. There is a role for Agile leadership at all levels in an organization, but Scrum Mastering so often becomes a pointless role, and many organizations see it as another type of project management role, driving people. Coaching should be appropriate to the context. I have seen a lot of lousy Scrum Masters, falling into old PM habits, and having teams simply accept it, because that is how they are used to working. I also have issues with the term Scrum Master; language often dictates how we behave, and this term doesn’t help to break paradigms.

So is what I do Scrum? Perhaps it is; there is enough of the original flow there to claim so: planning meeting, daily meetings, delivery of working software each sprint, retrospective, but ultimately the name itself is superfluous. The Agility inherent in the principles I teach and coach to allows fundamental change to take place in organizations. That is what I am after. If it helps to call it Scrum, we can call it Scrum. It offends to call it Scrum we can call it something else. Eventually, it will simply be “what we do”.

Scrum is a useful framework to get started down an Agile pathway, but if the framework becomes a rigid way of thinking it destroys its own purpose. The reason so many organizations struggle with Agility is because they want a quick fix. Scrum purports to offer that through its two-day “Certified Scrum Master” course. It is a superficial and ultimately unhelpful approach, and one that I am glad, finally to be disassociated with.

On 30 January 2007 I was fired from the Scrum Alliance for challenging the leadership on issues of integrity and transparency. I no longer teach CSM classes. The official reason for the termination: “…the effort to sustain you has exceeded the benefit you bring to the ScrumAlliance over the last year” is a little unclear to me, but it was my time to move on, so there are no hard feelings there, and it does allow me to begin to explore Scrum and Agile in new ways. If we don’t press for change, as context of place and time dictate, then we are in danger of becoming that which we set out to challenge: another silver bullet with fixed solutions to fit every problem. And the Scrum Alliance is in danger of becoming another command and control organization, shot through with rules and contracts to control the course of this new silver bullet. I reject that approach: I embrace chaos, and I embrace holistic, context-sensitive approaches to creating essential change.

The Scrum Exchange (SX) in Palo Alto, California is just three weeks away, so I thought it was time to start blogging about it.  In this post I’ll give a brief summary of my experience in organizing this event; later I’ll add posts about the event itself, and I hope other attendees will also contribute to that effort.

The idea for this event had been hovering at the back of my mind for a while.  I think since Kert Peterson, Michael Hamman and I had a chat at the Advanced Scrum Master training in Boulder in January 2005 when Kert conceived the idea of Agile Interactive (a name and concept which I have boldly and unashamedly stolen for one of the tracks at SX).  The general concept was to stage a small and intimate event where interactive and experiential ways of learning could be explored.  All of us felt, in some way, that a new way of building knowledge of Agile ideas and practices needed to emerge - that talking and showing powerpoint slides was inadequate to express the concepts inherent in the Agile paradigm.  The idea was just a bud back then, and none of us had the time to pursue it much further, but it continued to quietly blossom.

When I attended another Agile event almost a year later the idea surfaced again.  I was dissatisfied with the format of the event, which was essentially all Open Space.  I think the concept of Open Space is a good one, but in practice, and in my experience, it has consisted of much rambling discussion, with people writing lots of stuff on flip charts, some of which gets transcribed to a wiki… and then what?  The event was packed with bright people, all involved with Scrum and Agile in some way, all willing to share their experiences and explore, and yet it appeared that the forum for that sharing was limited.  Dialog is good, but it is only a small part of learning.  The problem, as I saw it, was that we were all sitting on our butts and talking.  Yap, yap, yap.  I was bored, I felt constrained, and I wanted to move around.  My mind was getting a lot of input, but my body was uninspired, unchallenged.  Why does that matter - this is software stuff we are taking about, right?  I don’t know why it matters, but I do know that it does.  I was unable to embody what I was hearing, and most of it was gone within a few days, as I knew it would be. ¹

Some people can learn through head input alone.  I cannot, and I figured I was probably not alone with this learning handicap.  I talked to a number of people about this over the next few months, regarding their feelings about the particular event and of Open Space in general, enquiring what they felt was positive and what was lacking at this event, and in this form of learning.  I don’t know that I came to any firm conclusions from these discussion, and the vision of the event that developed was more gut response than an acting on carefully analyzed data. 

During the Scrum Gathering in Boston, in April of this year I discussed the idea with Victor Szalvay.  Victor and I have been exploring partnership in various ways (as we Scrum trainers tend to do) and this seemed like a good opportunity to do something else together.  Both of us were willing to take a financial risk on this event, and it was good to be able to share that risk. 

To begin with I focused attention on those facilitators I felt would be able to deliver a more experiential type of workshop and invited people I had worked with personally.  With Victor’s influence the event gradually expanded to include a Scrum Starter track and an Advanced Agile track.  We widened the invitation to include additional west coast Scrum trainers.  Even so, the focus of “learning-by-doing” was kept to.  All facilitators have been asked to keep the powerpoint/lecture aspects of their workshops to a minimum, and experiment with a more interactive approach.  Probably the most physical of the workshops will be those in the Agile Interactive track, but it is hoped that all sessions fit the general theme of “Agility in Motion”.  We shall see.

The Scrum Exchange event is probably best described by this paragraph from the web site:

The Scrum Exchange is an open event aimed at all those involved in, or intrigued by Scrum and other Agile practices.  The theme of the event, Agility in Motion is intended to promote the idea that Scrum and Agile need to be experienced, not taught.  The event will allow for the exploration of new ways of thinking and learning about being Agile.  This will be achieved through experiential and interactive workshops, rather than traditional presentation methods.  Come with an explorer’s mind, and be willing to step beyond your comfort zone.

More SX blog posts are planned.  Watch this space…

1. By coincidence, as I was writing this post Pete Deemer sent me this video link in which the speaker, Ken Robinson, discusses the need to include creativity as a core subject in our schools, and refers in particular to people who “have to move to think”.  If you need clarification on what I am getting at in this post, watch the video.  Thanks Pete, excellent timing!

Little to report.  Slept most of Thursday, followed by a trip to Buenos Aires Opera House to see a Wagner concert (okay, not exactly Latin American culture, but my host already had the tickets).  We wondered the theatre district and ate pizza that night.  Second best Pizza I’ve ever eaten (best was in London - don’t laugh, it’s true!).  But I did have the very best pasta I’ve ever eaten in Buenos Aires a couple of nights earlier.  Big Italian influence here; apparently the ice cream is the best in the world.  That’ll have to wait until next time.

Spent most of Friday in my private Jacuzzi, unwinding and reading the Rough Guide, and on Friday night I went out with a bunch of the guys from the course (around 12 of us) for Asado - barbequed beef and other assorted cow parts.  I was persuaded to eat something unidentifiable - “don’t ask what it is, ask if it is good!”  It wasn’t, and I did ask.  Glands.  I regretted asking.  The whole Argentina beef experience was a bit of a let down, really.  The dessert however was a perfect example of Argentinean flan, topped with cream and dulce de leche, the sweetest thing in the world.  That alone is worth returning for - and the pasta, of course.

Spent Saturday strolling through La Boca, absorbing football, painted buildings, local artists, tourist trash and tango, and later through my local area, Palermo, full of charm and style and a great market place.  Really, a lazy wrap-down to the week.  Next time I’ll be more of a tourist.  This time it was work and people focused.  The best part of this whole trip was the people I met: the welcome, the friendliness, the course itself, it all exceeded expectations.  I’m home now, 18 grueling hours of flying.  Tired, but happy.  The desire to return soon for more of the city and the people is strong today.  Thanks everyone for the great feedback, and the kind words.  Alan and I are already planning the next visit.  Details will be available here as they become known.  Stay tuned.

Some related blog entries and photographs…

Mariano’s Blog 1
Johnny’s Blog
Shaggy’s Blog
Mariano’s Blog 2
Comments here
Angel’s Blog
Ariel’s Photographs: Day 1 *
Ariel’s Photographs Day 2 *
* Yahoo login needed to view the laasd photos

Scrum In A Box

• So… they say that Scrum is not an “off the shelf” methodology.
• Well, wouldn’t it be nice if it was?
• Time to create Scrum In A Box – the ultimate off-the-shelf methodology for the smart, bargain-hunting Software Process Shopper.
• With this amazing new product all need for CSM training will be eliminated. 
• Get the Box, and DO SCRUM!

This was the vision given to the four development teams on the Buenos Aires CSM course.  Their task was to build this product in two days, over four 30-minute sprints.  A Product Owner was chosen for each team.  The teams decided for themselves who this would be, and eventually all the teams rotated this role.  The rest of the team were developers.  There was no assigned ScrumMaster role, but everything that would be learned through this simulation would educate the participants on the knowledge and qualities needed to take on that role.  Task boards had been created on the walls of the room and the teams were introduced to this essential Scrum tool prior to starting. 

We began the simulation by considering the requirements.  The teams had a badly written, and very vague product backlog to help them kick off.  The first part of the simulation involved a discussion on usability.  Who was this product for?  Who would use it?  Why?  Through this conversation the teams began to understand that perhaps there was a serious use for such a product.  It could be a Scrum education tool.  Working with their product owner the teams began writing user stories.  This proved to be very difficult.  The vision was now unclear, the technology (modeling clay, cardboard, craft knives, marker pens, collage…) was unfamiliar to most - and it was day one of the CSM course, for heaven’s sake!  These people had yet to learn about Scrum.  All in all it felt very scary and chaotic. 

As mentioned in yesterday’s post, discussion and analysis began paralyzing the teams.  The fog was thick and everyone was trying to talk their way out of it.  Not very efficient.  It was time for action.  Near the end of the first day the teams executed Sprint One.  Planning was tough; no clear requirements had been written, the teams had found estimation close to impossible and no one had any sense of business value.  I encouraged the product owners to simply pick two things that they thought the teams could start on, have the teams figure out some tasks and just get going.  Each team had a task board to work from; the planning sessions and the daily meeting would be centered on this board.

The teams all felt a sense of failure after Sprint One.  The product owners essentially rejected everything they saw.  But this is when the learning began.  Through seeing what he didn’t want, each product owner began to get a better idea of what he did want.  Working closely with the developers a vision emerged through the review, and was more finely tuned through the retrospective and the following planning meeting.

The second sprint slowed down a little, as more focus was put on the bigger picture, on the design/architecture of the product.  Less was delivered, but there was a sense that the teams were on the right pathway.  In the third sprint some very high quality work was beginning to happen and by the end of the forth sprint some amazing products were fully completed.  It was astounding.

This was the first time I had run a CSM class in this way, and the quality of the work far exceeded my expectations.  But it was not only quality in terms of the product itself; the participants really began to embody the sprit of Scrum in their work.  Teams became cohesive wholes, “pair-programming” practices were adopted, acceptance criteria was defined before development started, a common understanding of “done” emerged.  All the good Agile development practices (some of which I had not even introduced) began happening.  The room was buzzing.

In one excellent moment at the end of sprint three, a team who had designed their product as a board game spent the entire 15 minute review meeting playing the game with their product owner.  They described it as their “acceptance test”.  Beautiful!

As each sprint went by, I took less and less of a process-driving role.  (basically, I got tired of clock-watching and shouting).  The fourth sprint was total self-management and was the most effective of all, with everyone keeping to the time boxes and completing all their work on schedule - in fact some groups completed a few minutes ahead of schedule and were able to simply relax.  I spent most of the fourth sprint walking around the room, absorbing the energy and passion, with a big grin on my face.

Scrum In A Box gave the participants of this course the opportunity to learn Scrum at many levels.  They were in a class on Scrum, they were actually doing Scrum, and they were building a representation of Scrum which forced them to continually assess Scrum.  There was a sense of introspection and infinite recursion here.  A life-force beyond anything that was planned.  One team even built this idea into their product: the final element of their “Scrum tour” was a set of instructions of how to build “Scrum In  A Box” to educate others.

I was honored to be able to facilitate this CSM class.  I learned so much myself from the experience, and was fueled by the passion and engagement.  I’d like to thank all the participants for making this such a great experience, and for embracing Scrum so openly and joyfully.  I consider this a true shared learning experience.

     Click to view

Later that evening I gave a two hour talk on Scrum at the public university.   I had imagined this as more of a lecture-style talk, but my co-organizer Alan Cyment had other ideas.  He encouraged me - and the audience - to get more interactive and we had a bunch of them up on the podium, holding hands in a twisted spaghetti-like formation, performing an exercise that in five minutes illustrates self-organization in a way that a million words could not begin to explain.  Following that interlude the energy of the room changed from quiet suspicion to interested engagement.  Thanks, Alan.  At the end of the talk we had a number of requests for further CSM training in Argentina. El virus está aquí!  Or, in Babelfish-speak: the agile insect has landed!

I now have a couple of days to relax in Buenos Aires, before returning on Saturday.

The Falklands War, 1982, Diego Maradona and the Hand of God, 1986, Andreas my next-door-neighbor in London, 1993-99,  The ear-torturing Evita, 1978, German refugees, polo, the tango, red wine, high quality beef…  Yep, that’s about it, the extent of my knowledge of Argentina prior to this visit.  I have not learned a great deal more in the past two days, to tell the truth, but I have learned that Buenos Aires is a cool and funky city, with good food and great people.  Twenty-five of those people are currently engaging with me on a journey of discovery about Scrum.  We are half-way through the CSM course and no one has walked out yet, nor aimed the usual suspicious, accusatory and closed questions at me.  There is some healthy skepticism, mixed with confusion; that is to be expected, and indeed welcomed.  On the whole, there is a spirit of open-mindedness here that I greatly appreciate; there is a desire to learn and explore.

Language has not been too much of an issue.  Enough participants speak good English to assist in translating for those that don’t.  Once we got past the first couple of hours of lecture (to cover the basic introductory stuff) the course became nicely interactive, and the language thing became even less of a barrier, as I had anticipated it would.  There is movement, there is passion, there is energy.

The overriding image I have of yesterday is best summed up by the phrase “Bounded Chaos”.  That’s Scrum.  The teams are being asked to build a product where the requirements are vague and the technology unfamiliar to most.  I’ll write more at the end of the course about the product the teams are building, preferring to keep that under wraps for now.  Mapping to the Stacey Matrix¹, we were on the edge of anarchy.  The more the teams tried to talk themselves out of that space the worse it got, and the deeper they entrenched themselves.  Predictably, talking just put us in the Analysis-Paralysis space.  The only way out was through action.  The teams were encouraged to start sprinting, to stop talking and take action.  It was chaos, but it was chaos with some boundaries around it: time-boxed, collaborative environment, regular feedback loop.  From the chaos, order emerged in the form of working agreements and innovative product.  It took just thirty minutes (the first sprint) to go from despair to knowledge, to go from fear to excited anticipation, to go from nothing to something.  Emergence.  That’s Scrum.

More tomorrow.

1. Read about Complex Adaptive Systems and the Stacey Matrix here.

Greetings from Buenos Aires, Argentina.  I am here to teach a two-day public CSM course.  To the best of my knowledge, this will be the first public CSM course to be taught in South America: an exciting, and scary prospect.  I speak no Spanish and my lame attempts to use BabelFish to translate some of my emails to the local Agile list ended up with heart-felt sentiments such as “I hope, like me you will catch the Agile bug” being translated into something about chasing fast-moving insects.  Undeterred I persevered with translating some of my handouts into Babelfish-Spanish.  Tomorrow will tell how foolish I look.

The translation effort was probably in vain anyway, as today I discovered that it is not the written word the Argentinean software people have difficulty with, but the spoken.  This has caused me to inspect my Powerpoint deck, kept deliberately minimal to avoid confusion, and add a number of new slides which can support my (now to be expected) unclear verbal expression.  So here I am at midnight, drinking coffee and inspecting and adapting like crazy.  Not really sustainable pace… nervousness and coffee: a lethal combination.

I have designed this course to be mostly interactive, so the participants can talk to each other in any language they choose, and I don’t need to understand a word of their discussions.  This course will be learning-by-doing:  Scrum simulation from start to finish.  The concept is something I have been experimenting with over the past few weeks, along with a couple of CSM/Trainer colleagues.  Results so far have been very positive, but it has not yet been tried in a different language… More tomorrow.

A few general interest notes… I am staying in an apartment belonging to a friend of my co-organizer, Alan Cyment.  Alan has essentially put this course together, finding the space, gathering the people, and organizing my accommodation and various entertainments.  The apartment belongs to an ex-professor of his, so full of books, all in Spanish except for “Eats Shoots and Leaves” (is that even translatable?) and the occasional Douglas Adams novel. 

The apartment is on the eighth (top) floor of a city apartment block.  There is a Jacuzzi in the living room; no kidding.  On a deck, and everything.  In  fact, the office desk is also on the deck, and the only available chairs have the spindliest legs imaginable.  Trying to place one of these chairs on the deck and have it not slip through the cracks… well, you can imagine.  It’s like a challenge from one of those dumb TV shows (hidden cameras in the walls,  maybe?).  After making the same mistake and expecting a different result enough times, I resorted to sitting on a bean bag, stacked up with two sofa cushions.  It started well, but when I found the keyboard was at the level of my chin and I felt like a hunch-backed midget I eventually gave up and relocated to the dining room.  The internet access is now spotty, at best.  Compromise - hate it.

Alan and I did some last minute running around this evening, trying to buy a flip chart.  Not something that is easily found in this city, apparently.  There is not even a common translation for the item.  We settled on a big role of brown paper instead, which we shall line the walls of the training room with before we begin.  Reconceiving - love it!

Twenty-four people have enrolled for this course.  Eleven more were turned away.  That is quite remarkable.  When Alan and I first discussed this, we optimistically hoped for around fifteen, which would have just covered expenses.  It is still largely a labor of love - and a challenge.  The economy in Argentina is such that the cost of this course seems extremely expensive to locals, yet is barely viable for a trainer to come here.  Not something that bodes well for future training.  Love of Scrum and a desire to spread the word will need to be the inspiring force for future trainers to head out this way.

I hope I am able to offer something worthwhile over the next two days.  Training anyone, anywhere, is a noble and scary endeavor, and one I shall never take for granted.  Time to get some rest.