I learned in the last month that I don’t know what XP is.

As it turns out, I don’t really know what Scrum is either.

This is a good thing.

No, I am not on crack. Let me say more.

Putting my foot in my mouth in public

I made the unfortunate choice of selecting this post for submission through the Scrum Alliance: 5 Ways Scrum Creates Safety: Why One CSC Uses Scrum and XP Together to Avoid XP Risks. I have gotten more flak over this than a years worth of blog posts.

For sure, there are some inaccuracies (more on this below)

Also, some people have interpreted it as saying XP bad, Scrum good.

In hindsight, I can see how people may interpret the post this way.

Sorry

I am truly sorry for offending anyone. This was not my intent.

Scrum and XP are evolving targets

My big learning is that Scrum and XP are evolving and imprecise concepts.

Let’s take and example from Scrum. Retrospectives were not originally part of Scrum. I checked out Ken’s original book and it’s not there. Neither is definition of done. Of course, they were part of CSM as taught by Ken in 2004 when I learned Scrum. Scrum at least has a Scrum Guide (hosted at scrum.org!) to define what Scrum is today.

Let’s consider XP. I have heard the statement that Retrospectives are part of XP and have been since 2001. OK, how would I verify that? Well, how about checking the revised edition of Extreme Programming Explained (2005)? Interestingly, it does not mention retrospectives. Jim Shore’s book does but it’s the Art of Agile, not the Art of XP. AFAIK, there is no definitive source for XP the way there is for Scrum. This makes it really hard to have a conversation about what XP actually is. Based on this, I think it is fair to say that I don’t know what XP is and I probably never did. I’m not even sure how I would find out if I wanted to. (If you know, please let tell me).

This demonstrates how CSM and standardized training has done more to grow the Agile community than anything else. It helps to have a standard language and a common core. So, kudos to Ken Schwaber for this.

Practices vs. Brand

I agree with the comment that what is most important is not the Brand, it is the practices. I totally agree. The practices are more important than what we call them.

On the other hand, the brand is relevant too. It defines where we start with clients, the language we use, and the community we grow with. So for me, brand does matter. And the Scrum brand (for all it’s odour).

Many thanks to Lowell Lindstrom and Adam Sroka for commenting on my article and helping me learn something from this experience.

Just had my first article posted to Scrum Alliance website. (Click link to check it out). I originally wrote this 9 months ago to support my Certified Scrum Coach application, but that process finished first.

Here is the abstract:

Scrum contains a set of practices distinct from XP that are intended to enhance project safety. The Scrum framework is simple and intentionally incomplete. Scrum expects that teams will add in practices that are relevant to their specific context. For example, there is wide recognition within the Scrum community that XP engineering practices need to be added to Scrum to create sustainable software projects. So, Scrum and XP together is a good starting point.

I was reading Freddy Balle’s book The Gold Mine: A Novel of Lean Turnaround and I read something that stopped me dead in my tracks. In the book, after months of transitioning a manufacturing plant to continuous flow using Kanban, the Lean sensei asks the innocent question:

Question: What is better than Kanban?

To answer this, one must think of the purpose of a Kanban card. In manufacturing, a Kanban card is a replenishment indicator for a particular part or assembly. In software, we use Kanban to represent a piece of work such as an MMF or user story. Either way, a Kanban card represents WIP (work in process). More Kanban cards means more WIP.

What’s our goal? To increase throughput and reduce latency while minimizing operating expense. Reducing WIP is very helpful. Would be great if we could reduce our WIP as far as possible. How to do that? One-piece flow. So we reduce Kanban cards to zero.

Answer: No Kanban!

If there is no Kanban and you are very Lean, then you have single-piece flow. The holy grail of Lean process. This is what Arlo Belshee and Jim Shore attempted to explained in their LSSC10 session Enough Kanban! Use XP for Single-piece flow. (Please check it out if you haven’t seen it before.) I say attempted because I didn’t get it – I needed to read the above question and answer for the pin to drop.

So what? If you are in an environment where you can do Scrum or XP, then go do so! If not, then Kanban is great place to start. Or finish – in the case of an elite Scrum/XP team that doesn’t need iterations as training wheels.

Kanban in Context

I love Kanban – it is a great tool. One thing that I keep in mind is that Kanban is only a small part of the Lean context in which it lives. Kenji Hiranabe has a great article on InfoQ on this - Kanban Applied to Software Development: from Agile to Lean Please check out Figure 11 TPS Concept Structure: it illustrates that Kanban is just one part of the Lean system of thinking. Of course, it is a great starting place for learning it.

(Aside: I almost had a blog post without images or drawings. Then I decided I needed to do something – anything to make my point more vivid. Please excuse my primitive drawing skills.)

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.

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.

Arlo Belshee and Jim Shore had an interesting pair presentation on titled “Single Piece Flow in Kanban” at LSSC10. A more accurate (although inflammatory) name for the talk is “Enough Kanban! Use XP for Single-piece flow”. It is worth mentioning that the context of the discussion is new product development.  Not sure about team size – seemed manageable. So this may be suitable for this context.

The basic arguement is that we should consider the flow of customer value. This is real flow. Moving Kanban cards representing tasks may be motion and not actual flow of value. The solution is not something new but something we already know: eXtremeProgramming (XP).

One challenge that Taiichi Ohno encountered decades ago when introducing Single Piece Flow at Toyota is that there is often resistance from specialists. They are more comfortable just knowing one piece of equipment.

The same challenge exists today when we ask developers, testers and domain experts to work together to deliver value. If your environment can work this way (and some can’t very easily) there can be a big cycle time and business value win.

What’s wrong with some Kanban implementations? Some have too many hand-offs and WIP due to queues. So, if you are using Kanban, this is something to watch out for.

Arlo and Jim describe the software work-cell as a collocated, cross-functional team that swarm work to minimize WIP and handoffs.

Gone is the release plan and the product backlog (see diagram). Instead a vision (which was a mindmap) drives the just-in-time generation of MMF (minimum marketable features) that are queued in the “on-deck” area. MMF is generalized to mean anything of business value. It could be a product feature. It could be a demo for a tradeshow.

For in-progress work, the notion of a Detective’s Blackboard was introduced as a dynamic unstructured area where tasks and task generators could be added and removed organically depending on the nature of the MMF. The idea is that tasks will grow as work gets started and then start to collapse as progress is made and new tasks stop appearing. (Maybe around when the MMF is ~2/3 complete.) In the example provided, the team was large enough to support 2 MMFs. The video and slides are available on InfoQ.

What looks like an earlier version of this is on Jim’s blog. See also Arlo’s video on Naked Planning. A video with session slides + Audio are on Jim’s blog.

Very cool stuff.

Part of my standard training for Product Owners is to help them understand how they relate to everyone else in an Agile/Scrum world. Hence the drawing below.

Project Community Diagram

The Product Owner is not part of the team since their role is to ask for more to keep productive tension in the system. I like the way Ron Jeffries narrates about the Product Owner Role without ever using the term. This is a good story. So is the follow-up one.

I like the XP notion of the customer team to reflect the group representing the customers interests. (If anyone can suggest a good link/definition, I’ll add it.)

Why is the ScrumMaster outside? Their primary role is to act outside of the system to help it function and grow. Why is the ScrumMaster cheering on top? Ooops. That’s a bug. If I had time to re-draw, I’d put them underneath holding up the whole system as a servant leader.

So what do you do, if you don’t like the way I have parsed the world? Please help me understand your perspective – draw a picture to show me the world through your eyes.

This is a list of some resources that are useful for getting started or growing your understanding of Agile.

The permanent page for this content on my website is here (so this is better place to link to since it will be updated).

Getting Started

Short articles for printing out and reading while you are on the train/subway.

• Agile Manifesto – Web page
• Agile Manifesto Principles – Web page
• Article on the history of Iterative developement
• Connections between Lean and Agile
• Short Scrum Guide – 13 page article/guide
• Scrum on a page – This you can put on a wall near you.

Intro to Scrum/Agile

• A Gentle Introduction to Agile – Presentation
• Agile Executive Briefing – Presentation
• Scrum in 10 minutes – Video (10 min)
• A Day in the Life of a Scrum Team – Video (6 min)
• Scrum Overview by Ken Schwaber – Video (60 min)
• Overview Powerpoint by Mike Cohn

Other Stuff you need to know to get your project started

• Getting started with User Stories – Book Excerpt
• Agile Estimation and Planning by Mike Cohn – Video (90 min)

Next Steps

• Check out some of the other resources below.
• Start reading some of the books.
• You have started a journey of learning – be patient and enjoy the trip.

Additional Learning Resources

• Scrum
  • Scrum Overview by Ken Schwaber – Website
  • Scrum Overview by Mike Cohn – Website
• XP
  • eXtreme Programming on C2 Wiki.
• User Stories
  • An Introduction to User Stories – Presentation
• Agile Estimation and Planning
  • Agile Estimation and Planning – Presentation
• Lean
  • Demo showing impact of bottlenecks
  • Lean for Business – Website
• Fun Stuff
  • Punchy video about how Agile can improve on Waterfall
• Agile Team Room
  • Agile Team Room – Photos
  • How does radical collocation help a team succeed?
• Pairing – team collaboration on tasks
  • Benefits of Pair Programming – C2 Wiki
  • Benefits Research Paper – Cockburn & Williams
  • How Pair Programming works - General concepts behind pairing and pair programming] (used in training)
  • Promiscuous Pairing - Some ideas on how rapid pairing can cultivate creativity. Also, How-to Article
• Agile Documentation Practices – Web Article
• Agile Testing – Video (60 min)
• Automated Testing
  • Automated Acceptance Testing – Presentation
• How Agile are you? (Agile Adoption)
  • Nokia Test – basic Agile test
  • Uncle Bob’s more extensive test
• Crystal Clear – low ceremony Agile process
  • 7 Properties of Crystal Clear – Article
  • 7 Properties Mind Map

Books to Read

Stage 1: Getting the basics in place

• Agile and Iterative Development: A Manager’s Guide
• Scrum I: Agile Software Development With Scrum – Basic Instructions
• Scrum II: Agile Project Management With Scrum – Stories about Scrum Usage
• User Stories Applied: For Agile Software Development
• Scrum and XP from the Trenches
• Agile Estimating and Planning

Deepening the practice

• Implementing Lean Software Development: From Concept to Cash
• Agile Software Development: The Cooperative Game
• The Software Project Manager’s Bridge to Agility
• Scrum III: Enterprise Scrum

eXtremeProgramming

• Extreme Programming Explained: Embrace Change
• Extreme Programming Installed
• Art of Agile Development

Technical Practices

• Domain-Driven Design: Tackling Complexity in the Heart of Software
• Refactoring: Improving the Design of Existing Code
• Agile Testing: A Practical Guide for Testers and Agile Teams

Lean

• Lean Software Development: An Agile Toolkit
• The Goal: A Process of Ongoing Improvement
• Critical Chain
• Lean Thinking: Banish Waste and Create Wealth in Your Corporation

Other good ones

• Crystal Clear: A Human-Powered Methodology for Small Teams
• Managing Agile Projects
• Fearless Change: Patterns for Introducing New Ideas

Games & Simulations

• XPGame – learn how Agile really works
• Leadership Game - learn different leadership styles and how you relate to them
• Bottleneck Game – learn how to improve your processes to eliminate bottlenecks
• Business Value Game – learn strategies and challenges with prioritizing work (product backlog)

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

At Agile 2009, Mary Poppendieck presented on “Deliberate Practice” – how people become experts. The video and slides are available from InfoQ.

Consider the fifth value statement proposed for the Agile Manifesto by Bob Martin:

Craftsmanship over Crap

This presentation follows in the theme craftsmanship – How do we as a community bring it about?

The answer given in this talk is we need to consider what it takes to develop elite level skills in other professions – deliberate practice.  Consider the visual note below:

It seems to me that virtually every company I have every worked for or with has done virtually nothing to bring about excellence in technical (or other) skills.  Imagine what the world would be like if companies viewed their employees as assets and invested in them with mentoring and challenges so that they get deliberate practice.  This requires companies to think about Production Capability and not just Production.  More than just thinking about hitting the deadline.  This is an essential component in build lasting success.

Ever heard of this crazy-sounding approach called eXtreme Programming (XP)? Maybe they were on to something.