The Agile Playground #3

Agile Playground Index: [AP#1] [AP#2] [AP#3]

Note: This exercise is probably the oldest one in my repertoire, preceding my software career.  I first used it when I was running advocacy workshops with disenfranchised inner-city teenagers – a  field of work not a million miles from the IT environments that many work in today… It needed almost no adaptation to work in Scrum training session sessions, just the recasting of some of the terminology.

Spaghetti

A game to illustrate the beauty of self-organization – and the pain of ‘expert’ management.

Instructions

Create a tangled knot of 8-10 people through a process of crisscrossed hand-holding. It feels awkward and uncomfortable. The other participants act as analysts, managers and observers. A vision of an open circle is offered, with everyone standing comfortably, holding hands. A constraint is set that in order to reach that state the hand-holding must not cease. The set-up for eight people will look something like this.

Once the team have established the spaghetti format, appoint and analyst and a manager (or ask for a volunteers).  The rest of the participants act as observers, and you should emphasize the importance of the observer role for giving feedback after the exercise.

The game proceeds in three stages:

1. The analyst is asked to write a spec: a set of steps the team members have to take to resolve the problem. Team members do not move.  You can offer the analyst a state-of-the-art analytical tool (a chair to stand on).  After a while it will becoem clear this is hard to do.  Maybe the first 2-3 steps will be written down.  Allow a few minutes, expressing impatience. Fire the analyst.  Employ a manager to direct the team.
2. The manager is asked to give instructions to each team member, using the requirements document the analyst wrote (if they managed to do so). If no document, use well-known micro-management directives to tell people what to do.  The team members will move if told. Team members not instructed to move should wait their turn. Usually this will not result in a solution.  Allow a few minutes.  Fire the manager.
3. (Of course) the team is asked to resolve the problem itself. What happens next is an almost text-book example of self-organization: a collaborative, reflective, emergent behavior occurs and the problem is quickly resolved.

Debrief

Debrief in a way that is comfortable for you, but with a strong focus on how it felt to be a team member waiting to be told what to do.  It is the feelings of frustration, irritation, boredom and waste that you’ll probably want to refer to at other times in the training. This is what Scrum helps to remove. There are many other Scrum learning moments in this exercise.  Look out for them and allow the team to discuss when appropriate.

The exercise lasts between 10-20 minutes.

Notes

If you have a large group you may want to immediately follow this exercise by allowing everyone to experience the feeling of resolution through self-organization.  Set up groups of eight and have them see how fast they can resolve the tangle.  Look at what happens when impediments occur. How are they resolved?

I have used this exercise with up to ten people in a group, but even with that number it is almost too large for the group to be coherent, and sub-groups can start to be identified.  Try it with very large groups, just to see what happens (dare to fail!) I’d be interested to hear the results.

If you are working in a culture where hand-holding isn’t comfortable, use short ropes or batons between team members.

This game has its origins in the theatre work of Augusto Boal.

Please don’t read this in IE

I have recently become interested in web-design.  Having been a software developer (ahem, craftsman) before moving into training and facilitation work I frequently find that I miss being a hands-on coder.  There was nothing (software-oriented) I especially wanted to develop though, as all my interest and work in the world of Scrum pointed me towards paper-based tools and human collaboration.

But then, a few things occurred, all around the same time: two friends asked me to design/build websites for them, I began creating a web application to run Welfare CSM auctions and I decided to improve the look and feel of my own Agile Thinking site.  Small undertakings, all, but enough to inspire me to read, play and discover the cool world of front-end technology.  One nice outcome of this is the discovery that inside the hacked-up mess we call JavaScript is a beautiful, elegant OO language waiting to be unearthed.  It is quite a joy to work with now.  The main downside of this small venture of mine is the (re)discovery of just how awful IE is.

Why is it awful?  Well, apart from the fact it is bloated and slow, the makers decided to create their own standards (I know, “own” and “standards”, oxymoron, right?).  Almost everything that renders as required in all five of the other browsers I test on (Firefox, Safari, Chrome, Opera and Arora) renders differently in IE — and usually looks a complete mess.  Now there are workarounds, which is good, but it does mean that for every page designed maybe 20-50% of extra design time is spent tweaking and re-testing on IE.  And so accepted is the fact that IE does things differently that instead of fixing the problem, Microsoft have added a proprietary workaround (the comment-buried conditional if[IE] statement).  And no one complains.  Yes it works, but no it is not smart.  It is ridiculous.  And unusable, of course, by any other browser.

It would maybe be acceptable if each subsequent version of IE improved.  But it doesn’t, each version just adds a whole new set of quirks that have to be learned, and supported, and continues to leave out some very basic support

So, in frustration one day I just switched off IE access on one troublesome page of my WelfareCSM site.  I figured that if people wanted what I had to offer they could take the trouble to use a real browser to read about it.  And if they didn’t want to take the trouble, then maybe I didn’t want to work with them anyway.  I also felt it was my duty to educate people that IE was not their only choice (some people do not actually know this).  The IE alert on WelfareCSM redirected the user to the Firefox download page.

This action of mine triggered off a short twitter discussion, which I found hard keeping up with in 140-character bursts, so decided to expand it into a blog post.  I have since re-allowed access to WelfareCSM in IE (for now) but only while I contemplate a more thorough exclusion of IE by all my web apps backed up by a ‘browser discovery’ program.  You see, when things don’t change they tend to stay the same.  And as we all know, change isn’t what someone else does, change starts here, now.

By our current actions –supporting IE– we say to Microsoft, yes what you are doing is okay, we can live with it. We’ll continue cleaning up your mess for you, and spend many wasted hours pandering to your uncooperative spirit, your arrogance and your superiority of market share.

But it isn’t okay, and I don’t want to support it.  My proposed action may be tiny, but it is action, and if done right it could be an interesting experiment. I’d certainly want a way to get feedback from those affected by the IE ban.  Ideas?

Eric Willeke kicked off the original twitter discussion, 4 Nov…

[erwilleke] Ok – I can’t believe WelfareCSM.com actually REFUSES to render in IE… thanks @tobiasgmayer

[tobiasgmayer] @erwilleke I am considering making all my websites refuse to open in IE. Someone has to take a stand

[erwilleke] @tobiasgmayer Even if just frustrates some techies and drive away the “extra guest” types you require on the WelfareCSM? What’s the goal?

[tobiasgmayer] @erwilleke IE==60%++ more webdev time to support the worst performing browser. And everyone should have AT LEAST Firefox, for choice.

[erwilleke] @tobiasgmayer We always saw the flip-side b/c of market share. FF & Safari(mac) had “enough” to justify supporting it, most others didn’t

[tobiasgmayer] More web designers should refuse to pander to IE. Stop wasting time. Shut it down. What will you do with your extra 50% of life?

[tobiasgmayer] @erwilleke almost ALL browsers except IE follow the same standards. Support one you get all the others for free. IE is an arrogant bully

[tobiasgmayer] @erwilleke If a required web page snubs IE and the user is shown an alternative he will likely take it, and voilà! one less IE user

(a couple of RTs…)

[ravinar] @tobiasgmayer Can you explain your “pander to IE” tweet?

[BillyGarnet] @tobiasgmayer “pander to IE”? The reason we care about IE is that a lot of Internet users are using it. http://bit.ly/2WdDGO

[tobiasgmayer] @ravinar yes. IE is a piece of crap, that makes up its own standards. There are many better, trustworthy (and free) browsers available.

[tobiasgmayer] @BillyGarnet (IE) and we have the ability to change that. After all, supporting something because the majority does has a bad track record.

The Agile Playground #2

Agile Playground Index: [AP#1] [AP#2] [AP#3]

Deborah Hartman-Preuss organized a spontaneous (guerrilla) Open Space at the Munich Scrum Gathering, and it gave me the opportunity to run a couple of games.  One of my favorite games with large groups of people is a game I originally ran when working as a youth and community worker with disenfranchised teenagers in inner London.  Turns out this game is very suitable for learning about organizational behavior, and I have been using it in my Scrum trainings for a number of years now.

Movers and Shapers

A fast-moving physical game to explore group dynamics. Participants move around the room attempting to create different formations that rely on the positions of other people… who insist on doing their own thing! It is chaotic, messy and frustrating. It can also be beautiful. I never quite know the what the outcome and learning will be with this game, but during the debrief participants often identify both dysfunctionsal and healthy dynamics at work.

Instructions

Introduce this simply as a warm-up or on-your-feet exercise, to avoid pre-conceptions. The exercise requires an open space, unencumbered by furniture. Participants distribute themselves around the space. There is to be no talking in this exercise.

Part 1: Victim

You are a victim. Silently select one person in the room to be your enemy, and another to be your shield*. Once everyone has done this, each person moves to a position where his shield is between himself and his enemy.

Facilitator: observe what happens in the room, look at the shapes being created, the energy of the people. The group usually breaks up and moves outward. The dynamic here is mostly about blame and avoidance.

* David Harvey pointed out that using the term “best friend” rather than “shield” may be less loaded. Good point.

Part 2: Protector

This time be the shield. Pick an attacker and a victim. Once everyone has done this, each person moves to position himself between the attacker and the victim, shielding the victim.

Facilitator: observe what happens, usually the group will collapse in on itself. The dynamic is one of protection, about covering up the mistakes of others.

Part 3: Egalitarian

Pick two people, and move to a positon in the room so that you form an equilateral triangle with your partners, each of you being a point on that triangle.

Facilitator: note that the group will again (most likely) not come to rest, but the movement will be less hectic than in the first two parts. Eye contact is usually maintained, and implicit agreements made. The continuous movement is indicative of a living system. Static systems are essentially dead systems. If you find this part of the exercise results in stasis, introduce something to upset this equilibrium, and discuss the living/dead systems idea during the debrief.

Debrief

Debrief after each part, as appropriate to your style and according to what you observed. You may also want a general debrief at the end. Avoid making value judgments, and let the participants draw their own conclusions.

The whole exercise will last anything between between 10-30 minutes, depending on the depth of the debrief. I tend to find that exercises like this often speak for themselves and over-analyzing doesn’t add much value. An alternative way of running this is to have 3-4 observers standing on chairs or tables, to observe the patterns and offer insights.

This game has its origins in the theatre work of Augusto Boal.

CSM Auction

What is the CSM course really worth?  Essentially, the market sets the rate.  Trainers charge what corporations are willing to pay.  If the price is too high —as it was seen to be when the recent recession hit earlier this year— classes do not fill up.  Trainers/training suppliers lower the prices until sales start increasing again, and thus establish a new market rate.

The market sets the level that corporations are willing to pay for its employees to be trained.  But what if the employees have to pay for themselves?  The rates would undoubtedly be different, but how different?  I decided to take a first stab at finding out.

I am running my first CSM course where participants can bid for a place in an open auction.  The course will take place in Palo Alto at the end of November. Ten places are up for auction with a starting bid of $100.  The other places are reserved for the unemployed through direct application.

Because this is part of the WelfareCSM program, there is a requirement that all participants pay out of their own pocket, and are not sponsored by an employer. These workshops are not cheap alternatives for companies wanting to train their staff, but are for those who would otherwise not have the opportunity to achieve CSM status.

Applicants can buy a place outright at the approximate market rate of $1,2000. It will be interesting to see how much many take that option. My guess is zero.

The most anyone has paid me for attending the WelfareCSM course is $500. It is my guess that this is about the maximum the bids will go up to. It’ll be interesting to see. Of course, the number of people bidding will have an effect on how high the bids go.

You can watch the auction in progress from here: WelfareCSM Auction. All bidders will use an assigned id so will remain anonymous.

The Inadequacy of Feedback

Or more accurately, the inadequacy of the after-course evaluation process to gather meaningful and actionable feedback.

I facilitated three sessions at Agile2009 in August.  It was a lot of fun, but I found something deeply unsatisfying and frustrating about the Agile2009 feedback process.  This is not something specific to Agile2009, it is a fault of the feedback system we have become accustomed to and, it seems, have never stopped to question.  I guess I have high expectations of the Agile conference leading the way in new thought, rather than following tired, old patterns that are clearly broken.  Too bad that has not yet occurred — but here’s hoping.

In a nutshell the feedback process works like this: The session ends. Participants are given a form, just as they are ready to leave the room to drink coffee, eat lunch or play the networking game.  On the form they are expected to check some boxes on a 1-5 scale against some vague and ambiguous criteria.  They are expected to add comments.  Most do the former, few do the latter (fewer do the latter in a way that is both legible or meaningful).  The forms are anonymous.  There is no space for a follow up conversation.

The value of these forms to me as a presenter (I cannot speak for others) is almost zero.  Participants often give diametrically opposed feedback, so it is extremely difficult to use it in a constructive way.  Different sessions suit different personalities, and there is no way to make everyone happy. I also dislike that the feedback is anonymous as it flies in the face of Agile values such as trust, courage and transparency.

I am sure there are many who can explain from a psychological or systems perspective why this process is so broken and so lacking in value, and I am hoping someone will do so by way of a comment.  I’m looking at it here in a purely personal  way, i.e. how it affects me. I have always felt that such a feedback mechanism not only adds no value, but is actually destructive.

When I read these anonymous feedback forms (written under duress, and mostly as an act of compliance) I have one of two reactions:

1. I am hurt by the criticism.  I feel deflated and wounded. I feel misunderstood
2. My ego is boosted, and I feel flushed with pride. I want to brag.

It is not constructive to dwell in either of these places, and yet this is where I automatically go.  Clearly, I can work on this, and I do, but I reckon that a more meaningful feedback process would help dissolve the two extremes and create a better space for both giving and receiving feedback.

When someone takes the time, in a thoughtful and reflective way to offer me feedback, either in person or in written form, in a transparent way (i.e. not anonymous) I find I have feedback that I can hear, that I can consider, that I can take action on.

These days when I teach CSM courses, or other trainings I don’t hand out feedback forms.  Instead I use a process of continuous reflection, which is done through rich dialog.  Occasionally I have asked for feedback in the form of a drawing, or a haiku. Such mediums tap a different part of the brain —or perhaps not the brain at all— and help people get away from stating the obvious.  I heard of one Scrum trainer who hands out blank sheets of paper at the end of the training.  This is a great improvement, but the participants are still under pressure to write something meaningful in a very short time-frame.

I continue to consider and to search for new ways of gathering meaningful feedback.  I am fairly sure the situation can be improved by getting rid of the anonymity aspect, making the feedback form optional, and allowing participants to take the form away and complete in their own time.

The Agile Playground #1

Agile Playground Index: [AP#1] [AP#2] [AP#3]

This is the first post in an intended series which will describe some interactive games, with commentary.

Scrum offers a completely different way of thinking about the work we do, therefore it seems appropriate that we explore completely different ways of teaching it to people. Playing physical, interactive games is a compelling way of introducing the core Scrum principles to individuals and organizations.  When talking to (sometimes at) participants with or without slides or whiteboards the information is one-dimensional, and tends to be taken in at a head level.  Playing interactive, physical games provides a richer experience and allows knowledge to be embodied by the participants.

Head knowledge tends to coat the surface of our minds, and it quickly fades, whereas embodied knowledge penetrates deeper and tends to stick.  The games and exercises described in the Agile Playground posts are all physical and interactive, and lend themselves to an increased awareness of Agile principals. The set of games described here are as a rough guide only, an introduction to the concept of game-playing for Agile learning purposes.  It is advisable to experiment with these games in a safe, supportive environment such as Open Space before applying them for training purposes.  It is necessary to understand the games for yourself, to appreciate the learning value, to really feel them, before offering them to others.

I see Agile games falling into two categories: 1) prescriptive games where the outcome is known by the facilitator and the game is guided towards that outcome, or 2) open games where the outcome is often unknown and the game takes on a life of its own, with participants drawing out meaning themselves.  It is the latter set of games that I am more interested in.

Go — a game for illustrating the Agile mindset
aka “Your Brain on Scrum”

Instructions Have your participants stand in a circle, evenly spaced.  Introduce the game like this: I shall point at someone; when I point the person will tell me to go, so I’ll walk over to take his space.  In order to take the space the person has to leave it, and the only way to leave your space is to point at someone else. When you point the new person will tell you to go, so you’ll walk over to take his space. And so on.  This will be a continuous exercise with no obvious end point. The game will find its own conclusion.

What Happens? At first the participants will really struggle with this.  They point and say Go , or when being pointed at they leave their space without saying Go, before realizing there is no new place to go to.  It is necessary to stop the game and restate the rules a couple of time. Other behaviors that occur include moving quickly and getting to your new place before the person who said Go has left it, and failure to pay attention thus not being aware when someone point at you.  After two or three stops, and a clarification of the requirements, the game is played smoothly and you can start to build up speed.

Additional Notes 1 I added these notes after witnessing the game being played and somewhat  misunderstood.  This is NOT altogether an open game, there is a very deliberate learning outcome… the recognition that Scrum is simple, but it is not easy.  I learned this game from Improv artist/actor Matt Smith.  Matt uses it to show the mindset shift needed to embrace improv ideas. Scrum requires a similar mindset shift (a paradigm shift if you like).  Go! illustrates the pain that comes with this shift.  It is difficult, but it can be overcome.  We need to re-train our minds to think differently about what we do. Ask people early on in this game why they are screwing up a game that has only (essentially) 3 rules.  What is going on… why is it so hard?  Help participants understand that the difficulties arise when they have to change ingrained patterns.  Scrum is simple, but it isn’t easy.

Variations After running the standard game for a while, try out some alternatives.  Replace the pointing gesture with one of an open hand.  This feels like more of a request than a command. Have no gesture, just use eye contact to give permission.  Play without permission at all, just walk to where you want to go and trust that the space will become available.  Additional Notes 2 Go! can develop into a game about flow, patterns, respect, listening, team-awareness and all kinds of other good things.  But beware.  Mixing up many learning outcomes in one game can be confusing.  I recommend using Go! in its simplest form to illustrate the mind shift required to do Scrum.  Pick the game up again later in the session, (using looks, head-nods, etc.) to focus on the patterns/flow part of teamwork.  Or use a different game.

Debrief Explain that the Agile mindset is utterly different to a traditional mindset, and ask how the game gets that message across.  The participants have a lot to say, so listen and learn.  Some of the discussion centers around the importance of team work, and being aware of the needs of others .  Other times it will focus more on the difficulty of changing the way we typically do things.  If you have used and variations have the participants discuss the different dynamics.

Additional Notes 3 Having written this game, and then seen it played reminds me how hard it is to write these games down, for reproduction.  There is a great deal of skill required to run a game successfully, to notice the learning opportunities and seize them appropriately, without being overly prescriptive.  So again, please use these games with great care — and be prepared to acknowledge your own failure, and improve as a result.

Don’t do XP

Steve Freeman offers a counter-argument on his blog entitled Do do XP.

I am beginning to grow weary of the repeated discussions with the many who insist that Scrum doesn’t work without XP.  Scrum works just fine — if applied with an understanding of the values and principles that are at its foundation. The context you implement Scrum in will determine the practices you need to apply.  Scrum in Church will have a different set of good practices to Scrum in Software, and both will be different to Legal Scrum.

XP advocates are quick to blame Scrum for the lack of good development practices in the software industry.  But given the very slow uptake of XP it could be argued (and I shall do so) that in fact XP itself is responsible for the lack of good practice in our industry.

Throughout the 1980’s and 1990’s, as languages improved and lent themselves to better software design, the way people wrote and tested code changed.  In the OO community at large there was a slow, but spreading adoption of ideas such as continuous refactoring, limited responsibility, driving development through writing tests first (TDD), continuous integration, emergent design, the setting of coding standards and even pair programming.  What the XP movement (essentially Kent Beck and a few colleagues) did was to pull all these good practices together into a package, and bundled it up with the the Scrum patterns that Jeff Sutherland had been practicing at Easel Corporation since 1993.  In a sense, this was the first concrete implementation of the Abstract Scrum class [ref].

All of this is good.  But somehow the adoption of these practices didn’t explode as one might have imagined they would. Perhaps it was the name Extreme Programming; perhaps it was the chief, or loudest advocates proclaiming that this was the one truth; perhaps it was management fearing a geek revolution, and working hard to undermine the ideas.  Perhaps it was because, in the end, XP is just another methodology.  I don’t know.  I do know that very few software development teams in the world claim to be (admit to) using XP.

Scrum in the meantime gained enormous traction,.  Not always for the right reasons, of course, but nevertheless a good percentage of adoptions resulted in some improvement to the way software was being built.  And now the XP contingent want a piece of that pie.  They are hungry.

Firstly, lets be clear.  I am absolutely in favor of software development teams using the software development practices best known to produce high quality code leading to valuable products. Why on earth would anyone be opposed to that?  I am less in favor of dumping a package of 12 things on teams and prescribing a method of working that they must all follow. It flies in the face of “people over process” and the principle of self-organization.  In a good Software Scrum implementation the team members would discover good practices for themselves, and the adoption would become personal and meaningful.  That is the kind of improvement I seek.  That some Scrum teams have not yet discovered better ways of working means that the implementation of Scrum needs to be improved, not that team members should be told how to do their work.

Here’s my thought experiment: how many teams would have adopted all the good practices that XP recommends if XP never existed?  I believe many more.  I believe these practices would have come in a fluid way to individuals and teams, as they came to me as a craftsman who cares about what I make.  I have never “done XP” but I have certainly written quality software.  XP’s mistake is to insist on all-or-nothing adoption.  That may not be what the inventors intended, but it is how XP is perceived.  XP may be the cause of people not adopting good practice.  Ironic, isn’t it?

Another point worth noting is that the XP book was written about 12 years ago, since when around 40 new languages have been created [ref].  That means the XP advocates are recommending people use software practices that are potentially up to 12 years out of date — which is about one quarter the life of our entire industry. Scary.  Allow people to discover good practice for themselves and they may come up with practices far more effective than our best minds could produce at the end of the last century.

I urge Scrum coaches to stop talking about XP and start talking about software craftsmanship.  That is what we ultimately seek and desperately need in this industry.  Thankfully, there is now a software craftsmanship movement with its own manifesto [ref] which is slowly gaining support.  Finally, we can begin to reinvent our industry by following good craftsmanship practice rather than new, fix-all methodologies.

Developers: don’t do XP. Implement a common sense framework to surface all the dysfunction of years, to ground you in core human values, and within that learn to be craftsmen again.  Or get out of this industry.

Scrum doesn’t do anything

A French translation of this article is available on Le Touilleur Express.

“Doing Scrum” is as meaningless (and impossible) as creating an instance of an abstract class.  Scrum is a framework for surfacing organizational dysfunction.  It is not a process and it is not prescriptive.  The core framework of Scrum, as described (e.g.) here and here does not actually do anything.  It is, in a sense a contract we put in place between those seeking value and those building it.  But a contract doesn’t produce anything.  An interface is passive.  We need an implementation.

Scrum begins to work when people understand it well enough to create a concrete implementation, to emerge a process that is their own.  Understanding and respecting the Scrum framework and the set of rules allows you to become aligned with others, to have a common set of values and principles from which to operate.

Scrum itself can be thought of as similar to a set of game rules.  Think chess, think soccer.  The rules are easy to learn, and knowing them means you can play the game with others.  The rules are the ties that bind us together.  But just knowing the rules means nothing in terms of deriving pleasure from the game.  You need to play, to be involved.  It is doing, not knowing that brings about results.  To play well you need to develop strategy, and in team games you need to develop relationships, and trustful interactions.

In any game, once you start breaking the rules everything falls apart, and no one will want to play with you.  It is the same with Scrum.

So respecting the contract, the rules, or in software parlance, respecting the interface, allows you to create a process that suits your context — and your context is many things… people, industry, business, market place, product, location, language, physical environment, culture, people.  It starts and ends with people.  Scrum doesn’t actually do anything, people do things.  The Scrum process will emerge through the interaction of the people, and it will be different for each organization or team.  And this is where people trip up; too many think that creating their own process starts with breaking the rules.  It doesn’t.  Do that, and you have failed before you begin.

The Scrum process being created must operate within the agreed parameters, must be bounded by the rules.  All methods of the abstract class must be implemented, or the class won’t compile, won’t run.  Try to move your bishop in a straight line in a game of chess, and your opponent will leave the table.  Pick up the soccer ball and throw it and you’ll be red carded.

The framework of Scrum is a powerful mechanism for surfacing organizational and personal dysfunction.  It is that very power that causes people to try to circumnavigate the rules, to take shortcuts.  They don’t want to look.  But not looking doesn’t cause problems to go away or broken things to mend, it just delays the inevitable giant crash.  We don’t call out the value of courage in Scrum for nothing.

Comparing Scrum then to implementation practices such as XP or software craftsmanship makes little sense.  Each of these movements offers excellent tools for implementing a solid Scrum practice, for making the abstract concrete.  Scrum offers a strong framework and a relentless rhythm to shake out the dust of years.

You cannot “do Scrum” but you can certainly embrace it, and the more courageously you do so the stronger will be your emergent process.

InfoQ video interview

This interview, conducted by Amr Elssamadisy, was recorded at Agile2009, Chicago. InfoQ do a great job on video interviews. You can follow the text and jump to each new question if you get bored. The transcription sometimes errs though — how small exactly, is a minimized whip?

Link: Tobias Mayer discusses WelfareCSM and Scrum

“Tobias Mayer talks about the philosophy behind WelfareCSM, unbounded vs bounded creativity, the application of Scrum outside of software development, Kanban vs Scrum, the benefits of fast-failing, software development as an artistic endeavour, software craftsmanship and XP, test-driven development, and the done state.”

Just for the record, I have now staged twelve WelfareCSM courses and taught ten of them myself, including three in partnership with other facilitators. The other two were taught by Doug Shimp, who went on to create “Hard Times University”, and Lyssa Adkins, who is currently adapting the model to “Non-profit Scrum”. I have two more scheduled for this year. See the WelfareCSM website for more details.

The first WelfareCSM class, held in San Francisco, was documented here: Joy and Chaos at the Hat Factory.

Scrum Roles — an abstraction

I recently wrote an article entitled Simple Scrum where I attempt to describe Scrum in an industry-independent way.  I was dissatisfied by retaining the names of the Scrum roles, as they seem too industry-specific [more] or at least are loaded with meaning specific to current (often unsatisfactory) usage.  In considering a fully industry-agnostic Scrum, I have recast the roles to their essence.

The Roles in Agnostic Scrum

1. The What Voice
A single voice, possibly channeling many voices, with the aim of defining ‘well formed outcomes’ and prioritizing for the highest possible value in the given context.  The What Voice is also responsible for expenditure and any go/no go decision.

2. The How Tribe
A cross-functional group of 3-7 people who between them contain all the skills necessary to solve the problems given by the What Voice.  Only the members of the Tribe are empowered to make decisions as to how to do the work, requesting clarity and support from the What Voice as necessary.

3. The Joker
An outcomes-neutral facilitator, concerned with fostering a collaborative environment, guiding the tribe towards self-improvement and self-sufficiency, and challenging the containing organization to lead through release and honor, rather than control and mistrust.  The Joker acts as a servant to the team, and an agent of change within the wider organization.

These three roles constitute the Scrum Team; it is the pull in three different directions: profit, mastery and the greater good, that generates the healthy conflict and tension required to reach previously unimagined levels of innovation and creativity, and allows Scrum teams to deliver true value.

There is a fourth role in Scrum, outside of the team, but involved at regular intervals.  The role is essentially everyone else who cares.

4. The Audience*
Everyone who funds, uses or profits from the product, service or idea being created.  The Audience offer feedback at regular intervals, and should contain amongst them a handful of serious critics.

The What is the destination; the How is the pathway

Calling the first role the What Voice and the second role the How Tribe instantly sets the two aspects of creation aside from one another.  For self organization to work a team (or tribe) needs to be empowered, left alone and trusted.  Trusting is difficult when requirements are vague, and empowerment is impossible when the tribe experience continuous interference regarding the technologies, tools and practices being used.

We need a clear separation between what is being asked for —essentially a goal: an outcome of value— and the path we’ll take to get there.  People on the business end of the creative process need to define clear outcomes, that describe audience and value.  As they are likely not developing solutions themselves they need to be completely feet-off the solution pathway, unless specifically invited in.

Looking at the Scrum roles in this industry-agnostic way allows us to see the underlying principles and values on which the roles need to operate to be successful.  It is too easy to get caught up in the day-to-day implementation decisions, and lose sight of the greater purpose.

* I first came across the term “audience” for users and stakeholders in Matt Heusser and Chris McMahon’s recent ST&P article [Volume 6, Issue 10, Oct 2009] Performing the Software. I liked it, and thus borrowed it.  Thanks guys.