Agile Thoughts

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.

Update: In November 2007, at the Scrum Gathering in London I was invited to rejoin the Scrum Alliance by Ken Schwaber, its founder and chairman.  Ken and I had always maintained a good professional friendship, and I had watched the Scrum Alliance grow and change over the year, eventually hiring the excellent managing director, Jim Cundiff, who is instrumental in moving the whole organization towards a much more self-organized model, in true keeping with its principles.  I was happy to accept, and to re-apply for CST status, which I received in January 2008.  My love for Scrum, and for the people in the community is alive and well and I am proud to be serving the community as both a coach and a trainer.

More pictures…

The crum SEx change… playing with words and with ideas, playing intellectually and physically, talking, thinking, laughing, moving, telling stories, writing poetry, celebrating failure, finding new questions, interacting, listening, feeling, dialog, conversation, passion, digging down (how low can you go?), exploring really tough questions… and then there was the warmth of old friends, the excitement of new ones – and it all related to a deeper understanding of Scrum. That was my experience of the Scrum Exchange 2006. Some personal highlights from other participants follow…

Personal Highlights

The event exceeded my wildest expectations!

Size and setting and informal flow was FANTASTIC.

The people and sponsors were wonderful and very open.

Having so many people believing in Scrum in the same place, exchanging ideas and experiences.

Meeting people who want to transform organizations.

Edgy, interesting, amorphous sessions.

Interesting insights into others who have been doing Scrum for a while.

Learned a great deal about Scrum in general; specifically, gathered info to promote and support the use of Scrum within my company.

The willingness of all participants to try weird stuff.

Scrum Intro and the self-organization activities (Key Principles of Scrum).

Realizing the connection/common theme behind all the sessions I attended.

Michael Hamman’s session about “requests” and “invitations”.

The general acceptance by everyone.

The Velocity Game.

Scrum Basics (green track).

Ending as a big group with Terry Sand and play and humor.

The arm twisting and entangling exercise (in Tobias’s session) was a great way to dramatically illustrate the power of self-organizing teams.

Teamwork - change - acting outside the box.

Pouring lemonade over a piece of cheesecake to the affirming sound of “ding” from the group: the power of positive feedback. [ref]

Bodywork - cutting paper, role-playing, games, especially Matt Smith’s “finger” solution to Power Games

Kert’s session.

Strangely enough, being able to come here while waiting to see my very ill friend was a gift. Thanks!

Dan’s session. I want his powerpoint slides.

Meeting people who have little experience and more experience - and sharing.

Conversations with people I wanted to meet, like Victor (Szalvay). Also new people, new friends and collaborating.

Rethinking ideas with new perspectives.

Realizing I’m not alone with the frustrations I am feeling trying to implement Agile.

Opportunity to get the input/advice of not only practitioners, but also other attendees - networking.

Kert and Steve’s classes provided me with a number of good ideas on how to help make my teams more cohesive.

Great new relationships.

Everyone was open to conversation, interaction and helping each other.

Great valet service!

The photographs on this post were taken by Alan Cyment (who, by the way, flew in from Buenos Aires for this event). There are more great photographs of the event at here. Enjoy.

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.

Last week I had the privilege of working with an organization in the UK who take Scrum seriously, and understand that it is more than a quick fix. The director/VP level management realise that it will take time for Scrum to show benefit and more importantly they understand the need to trust their development teams.

I spent five days with the company, and they committed 25 of their developers and testers to working full time with me during those five days. That is a big investment, and I recall with dismay those companies that have told me “we can’t afford the time to send our employees on a (two-day) training course” - we have work to do”… just like the lumberjack who complains his saw is blunt, but then says he is too busy cutting the tree down to stop and sharpen it. But these UK guys were different.

This company have been doing Scrum for about 2-3 months. The one Scrum Master they currently have took the CSM course that Boris Gloger and I facilitated in March this year. They have had some success with the transition, but then started to run aground and recognized they needed additional support in the form of on-site coaching. A good thing to recognize. I wonder how many companies fail to make that connection and continue to struggle. Scrum is not easy; it surfaces problems and makes things look ugly. Some companies will do their best to hide the unsightly things and plod on with a “hybrid Scrum” (eek!) that doesn’t address, or even acknowledge the root causes. Other companies will abandon Scrum altogether and reach the conclusion that “Agile doesn’t work for us”. Happily this UK company decided to go to the next level and work through the difficulties.

During the first two days I worked with a partner, Michael James, to run a team training course. I sold this course to them over a CSM course, partly on cost (it is cheaper by $50 per head as there is no payment to the Scrum Alliance for certification), but mostly on the fact that these people (with the exception of 2-3) would all be Scrum Team Members, not Scrum Masters. It made sense: train for what you are going to be.

There was a lot of skepticism among the workers - remember this came as a management initiative, not a grass roots one. Most of the skepticism is of the healthy kind (willing to learn) but not all of it. Still, the general mood of the group was positive, and Michael and I made a lot of inroads in terms of creating a shared understanding of the nuts and bolts of Scrum, and the use of simple tools such as the task chart - which I more and more see as a core element of a highly functioning Scrum team. When used correctly the task board will keep a team focused and grounded.

During the latter three days the work was focused on improving the quality of the product backlog, identifying organizational impediments, and, most interestingly, exploring the limits of self-organization. The outcome was that the teams completely restructured themselves, and removed a “control” group who were responsible for decision making, prioritization, estimation and work assignment. All duities of this control group would now be distributed between teams and Product Owners. Making these decisions created a feeling of empowerment and freedom among the team members, but to the point where I grew slightly concerned. There was a danger that it could move towards a state of anarchy. Could this be too much freedom, too much power? How would it be used?

I recalled Spiderman’s famous line “with great power comes great responsibility”. The teams were empowered, what now, was their responsibility? This led to a discussion on Responsibility and Commitment. The whole group worked on creating a Team Charter that expressed their commitment to the organization. This was done in small teams, through three iterations, sharing the results with the whole group at the end of each iteration, reconceiving, and then fine-tuning during the subsequent iteration. It was a sort of Scaled Scrum model: living the principles. At the end of the third iteration the product was complete. It was not perfect, but it was a working agreement that everyone present (including the skeptics) felt able to commit to for the next thirty days, when it would be up for review. The Team Charter would be printed large and displayed around the building for all to see.

Here is a copy of the Team Charter:

Framework: We commit to following Agile principles to the best of our ability using the whole Scrum framework.
Quality: We commit to building quality into our products at every stage of their development and to continuously review and improve our techniques for achieving this.
People: We are professionals and have a responsibility to respect each other, act honestly, communicate openly and assist/seek assistance where appropriate.
Process: We commit to working with the organization to define a minimal process to guide our activities over the duration of each sprint, empowering teams to get the job done.
Growth: As individuals, we commit to enhancing and furthering our knowledge and to share that knowledge, as appropriate, with others at [company].

I am deeply impressed by this piece of work, and would love to see more organizations create such a document. To me it showed a seriousness and a dedication which is rare amongst grass roots workers in a top down implementation of Scrum. The experience of working with this company was one of my most enjoyable consulting experiences to date. I hope to be back there in a few months for a follow up visit, and will get to see if the good intentions became good actions. I’ll let you know…

I went to Canada for the first time on Wednesday.  This trip followed hot on the tails of my recent UK jaunt, so I was still reeling from lack of sleep.  The reason for the visit was to run an in-house CSM course, in partnership with a Scrum colleague. The course was being held at the hotel where we stayed, so all I really saw of Canada on this trip was the inside of the hotel, and then on Friday morning some of the rather bland surrounding streets leading to the local golf course where I went running; dull, but it was the only green place within miles.  So no memorable impressions of “Beautiful Canada” for me yet. 

The CSM course started shakily.  There was a lot of confusion from the participants as to why they were there and what the course was actually about.  This is a feature of many in-house CSM courses where Scrum is being introduced in a top-down way.  Many participants did not actually know it was a CSM course, or what that implied.  Mental note: assume nothing.  After a bumpy start, with a sense that the course was limping painfully along, the second half of Day One eventually picked up in pace, and then Day Two was fast-paced and a lot of fun.  My co-facilitator and I both recognize that the course needs still more experiential and interactive content.  It is these aspects of the course that work the best - according to both our own observations and participant feedback.  It was the actual simulations, i.e. 59-Minute Scrum, Plan A Party, The Velocity Game and Prisoner’s Dilemma that were the most engaging aspects of the course.

The first half of Day One sorely lacks participant involvement.  The other problem we always face on the first morning is a myriad of “how will this work for me” and “what if” questions.  Usually we are firm about deferring those questions until late into Day Two, where we find they are mostly answered by the preceding course content, but sometimes I find I can too easily get caught up in discussions which take us off onto unwanted tangents.  Such discussion, although possibly interesting, is usually not constructive early on in the CSM course. Action is what is needed.  I am now working on tuning the early part of Day One to incorporate more action-based activity: Learning by Doing.  The difficult part of this is finding simulation-type exercises that will work when there is little knowledge of the Scrum process.

The nature of an in-house course is very different from a public course where the participants are almost always there by choice, and are either practicing Scrum (in some form), or have made some effort to learn about it from books and articles; a level of engagement and an excited anticipation exists from the start in public courses, and it generates energy for both the facilitators and the participants.  In-house course participants are too often there because they are told to be; they are not there willingly, and that is a major contributing factor to why the early part of in-house CSM courses tend to drag: we have to “sell” the idea to the group. 

The other big issue I have with the CSM course is that it is a CSM course.  Most participants on this particular course cared nothing about being ScrumMasters, and having to cover certain ScrumMaster-specific material began to make little sense.  Team training is what is required in many of these cases, but sadly the Scrum Alliance does not offer a Certified Team Training course and it is the Certification part of the name that sells the course.  We do companies a disservice by only having this course to offer. 

The Scrum community does not need tens of thousands of Certified ScrumMasters; the idea is nonsense.  What the community needs is informed team members, who recognize that successful working relationships and healthy work environments are formed from something more than a quick-fix two-day course and a certificate. It is time for the Scrum Trainer community to rethink their (our) strategy for introducing Scrum into organizations.

Boris Gloger and I ran our first public Agile Product Owner course last week in Cambridge, UK.  It was an interesting experience, especially in that we had no actual product owners on the course.  Instead we had a physicist, a software engineer, a CEO, an IT director, a partner, a scrum master, a consultant and a PhD student.  The latter two were perhaps the closest to the role in terms of previous experience, but not engaged in that position at the current time.  The material was of course essentially aimed at those immersed in the role, so its applicability was somewhat lost, and the course became rather academic in nature.  Still, it was an interesting first run and most of the feedback at the end was very positive.  Interestingly, one of the most skeptical and questioning people on the course gave us the best feedback.  That always feels good.  You can read some of the feedback comments here.

One of the roles we asked participants to take on after the course was that of critic.  I have always felt that the Agile world lacks serious and informed critics in its midst and I have an aim to cultivate that skill on my courses.  The participants were asked to write a three paragraph critique of the course in the style of a film or book review.  Only one participant (to date) rose to the challenge, Paul Oldfield.  Paul’s critique begins with “This course is good.  It has the potential of being excellent, but it isn’t there yet.” and then goes on to pinpoint some areas of concern in the “usual ‘critic’ style guaranteed to get up the noses of authors, actors, presenters or whatever” (Paul’s words).

I have uploaded a PDF of Paul’s critique, somewhat nervously, but hey - it’s all about transparency, right?  You can view the document here.

Do I agree with Paul’s criticisms?  Not completely, but yes, in part. He and I have entered into a short dialog on some of the points, and perhaps Paul will comment further here.  Whether or not I agree is really beside the point;  Paul took the time to attempt a serious critique of the course, and that is what I was seeking with this exercise.  I hope other trainers take up this idea.  Scrum needs critics or it is in danger of becoming watered down and half-baked.  All we have now it seems, are evangelists and skeptics (often uninformed skeptics).  Criticism is an art, and we need to cultivate it among those entering the Agile field. 

Boris and I plan to run the Agile Product Owner course again in the fall in Palo Alto, California and Manchester, UK.   Criticism is optional (!)