At Agile Tour Toronto last November, I conducted a workshop to get crowd-sourced research into high-performance organizational cultures. The purpose of this workshop was two-fold. First, to understand similarities and differences between organizational cultures. Second, to see if case-studies of high-performance cultures would resonate with Agile-oriented people.

The companies that were selected for study were:

1. Zappos – amazing customer service
2. Valve Corporation – everyone responsible for finding a project to contribute to (no hierarchy)
3. Semco – where people pick their own salary and people choose their managers
4. Netflix – where staff are managed like a professional sports team – only the best and non-performers are cut
5. Beyond Budgeting – OK, this isn’t a company, but we used the composite characteristics of companies that move to decentralized control. It’s more about leadership than budgeting.

Each group was given a case study, and asked to summarize the following:

• Key Organizational Characteristics – What did the organization pay attention to and how did it structure itself?
• Business Benefits – What material business results were observed in that organization?

Happy Customers and Engaged Staff

When asked what the key benefits these companies found from their high-performance culture the aggregate results across all companies were happy customers and engaged staff. See image below. We played a short version of the game of 35 to arrive at this result.

With regard to the second goal of the workshop – the workshop participants were very interested and several indicated that they found learning about these cultures as valuable for understanding how to progress with Agile at an organizational level.

Zappos Characteristics and Benefits

I have photos of the results of some of the groups, but the lighting was terrible so it’s really hard to read. Below are the results for one group that was working on Zappos.

Characteristics:

• Focused on long-term vision
• Customer oriented
• Fun and a little weirdness
• Team communication
• Personal and professional growth

Benefits:

• Delighted and repeat customers
• Employee retention
• Long-term growth
• Positive financial outlook
• Better ROI

Acknowledgements

I would like to thank all the participants for working together to understand each organization’s structure and to identify the key benefits. Based on the ratings and comments, it looks like people had fun.

I am very grateful for Thiagi for showing me how to create a great workshop out just some handouts so that I can get out of the way and let people learn directly.

Martin Fowler is among other things the Chief Scientist for ThoughtWorks. He gave an interesting keynote that consisted of 3 mini-talks. I thought it was very effective since it was accessible to those new to Agile as well as interesting for folks like me.

Here are my notes containing the juicy bits:

One problem Agile suffers from is Semantic Diffusion where the meaning of Agile is getting diluted. As we grow, there is increased miscommunication and less understanding. I see this struggle on mailing lists where well-intentioned people sometimes mis-explain things.

Martin then made the case that Agile requires Evolutionary Design. It goes like this: requirements change, so you need adaptive planning and hence evolutionary design. Play the Marshmallow Challenge to experience how this can work.

The next topic (middle of diagram) was about people. He touched on Taylor’s anti-pattern of process-centric view where people are replaceable parts and contrasted this with the research of Alistair Cockburn who classified people as non-linear and variable. Martin suggests that each team must own it’s process and evolution. Not sure how he reconciles this with the enterprise view.

The final topic was on code branching strategies and how continuous integration is the best of all strategies. Heed his call or suffer the despair of code decay in your feature branches.

If you want to get a more in-depth report, check out John Tobin’s blog post or Piergiuliano Bossi’s very detailed post.

Slides? Not sure. If we do get them, the will be linked from the conference website.

Wow! Agile Games Day Workshop! What a great way to end Agile Tour Toronto! Here’s what people had to say about Gino Marckx and my workshop:

• “Fun, Energizing, Informative I liked adjustments during the day to our plan – nice! Facilitators checked in to see where group was at (all day – during games too)” – Alistair McKinnell, Agile Coach
• “Engaging, Fun, Self-discovery High energy personalities in delivery; not sitting all day and mixing the groups up” – Colin Bowern, Technology Coach and Solutions Architect
• “Fun, Engaging, Educational I liked the split from play to how to facilitate; the mixture of games and game lengths; the flexibility to adapt to the needs of the group” – Sarah, Coach
• “Engaging, Fun, Insightful I liked talking about different roles; it was laid back and fun; good energy and inspiring. – Nick Faulkner, Team Lead
• “Fun, Insightful, Amazing We adjusted as we moved through the day and we took longer where there was value” – Alex Aitken, Consultant

Mistake #1 – Too many games

It all started a week before when participants met online to play the Innovation Games® Buy A Feature game to select what games we would play. Gino Marckx and I provided a menu of 20+ games. The prices? We use the number of minutes for a session. It was a public game, so feel free to check out our results or run your own games.

The first mistake was that we had too high a budget when playing Buy A Feature. I had worked out the approximate number of minutes and decided to budget 30% of the time so we would be a little under the total time. Problem was I forgot to change the default from 40% so we ended up with too many minutes.

How would you recover?

Gino and I used dot voting to prioritize the games selected so that we would play the most important ones first. Here is what we came up with. (Note: no votes for team games since we did this right at the start before the voting). The games are listed from top to bottom based on “ROI” (dots/time).

Mistake #2 – Budgeted times off by 40%

As the day progressed, it became clear that the time budgets we had allocated were too low. Way too low.

How do we know this? Well, having just finished a Kanban workshop, I created a control chart to track actual time in comparison to budget time. See photo below.

Root causes?

1. When we were having valuable debriefs we kept going, rather than keep to our timebox.
2. After each game was finished, we had a game facilitation discussion to talk about when you might play the game, setup needed, tips and tricks, etc. People found this very valuable.
3. The games are tiring and people needed more breaks than planned.
4. The two big games – Business Value Game (BVG) and Yellow Brick Road really benefit from having 2 hours instead of 1.5 hours. This is consistent with my earlier playings of BVG.
5. Some of the games we were less familiar with.

The Games We Played

Here is a quick review of the games we played and when to use them. The full list of games is here.

Team Formation and Energizing

Constellations (30 min) is used to share team perspectives around values and beliefs. The information allows team members to help each other through challenge areas and provide hooks to talk about problems. We also played Tribes as a warmup but don’t have a description for this.

MarketPlace (60+ min) is used to inform team members about skills help by one another. This helps on many levels. First, you know where people are coming from. Second, you learn what skills and capabilities they bring to the project. Third, you may notice other things about them that can help the project succeed. Fourth, appreciating skills creates a powerful connection between the team members.

Play these games with all team members when you start working with them.

Product Backlog Management

Business Value Game (90+ min) helps players understand different views of value and think about the challenges of modeling business value. In particular it gets players to think about how to keep customers happy and balance technical improvements with feature delivery. It also hammers home the importance of reviewing acceptance criteria. Play this game with Product Managers/Owners and everyone involved in backlog prioritization.

Emergent Design

Marshmallow Challenge (45 min) helps players understand the benefits of incremental and evolutionary design. Teams that balance planning with experiments and learning about the problem domain do a lot better than teams that do a lot of upfront planning and no learning. Play this game to shift away from Big Design Up Front. This is suitable for all team members and especially important for Product Managers/Owners and Architects/Designers.

Developing Coaching Skills

Yellow Brick Road: Fresh Insights through peer coaching (90+ min) allows people to develop their coaching and observation skills so that they can help one another. A side effect of the game is that people can solve real problems. This is a good game to play with ScrumMasters, internal coaches and managers.

Value of working in small batches

Penny Game (30 min) is a fast and effective demonstration of how customer responsiveness can be improved through delivery of work in small batch sizes. It also highlights the importance of identifying organizational impediments to productivity and selecting high priority stories first to maximize ROI. I like to play the game when introducing teams to Agile and Lean/Kanban – especially to motivate user stories vs. big requirements.

Concurrent Projects delay delivery

Name Game (10 min) shows how delivering to multiple client projects at a time will give the perception of responsiveness but will lengthen delivery times. Great game to play with managers, project managers and Product Managers/Owners.

Multi-tasking reduces effectiveness

Multi-tasking (10 min) is a quick pen and paper exercise that illustrates how multi-tasking reduces the effectiveness for an individual. Play it with managers and team members that think working on multiple projects or multiple tasks is a good idea.

Some photos from our day of play

Business Value Game

Marshmallow Challenge and Marketplace

John Goodsen and I set out to deliver a great one day Kanban workshop as part of Agile Tour Toronto 2010 and we hit this one out of the park.

What People had to Say about the Training

• “Engaging, Practical, Fundamental I liked the flow from concepts to games/practice; moved quickly; teamwork/collaborative learning.” – Alex Zeldin, Manager Planning and Business Solutions
• “Wicked, Awesome, Cool I liked the games and the Q&A session at the end.” – Trevor Ramoutar, Project Manager
• “Interactive, Informative, Practical A very lively workshop – you could feel the experience the trainers have! Thanks a lot.” – Hedi Buchner, ScrumMaster and coach.

Recipe for Success

• Two coaches who have different experiences, points of view and are ready to experiment (See: Agile Coaches are like Superheroes)
• A strong desire to apply Training from the Back of the Room (See: Thought you were a good trainer? Guess Again!)
• A group of motivated learners

How I trained from the back of the room and loved it

If you are unfamiliar with this book, please check out my book review and mindmaps.

Below are the exercises we use from the book. Most of what we used was from Connections and Conclusions. We played lot’s of games for concrete practice. We had limited use of slides (see bottom of page) to illustrate concepts. My overall take is that we covered less and did it with much higher quality.

Introduction

Connections – “PostIt/What’s in it for me?” (p.99)

• Hand draw poster with “What’s in it for me?”
• As people arrive, have them write WIIFM on PostIts with their Name.

Connections – “Think then Ink” (p.98) + Knowledge line

• “Think about what you already know about this topic.  Write three facts on an index card.
• Form a line from most to least knowledgable about Kanban/Agile to least.
• Share your facts on index card with your neighbours.
• In a line from least to most, everyone can share one thing with the class

Lean: Waste & Value Stream Mapping

Connections – Card Carousel (p.106) – 2 minutes

• Pass around cards with topics written on them: Value Stream Mapping, Muri, Mura, Muda, Value, Toyota Production System, Waste

Oops – forgot to integrate cards when reviewing material.

Idea – Would have been good to have people make notes during waste discussion of what they have seen in their workplace and then make a top 10 list.

Flow Basics

Conclusions – same exercise as at the beginning. Wow, what great discussion. People really remember this part.

Closing of the Day

Get Kanban Game

The whole workshop was organized around playing Russell Healy’s GetKanban Game in the afternoon. The morning was all about layering in basic lean concepts followed by a quick intro to Kanban – just enough to play the game. Afterwards, we covered various topics through parking lot (Q&A).

I give the game a thumbs up and will definitely use it again. One important note that John and I clued into is that the game presupposes that people understand breaking work into small batches/tickets and limiting work in process. That’s why we played several games in the morning to establish the basics of flow. See slides for specifics.

Slides

Eating our own dog food

Yes, John and I eat our own dog food. We used Kanban to visualize the work we needed to do to prepare for the workshop. Below is a snapshot of our Kanban board we created in google docs. See Henrik Kniberg’s sample.

Thanks

John and I would like to thank everyone who shared material with us to prepare our slides – notablly Henrik Kniberg, Mary Poppendieck and Jon Stahl.

I would also like to thank Russell Healy for discussions on rule variants of the Kanban Game.

About a year ago I gave this presentation at Agile Tour Toronto 2009 – Agile Executive Briefing – Situational Assessment and 50,000ft view of Agile. DZone finally posted it.

It is interesting to watch oneself after some time has passed. I would definitely keep the energy and the passion. For sure I would speak S L O W E R (Man, I was like a gerbil on speed). I would also drop most of the text as you can see in my more recent zen-like presentations. A lot of the message is very good – I reminded myself of a few things. Enjoy.

Scott Ambler gave the keynote at Agile Tour Toronto this past Fall. As a conference organizer I only caught part of it, but still there were some useful perspectives that I wanted to share. Scott’s presentation is here.

Scaling Factors are about the kinds of things that make software projects more difficult (whether using Agile or not). Each of these factors require additional considerations that are outside of basic Agile practice. I find this a nice way of thinking about project complexity since this directly maps to the challenge with adopting Agile.

There are no repeatable projects.

There are no repeatable projects. I thought that was worth repeating since a lot of organizations still don’t understand that each project has a distinct signature and may require a different approach: Standardization is a good recipe for failure. Reading between the lines this seems to be a shot at PMO’s that are mandated to standardize software delivery.

This fall, I had an opportunity to hear J.B. Rainsberger give an interesting, entertaining and educational talk – Introduction to Agile via Theory of Constraints.  (The same talk was given at Agile Tour Toronto, but my notes are based on an earlier talk at a client site.)

If we think about our software group as the system under study (photo – top left), then the primary measure of productivity is running tested features. (i.e. in production). The key question is how can we maximize our throughput while holding steady or minimizing inventory and operating expense. The theory of constraints is largely about the hunt for the bottleneck in the system. In J.B.’s opinion, learning is the biggest bottleneck. (I usually say communication is the bottleneck but this seems roughly equivalent).

How do we subordinate learning as a bottleneck? Some practices (photo – right) that help are working in pairs, sitting together, using estimates as budgets.

I can’t remember where this fit in, but J.B. had a great example of managing scope that he referred to as dimensional planning (photo – bottom right).  It involved looking at different versions of a car that could be delivered: Lada, Toyota, Lexus. The point is to do a quality job with whatever you do, but you may not do all the features to get a top of the line solution.

A big part of the talk was about using queuing theory to explain TDD, BDD (photo – left). J.B. has a write-up that covers part of the talk on his website. It is a nice explanation although it does stretch a bit thin from my understanding of queuing theory.

BTW, one of the best parts of the talk is watching J.B. at work with his tablet laptop which he uses like a gigantic whiteboard.  It’s a way more dynamic than slideware.

Below are the slides from my first presentation at AgileTourToronto. This is a new one I prepared to communicate Agile to C-Level Management.

Agile Executive Briefing – Situational Assessment and 50,000ft view of Agile

The first part of this presentation is a situational assessment of typical challenges in IT project delivery using the SCRAP (Situation, Complication, Resolution, Action, Proof) model. This is essentially a business case for Agile. So if you are looking for ways to get buy-in for Agile, then this is a good place to start.

The second part of the presentation shows you what Agile is from 50,000 ft. From this high up, we’ll be covering the essential elements from a business and management perspective. We’ll cover what Agile is, what it does, how it works and what it achieves.

Each of the parts can be used independently so you may use the first part to get buy-in or the second part as a high-level introduction.

Slides on Slideshare

Below are the slides from my first presentation at AgileTourToronto. It is based on ideas from Alistair Cockburn (among others) and has been a work-in-progress since I started sharing Agile ideas in 2002.

Presentation Overview

There are a lot of choices and alternatives for getting started with Agile. It can be confusing. This talk will give you a brief guided tour of Agile methodologies so that you have some understanding of how they are similar and how they differ. We’ll cover some of the history of iterative development and waterfall as well as the Agile Manifesto to provide context. At the end of this, you will have an understanding of key principles and the Agile landscape.

Slides on Slideshare

A Gentle Introduction To Agile

Agile Tour Toronto 2009 is over and it was an outstanding success! There were 150+ participants, 17 great speakers and lot’s of learning and sharing.  It is really great to see all of our efforts as organizers come together in an amazing conference.

On a personal note, I met lot’s of new people and had a number of interesting discussions and exchange of ideas. We are definitely going to do something for next year and make this an annual event to grow Agile in the Toronto area.

All the presentations will be appearing at DZone over the next several months.  To cover this gap, we are going to publish whatever slides we can directly on our website.  Mine are here: A Gentle Introduction to Agile and Agile Executive Briefing.

Thanks to everyone who helped make this a big success.

Partner Workshops

On Monday and Wednesday, I had the privilege of training together with Yves Hanoulle to run two Agile workshops: KickStart (XP) and Games Day.  It was a great experience for me and for the participants.  Pairing works.  Even for training and coaching.  Who knew?  Yves, i guess So, now I am actively looking to pair with other trainers/coaches.