I am really excited to have two sessions accepted at Agile 2010 in Orlando. As I am a big fan of pairing to get high quality, I am happy to say these are both pair-designed and will be be pair-led with other great coaches.

The biggest bang for the buck! Strategies to organize & prioritize your backlog – with Gino Marckx is an introductory tutorial and simulation that is part of the Product Management Stage. (Dry run at XPToronto meeting in June)

Look before you leap – Agile readiness assessments done right – with Gerry Kirk is an expert-level workshop that is part of the Agile Adoption Stage. (Dry run at Agile Coach Camp Canada) Check out the program links for more details.

I would like to thank everyone who provided input on the draft sessions in the wave, as well as the comments from reviewers. Oh, yeah, and a big thanks to Gino and Gerry for partnering with me on this.

BTW, there is no official Agile 2010 Speaker logo that I am aware of – I made up the one above

I recently attended a ThoughtWorks QTB – Rapid, Reliable Releases (AKA It’s not making money until its in production) by Rolf Russell and Andy Duncan. It was a solid presentation around the importance of managing environments effectively.

I will walk through the diagram below starting with …

a reliable continuous integration system creates a foundation for rapid reliable releases. It provides early integration and gives the teams rapid feedback on how they are doing. Everything else follows from this.

A key ingredient for successful management of production and other environments is collaboration with dev and ops. There is even a new type of role appearing – DevOps – that handles both development and operations. Either way, someone needs to champion this important interface.

The next topic was about using value stream mapping to see what it takes to actually get something into production (I heartily agree with this approach as I have found it very effective). What we often see as a result is that the work is optimized for each department and is not aligned with the best needs of the whole business and there are lot’s of delays and handoffs.

The next step is to envision future state - what items can go in parallel to get feedback as soon as possible. In one environment is was functional testing, performance testing, and UAT.

A practical idea is to use the cloud for scalable parallel Continuous Integration. In this situation we need lot’s of computers for a short burst, so this lines up nicely with the cloud’s pay per use model and lets testing go really fast.

The final bits of advice were around creating deployment recipes that go with the code (including database changes). In order to accomplish this you will need to create consistent environments and encapsulate differences (such as number of servers, specialized hardware, etc). Once you explicitly handle all the risky bits, then it is easy to support reliable and automated deploys.

If you haven’t done this sort of thing before, then it may seem like a lot of work. For me, it’s seems just normal. I personally implemented a lot of this when I worked at a startup in 2000 and have been using it ever since. I can say firsthand that work on this really pays off.

Video is available on InfoQ.

Subtitle: How we created and played a brand new game all in one day.

On Day 2 of DeepAgile, Michael McCollough and Don McGreal got us started on with a game design workshop. From there we used open space to invent and play the game with other attendees. This blog shares what we learned about product backlogs and game design.

Getting started: A room with a view

The first job in open space was to create 3 consecutive session in the open space (one for each of: objectives, design and play – see photo). I announced that each open space session was independent and that people could attend just one or all – we would do a re-start at the beginning of each one. Working and collaborating with others – what a great way to use Open Space.

I scoped out an amazing room at NERD with a round table, ceiling-height whiteboard and a spectacular view. Perfect for inspiring a team and encouraging collaboration.

Learning Objectives: Keep it simple

We started with a long list of learning objectives at the end of Mike & Don’s workshop (see photo on left). We knew this was way too long and had it winnowed down to the three within the next hour (see photo on right). By the end of the day we had stripped it down even further to just the first objective: there are multiple ways to represent a backlog. KISS strikes again.

The Problem: Product Backlog Management has challenges

The starting place was to help product owners to organize and prioritize their backlog. We spent discussed the topic for a while to get on the same page. We figured out there are a whole bunch of steps involved in building and maintaining a backlog (See diagram below):

1. Identify Stakeholders
2. Identify work (Stories)
3. Estimate work (units, T-Shirt sizes); identify risks
4. Organize & Prioritize <– Focus of our game is on organizing
5. Communicate
6. Execution & tracking (Release burndown/up)
7. Re-prioritize

(We had a great diagram on the whiteboard but can’t find it. So I redrew it from memory and added some flourishes.)

The simple act of preparing brainstorming objectives for the game led to a better understanding for all of us on the full life cycle of a product backlog. The big picture allowed us to focus in on one part: organizing and prioritizing. Even this was too big! We split approaches and concepts into ones that were more about organizing and ones more about prioritizing. At this point we had three game concepts:

1. The missing stakeholder game – who are my stakeholders and why are the missing? (prioritization)
2. “Malfunction at the stakeholder junction” – AKA the dysfunctional stakeholder game. “I want this.” “No, I want this.” (prioritization)
3. The Backlog is in the eye of the beholder – all about organizing based different stakeholder perspectives. (organization)

We did a strawman vote and there was a clear consensus around moving forward with the last one – on organization of the backlog.

Working together on the game

It was fun. Really fun. I played the role of product champion and facilitator.

We started with the Pomodoro Technique to stay focussed and on track (yes, I even drew tomatoes on the whiteboard).  In the design session, we got into a state of flow and just kept going to meet our timebox.

We had to deliver a game since it was announced and on the open space board! As my thesis supervisor said – “Nothing concentrates the mind like a deadline.”

We did lot’s of brainstorming. Everyone was really good about coming up with ideas and letting go of ones that weren’t working out. One idea Greg Ott came up with was that of a garden (see photo on right). After a while this turned into the the farm metaphor we decided to use for the game. In retrospect, having a huge wall to keep ideas alive was invaluable.

Playing the Game

Playing the game was a lot of fun. You could feel the energy in the air (see photo) and the room was packed with designers, players, and observers. We got mostly very positive reviews.

You can find the game rules and feedback here: Backlog is in the Eye of the Beholder Game v0.7 This is our current version and it is supposed to be published with Deep Agile Open Space notes. Feel free to use and make your own.

Thanks to everyone who designed, played and supported us. Special thanks to core co-inventors: Warren Elliott, Greg Ott, Mary Gorman, Dan Zaino, Judy Rivais.

(This is part of a series on DeepAgile 2010 Games Weekend).

Michael McCollough and Don McGreal ran a valuable workshop on how to create your own game. Mike and Don have been creating simple, fun games for years and have noticed an approach they follow. See TastyCupcakes for lots of great games. As a caveat, they outline one particular style of game development – simple games. This is in contrast with complex games such as XPGame and Business Value Game (which are favourites of mine).

It all starts with a problem. What do you notice going wrong? What do you want your teams to understand better?

Next come your objectives. Pick one to three things that you want the game players to learn.  For extra points you may want to consider the Dreyfus model or Bloom’s taxonomy. These were suggested by attendees. Mike and Don keep it simple.

For a while you will need to spin and loop around as you search for an idea. As this happens, it is helpful to be constrained by some principles: stick to objectives and keep it simple (KISS). Inspiration will come from material (cards, balloons, etc), as well as games in other industries. Their mantra is “Beg, borrow, steal” and them make it your own. Learn from your participants – they will tell you a lot if you listen.

Finally, summon the courage to try it (or just do it). Start as soon as possible and iterate.

And remember, the whole point is the debrief. Give ‘em space and let ‘em discover.

(This is part of a series on DeepAgile 2010 Games Weekend).

Tobias Mayer led a fun and effective session (Agile Playground) at DeepAgile where we played games for building team and collaboration.

Movers and Shapers for team dynamics

I first played this game with Tobias at Agile 2009 and found it very powerful for teaching the impact of our behaviours on team dynamics. There are three rounds of simulation with different focus on how to interact with others. A detailed write-up of the game is on Tobias’s blog. Very handy for shifting thinking and focus to team behaviour.

Hypnotizing Hypnotist for pairing and collaboration

This is a very cool exercise to provide participants a sense of directing, following and collaborating. The group is formed into pairs. One person is the hypnotist and guides the other person with their hand. The hypnotizee’s job is to keep their face 1 foot from the hand of the hypnotizer (see Tobias hypnotizing on left). Debrief. Roles are reversed. Debrief.

Now it gets really fun. In the next stage, pairs hypnotize each other at the same time (see Lyssa and Tobias on right). This generates some laughs and interesting behaviours. I think we also ran it with one half of the room at a time so we could see what was happening. Remember to applaud.

Other stuff

There was other really cool stuff I am skipping over:

• Failure Bow – give people the freedom to take risks and recover from mistakes. This allows them to be available and productive rather than discouraged and disengaged.
• Pair storytelling – One person puts their hands behind their back and the other stands behind them and becomes their arms and hands. Once a story topic is established, the participants get to tell a story together with the hands leading.

(This is part of a series on DeepAgile 2010 Games Weekend).

Lyssa Adkins ran a very practical session at DeepAgile that shared several tools for team formation or for tuning up existing teams. She often uses these right at the project start since team members may know very little about one another – even if they have been working together for years. Here is a run-through of three of the exercises.

Constellation – Understanding each other through motion

I love this exercise. It provides the team members as well as the coach important information about everyone on the team. It is called constellation since everyone arranges themselves around an object on the floor (in our case a roll of tape) depending how they feel about a statement such as “I like getting results”.  People align their bodies with the statement: standing beside the object signifies strong agreement while standing far away to signifies strong disagreement. It is very powerful since people are engaging their whole bodies. To learn more, there is a full write-up on Lyssa’s blog.

Timeline – sharing our pasts

In timeline, each participant draws a timeline of their life with peaks, valleys and major life events. In turn, each person describes their timeline to the team. Team members listen and note skills or talents (on sticky notes) that stand out. These are then posted at the bottom of the timeline and reviewed as a team. This approach is about figuring out who the person is and what special perspectives they bring to move the project forward. When we did this, it helped the demo subject feel more positive about their talents. Nice.

Marketplace – sharing our talents

In marketplace we pretend we are a vendor in an open-air market place and decide what wares we have to sell. What are our special skills and talents that pertain to this project? We even get to create a banner to attract people. Under the table are things that are true for us, but may not directly relate to the project. The debrief is the same as timeline. Usually a coach will use one or the other (in the training session half of us did marketplace and half did timeline).

Below is my marketplace as an Agile coach.

(This is part of a series on DeepAgile 2010 Games Weekend).

At DeepAgile2010 this past weekend Mike McCollough led a session on Retrospective Games. We played a brand new game called Balloon Madness as an excuse to use several different retrospective formats. The game is in the conference booklet but is not yet posted on TastyCupcakes (check site for lot’s of fun Agile learning games).

What I learned about retrospectives

• Change the format on a regular basis. One attendee switches things up every retrospective.
• You can get great results by focussing on more of what works. This is inspired by appreciative inquiry. We are so used to looking at what the problem is, that looking at success can have a powerful shift.
• Another was to have each person write a personal commitment story card for something to do in the next iteration. They signed the card and someone else agreed to pair with them on it to provide support. The cards were posted beside the scrum board as a reminder. They were reviewed at the start of the following retrospective.
• Liked-Lacked-LongedFor was also suggested as a powerful way to connect with people’s deeper selves.

At DeepAgile in Boston, I played Yellow Brick Road: Fresh InsightsThrough Peer Coaching. The game was led by it’s inventor – Portia Tung who did a great job even with a very large group. If you haven’t played this, I suggest you make the time.

The game teaches people skills and resources to be effective coaches by practicing with peers. In the game, people take turns in one of 3 roles: Client (with a problem), Coach, and Observer.

Solve real problems

In the role of Client/Dorothy, you get to be yourself and bring up a problem that you want to work on. Over several iterations, new perspectives help you access the resources you already have. So a cool side-effect of this game is that you get fresh insights into whatever problem you want to work on.

Coach practices questions

The coach gets to practice listening and asking questions. We discovered that listening is something we need to practice since we are so used to jumping in with our expert opinion and solutions.

We also get practice with different types of questions (image by Portia Tung):

Observer provides depth

The observer roles gives you a chance to step back from the situation and really notice what is going on. Portia’s picture captures the simplicity of the task:

I was reminded that observation is a very helpful debugging technique. It is also less than easy – especially if you are like most of us and out of practice.

As the observer, I was able to get much deeper insights.

Go play this game

I am going to play this game again for myself and to help those I am coaching. The complete game instructions and presentation is available for download, so give it a go! I’m sure you will get value out of it. Even better, get Portia to come play with you so you can see some of the finer points.

(This is part of a series on DeepAgile 2010 Games Weekend).

Alternate Title: A model for understanding Scrum and Kanban

(Cool diagram below – skip down if you are in a rush

As I flew home after LSSC10, I wondered how Kanban-style software development would shape my world in the years to come. I self-identify as an Agile/Lean Coach and wondered what the road ahead looks like for me.

Someone at the conference commented that Kanban was going to dominate discourse in our community. Some people in the Kanban community say it is more widely applicable and is a more rigourous approach. Another commented that software processes historically have a 7 year run and so it is time for the age of Scrum to wane. The arguement goes that even if Kanban isn’t better, the community needs a new buzz to keep things going. All this made me wonder.

Is this true? If it is true, what does this mean for me? How can I reconcile this with what I know works? Before we delve deep, I need to share where I am coming from.

I use Agile

I have used Scrum for many years as a starting point for Agile transitions. It is compact, creates visibility, and builds a team culture. I also use XP practices.

I use Lean/Kanban

I have been using Lean concepts for many years and very heavily in the last year. I have made extensive use of Kanban-style Scrumboards as well as pure Kanban boards for business and support groups. I have had great success with other tools as well: root cause analysis, the A3 technique, and value stream mapping. This winter, I implemented Kanban with a 18 person software group and shifted behaviour with a cumulative flow diagram.

For me, Agile includes Kanban

When I read the Agile Manifesto and principles, I don’t see anything that excludes Kanban. All the XP technical practices still apply – perhaps even more so. Scrum notions of Product Owner, Product Backlog, and Retrospectives still hold value. Iterations may be gone, but they have left a trail of useful concepts of tools that the Kanban community enjoys. Maybe 80% is the same. Why am I making this point? Some proponents on Lean and Kanban highlight the differences rather than relationships: “Kanban is new!” “We are post-Agile” – as if that were cool. Our community is better served by focussing on the positive in every approach.

What I learned at LSSC10 that shifted my thinking.

At LSSC10, I started noticing contexts – what environments and circumstances encourage Kanban-style Agile.

Support Kanban What blew me away was a keynote case study on Kanban turned out to be about a couple of support groups who figured out that Scrum is not a good fit when there are lots of interrupts and emergencies. Ah, um, … not really news. This is the canonical case for Kanban.

Naked Planning or using XP for single-piece flow is about creativity and cross-functional teams swarming work (MMFs). The context here appears to be a team with a lot of focus working on innovations. This is much more similar to Scrum/traditional Agile rather than Kanban.

(Vanilla) Kanban Mike Fitterman and Rick Simmons of Constant Contact told the story of how Scrum wasn’t working out. Two development teams shared QA and product people and found there was too much planning and communication overhead. (Ooops, sounds like ScrumBut.) Anyway, the context in which they applied Kanban was with one with specialists and group that was too large to be a team.

Vale Kanban Alisson Vale described an environment with small work packages that come from a variety of demand channels. (See also video). It very much sounded like system evolution rather than discontinuous innovation. Interestingly, his model does not follow work decomposition by role but rather allows flexible routing and story swarming much like XP.

Production Line Kanban and (Vanilla) Scrum Most insightful of all for me to outline contexts was Clinton Keith’s session on video game development (go read it). He used a timebox for creative work both with takt-time in production-line style Kanban and with Scrum during design and problem solving phases. So, in this situation, they see Scrum for exploration and Kanban for cranking stuff out.

Scrum and Kanban fit different contexts

• Kanban can handle a lot of interrupts
• Kanban supports specialized roles with divergent skill sets
• Kanban excels at repeatable work such as a production line
• Kanban works fine for groups larger than 7+/-2 since communication and planning overhead is lower

• Scrum excels at projects requiring deep collaboration and innovation
• Scrum works best with small cross-functional teams (7+/-2)
• Scrum is great for providing shared goals and work context
• Scrum encourages generalists

For a more comprehensive list of similarities and differences see Kanban and Scrum – making the most of both. See also Jason Yip’s recent observations.

A model for thinking about Scrum and Kanban

I am a visual thinker so I need a picture to put it all together:

• The vertical axis differentiates environments with a strong focus from those with many interrupts and divergent needs.
• The horizontal axis indicates the spectrum from defined, repeatable work to exploratory and innovative work that benefits from swarming.

Every process has a sweet spot

I have indicated where I see various process styles play best. (For example, Scrum is good when there is focus and exploration.) The dashed lines suggest  that these are not hard boundaries. The regions and shapes are more illustrative than literal.

In this model, Kanban is at centre stage. I have repeatedly witnessed first hand that Kanban is very easy to implement and provides great benefits.

I also have seen the value in creating small, focussed teams using Scrum. For sure it is harder and yet very rewarding. On the downside: it doesn’t fit all contexts.

In truth, I am not 100% satisfied with the fidelity of this model, however, it helps me understand how to approach work with my clients

We need to know both Scrum/XP and Kanban

If all you have is a hammer, everything looks like a nail.

What tools do you have in your belt?

Henrik Kniberg gives the metaphor of comparing a knife with a fork. Which one is better depends on the situation. We need need to know both Scrum and Kanban. XP, too, but that goes without saying.

As an Agile coach I need to understand a client’s situation to know whether to start with Kanban or Scrum or both. Miyamoto Musashi – a famous Japanese Samurai spoke regarding choice of tools – said “You should not have any special fondness for a particular weapon, or anything else, for that matter. Too much is the same as not enough.”

Let’s build community

For my Scrum and XP friends, Kanban is here to stay and it is going to continue to grow; let’s embrace it and help mature it.

For my Kanban friends, let’s build bridges and create a strong inclusive community.

Hungry for More?

• Kanban and Scrum – making the most of both by Henrik Kniberg and Mattias Skarin
• Kanban by David J Anderson (Just released)
• Scrumban – Essays on Kanban Systems for Lean Software Development by Corey Ladas

Thanks

Many thanks to Jason Yip for helping me refine my thoughts and to Siraj Sirajuddin for getting me to attend LSSC10.

What do you think?

The picture I am painting may be missing something. Please share comments or get in touch with me directly to build a better model.

Alternate title: Most Scrum teams need a Kanban board

I am a big fan of Scrum, however, the notion that there are no interruptions during a sprint is simply not realistic in many environments – especially teams adopting Scrum.

Let’s dream of perfection

A key concept from Lean is to dream of perfection. In this case, perfection is “no interruptions”. This is good as a goal but not as a starting point.

Deliver Value

Let’s face it, there is a lot of business value in keeping a production environment up and running. Almost universally, this is more important than getting that new feature out. Unfortunately, this value is usually a form of waste since there may have been things that we could have done to avoid production issues in the first place. It even has a name: failure demand. When we dream of perfection, we dream of zero production issues.

Oops. We live in a world where there are external events. Yep. It’s true. Even Scrum teams. Maybe it’s more useful to drop a story or shallow out some functionality when some important external interrupt happens rather than abort the entire Sprint.

Ken Schwaber told the story of getting kicked out of a client close to home for attempting to veto the company picnic in favour of focus on the Sprint commitment. I keep telling the teams that they are part of a bigger picture and they need to be in tune with that.

I follow the rule of letting Product Owners swap out unstarted stories for new ones if the team agrees. This comes from XP. Darn, broke another Scrum rule in order to maximize business value.

A separate support team is an anti-pattern

I keep getting asked – hey, can’t we have a separate support team?  Then there won’t be any interruptions. NO! Funny thing is that most technical folks don’t want to be on the support team. But the main reason is that it is very useful to have people developing software fix their own bugs and appreciate what it takes to get something working in production. Otherwise defect rates will climb steadily and that’s the wrong direction to go. We want zero defects, not more.

Most Scrum teams need a Kanban board

For as long as I can remember most teams I have worked with have had a support board where we track the actual hours spent on support. Why actual hours? This gives us history and the ability to predict support workload – very handy information during a Sprint Planning Meeting.

More recently I have used a Kanban board for managing support issues.  See sample photo below.

So now, my thinking is that most new Scrum teams probably need a Support Kanban. How about at your company?