One of the workshops I run is to help team members understand root cause analysis. I use it with operations teams as well as product development teams. My workshop goal is to have people leave with a basic understanding and some practice.

I created the diagram below to situate this workshop in a larger context of Kaizen (Continuous improvement).

One starting point is with a team using a Scrum board or Kanban to create BIG visible information. This supports teams in identifying problems or waste to stop the production line and investigate the problem using root cause analysis tools. I introduce two tools and have the participants practice with each:

• Ask Why five times – powerful technique for drilling down into problems.
• Fishbone (Ishikawa) Diagram – looks at the big picture around the problem.

Both of these improve quality to help teams go fast. 5S (sort, straighten, shine, standardize, sustain) is also totally applicable for software – it’s called clean code: coding standard, refactoring, etc.

Finally, the foundations for Kaizen and root cause analysis are:

• NO BLAME. Most problems are related to the system, not individuals.
• Team work and trust. If 100 people each help find 1% improvement, this will be sustainable.
• Genchi Genbustsu – Go and See.  When you work on a problem, go to the source and get the facts for yourself. Root cause is about investigation and problem solving – see and think for yourself.

If you want to learn more, check out Implementing Lean Software Development: From Concept to Cash or Toyota Production System: Beyond Large-Scale Production.

Workshop Slides

Here is a slide deck I have used in training. It’s from last year, and would benefit from a refresh to cut down on the text – still very usable. As usual, you are welcome to use this as well as the diagram under Creative Commons license.

As a trainer, I have become increasingly convinced that games and simulations provide an excellent platform for learning concepts and new behaviours. I am playing and training with more and more games than ever before. It was getting hard for me to remember all the games and decide which one to use in a particular situation. (Can someone please create a public website where we can list games, rate them and tag them by the problems they solve?)

Where Games Play

Here are some of the games that I am currently use or want to use in training.

What’s with the grid?

• People – games about people learning individual skills or learning about individuals
• System - games about the team or organization
• Concepts - games primarily about teaching concepts or ideas
• “Experiencing our reality” - games the help us understand ourselves and our context

Links – People/Concepts

• Multi-tasking (10 min)
• Collaborative Origami – collaboration & communication (15 min)
• Yellow Brick Road: Fresh Insights through peer coaching (90 min)
• Pair Draw (30 min)
• 99 Test Balloons – acceptance testing (30 min)
• Go! – Your brain on Scrum (10 min)

Links – System/Concept

• The Biggest Bang for the Buck – backlog organization and prioritization – (60 min). Game I created with Gino Marckx will be released around Agile2010.
• The Backlog is in the Eye of the Beholder – organizing backlog from stakeholder view (40 min). Game I co-created at Deep Agile.
• Business Value Game – helps understand differing sources of value. (90 min)
• Marshmallow Challenge – understand benefits of incremental design (45 min)
• XPGame – Scrum variant – basics of iterative development and acceptance testing (180 min)
• Penny Game – Flow of value, process improvement (40 min?)
• Bottleneck Game – understanding process and applying theory of constraints (90 min)
• Name Game – Limit concurrent projects (10 min)
• Movers and shapers – team dynamics (10 min)

Links – System/Reality

• Ball Point Game – process improvement, teamwork – simpler than penny game (40 min)
• Value Stream Mapping – hmmm. not a game really
• Leadership Game – self-organization and leadership styles (180 min)

Links – People/Reality

• Constellations – Share team perspectives (30 min)
• Improv Games and Hypontizing hypnotist – Get better at collaboration and innovation (10 min to ?)
• Yes, And (not Yes, But) - Shift your mindset towards collaboration (15 min)
• MarketPlace – share skills with team members (30+ min)

Other thoughts

Please draw your own maps and share them!

Other games

I did not include games that have are designed to achieve and outcome such as  retrospectives, planning poker or Innovation Games® since the primary purpose is not training/teaching. These are important too.

Happy to be finally attend InnovationGames in Chicago, July 15/16.

Cross-training charts (also skill training charts) are a standard part of the Lean toolkit. They are used to identify limited skill sets that can lead to bottlenecks and work stoppage.  See manufacturing example.

In Scrum (and some Agile), we have the notion of cross-functional teams and place value on generalists who can go where the work is. Cross-training charts can help get you there.

Technology and Domain skills

When helping teams assess themselves, I separate technology skills (who knows a library or tool) from domain skills (who know the frazzit module). Once teams do this, the lightbulb goes off – “Oh that’s why it takes so long when we need to do work on the frazzit – only Bill knows it and he is busy with other stuff”.

On the left is a legend I have used with a couple of wiki-enabled clients to track the matrix. (Excel works too and has a nice colouring feature under conditional rules but is less visible.

Consider the example cross-training matrix below for the developers. (QA, BA important too, but they have different technologies/skills). Across the top we have the names of the developers. As you can see, on the front end, they have an OK idea how to use SpringMVC and JSTL; there are no experts, though, so it may not be clear what their frame of reference is. Sometimes people don’t know what they don’t know. Very limited experience with UXD (User eXperience Design) which may be an area for attention depending on usability goals for the product.

What about the domain matrix? Well, it looks the same but with areas of the application outlined at an appropriate level of detail. You can put the whole team (not just dev) on this one.

Lottery/Truck Factor – Are you managing your risks?

Truck factor is about how many people on your team can be hit by a truck before you can no longer effectively support a piece of software.

The cross-training chart can be used to assess how well management is managing risk. Usually what I see is “not at all” and the result shows in terms of deteriorating code quality due to departures and growth.

How to spread knowledge?

There are lots of ways. My favourite is pairing. I also like to impose a limit on publicly declared learning goals – just pick one thing to learn at a time to provide focus.

My suggestion: give your team time to share knowledge and let them decide h0w they want to do it.

Footnotes

• I keep talking to people about this so I thought I had better post on it. Most recent discussion was at a session at Agile Coach Camp in Waterloo.
• See complementary practice of Timeline and Marketplace for understanding other team members.

Here is a very short (2 min)video where Selena Delesie and I reported back on a session at Agile Coach Camp Canada. This is what a group of 10+ of us came up with.

I’ll link to the writeup when it is posted.

Thanks to everyone who was there – it was a fun, intense and valuable session for me.

For years I have preferred Scrum as a starting place rather than XP since it is easier to adopt. One of the patterns of Fearless Change is to take small steps. Scrum is a much smaller step than XP. That’s old news. Lot’s of folks like to start with XP, that’s OK by me.

Probably a good thing to clarify at the start is that Kanban is part of the Agile family of processes.

Kanban is easier to adopt than Scrum

Way easier. Like almost trivial. Let’s see: no process change, no role change, no change in team structure. Just make the work visible. Wow! There is so much value in just making the work visible. Lot’s of little problems can be fixed and voila – productivity and cycle time gains.

Kanban uses Kaizen = Continuous Improvement

Kaizen is about continuous improvement. Define a standard process and then start improving. Take smalls steps. Get everyone involved. Kanban is a standardized process flow that starts with the existing process.

In the graph of performance vs time on the left, kaizen will result in improvements that will asymptotically approach the limit within that paradigm.

As teams mature, they may go beyond this into the place where Scrum/XP start…

Scrum/XP is Kaikaku = Radical Overhaul

Kaikaku is discontinuous improvement. It is about a revolution in the way things are done. It is also called Breakthrough Kaizen.

Can anyone say Scrum or eXtreme Programming? It changes work groups, job titles, roles, and project basics. For contexts where Scrum is a good fit, it is a high-value, high-cost game-changing move. James Shore has a great post on Kaizen and Kaikaku where he argues that this is a better starting place if you want a high-performance team.

What does this look like in terms of performance? See graph below. It looks like Virginia Satir’s Change Model.

In the Lean world, companies use both kaizen and kaikaku depending on circumstances as they are complementary approaches.

Why a gateway drug?

The gateway drug theory states that softer drugs (Kanban) can lead to harder drugs (Scrum, XP). This is a great metaphor because this theory has been proven as well as dis-proven. To quote David Anderson “we are only beginning to understand the differences between Scrum and Kanban”.

Do I believe in the the theory? I’m not sure that I care – as long as people are working to improve their work environments at a pace that works for them, that is good enough for me. For me, any Agile is good –  it does not need to be one particular style.

Let’s face it – lot’s of organizations are ready for a radical overhaul. For companies like these, Kanban is a great place to start. Getting off the sofa and going for a marathon may not be a good idea. For some it may be better to start by jogging around the block.

Other Perspectives

David Anderson has a contemporaneous post (go read it, it’s good) supporting the notion that Kanban is primarily focussed on continuous evolution until the organization has enough maturity for more radical changes.

Ken Schwaber is continuing the drum beat that Scrum is the one true path.

Alternate Title: Organize and prioritize your personal projects.

I keep my life sane use David Allen’s Getting Things Done (GTD) together with the Pomodoro Technique. GTD is great for managing the little stuff (like email) and Pomodoro is great for managing and prioritizing projects.

I use Index Cards for managing the Pomodoro Technique

For each activity, I use index cards (like story cards). The one in the photo has a title and two boxes – each represents a pomodoro which represents 25 minutes of uninterrupted work. In the example on the left, I am estimated that writing the blog post will take about an hour (two pomodoros).

You may be wondering what those blue and green squiggles are. Like on Agile projects, I annotate cards with themes to help with organizing them visually. On the left you can see the legend for my personal backlog. It ranges from Blue Sky (future oriented) work on my Agile Coaching Company to foundational work that has to get done or will improve my productivity.

I plan based on importance, urgency and balance

When I plan each day, I like to see some balance between themes to make sure I am looking after all my interests. Themes are an easy way to organize my backlog.

What about prioritization? Thanks to Gino Marckx for designing the Quadrants of Effectiveness Game, I use Stephen Covey’s quadrants and the Eisenhower method of prioritization. All you need to do is to scatter your cards according to Importance and Urgency. See photo below.

There is one pile of cards under CSC (hence the big box and the elastic band – like an epic). How did this work out for me? It was a good way to get started when I felt like I had too many choices. So, the next time you feel overwhelmed, perhaps, you may think of this post and take a step back to organize and prioritize your work.

What’s this business about 11?

I am using this to indicate that this is an add-on to get extra milage out of the Pomodoro Technique. See cultural reference for details on where this comes from.

Confessions

This is where I come clean on where I slack on Pomodoro Technique. I do allow interruptions since they usually have high value. I also don’t track them either. I have done so in the past, however, I don’t find it particularly critical for me. So there. So maybe my knob only goes to 1.1 …

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.