Kanban is a Gateway Drug

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.

Comments (4)

Rapid reliable releases

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.

Leave a Comment

Enough Kanban! Use XP for Single-piece flow

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 PlanningA video with session slides + Audio are on Jim’s blog.

Very cool stuff.

Comments (4)

Customer Team Helps Product Owners Survive

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.

Comments (2)

Agile Learning Resources

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.

Intro to Scrum/Agile

Other Stuff you need to know to get your project started

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

Books to Read

Stage 1: Getting the basics in place

Deepening the practice

eXtremeProgramming

Technical Practices

Lean

Other good ones

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)

Leave a Comment

Agile Tour Toronto Presentation: A Gentle Introduction to Agile

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

Leave a Comment

Deliberate Practice – a key to Craftsmanship

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:

Deliberate Practice

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. ;-)

Comments (1)

Agile Kick Start and Agile Games Day – Announcing Two Workshops October 19th and 21st

As one of the organizers of Agile Tour Toronto I was thrilled with our success in attracting attendees – we sold out a month before the conference.  We decided that we would rather have a smaller conference with a good experience rather than a larger one that is more than we can manage in our first year running it.

To run the conference, we created a not-for-profit organization – Toronto Agile Software Development Community – with a mission of helping people and companies in the Toronto area with Agile techniques.  I was sad that we could not do more to help grow Agile in the community.

A few days ago, Yves Hanoulle, announced that he would like to do some training to help justify flying all the way to Toronto just for a one day conference.  I agreed to help and we are going to jointly run not one, but two workshops around the time of Agile Tour Toronto.  This will allow Yves to attend and present as well as provide an opportunity for those who can’t attend Agile Tour Toronto.  The works are:

Agile Kick Start – Monday, Oct. 19th

Agile Kick Start is for those new to agile as well as those interested in learning more about the technical pillar of Agile called XP.  We also talk about agile values, self-organizing teams, project vision, scaling agile, visual management, the famous XP game.

Agile Games Day – Wednesday, Oct. 21st

Agile Games Day provides hands-on experience with key Agile concepts through a day of learning by doing.  This includes defining business value, leadership/self-organization, and learning how to go faster using the Theory of Constraints.  If you haven’t tried before, this is a great way to learn and internalize concepts.

Why offer these sessions?

As organizers of Agile Tour Toronto, we noticed that there were a lot of people registering groups of people from their company to get basic training.  Hence the motivation for offering Agile Kick Start.

One of the things we talked about doing as part of Agile Tour Toronto was to run a games track since we know how important hands-on learning is.  Then we hit complications like finding more space, soliciting proposals and just didn’t have enough time.

Yves and I are really excited to be able to offer these workshops as a complement to Agile Tour Toronto and hope you can attend.

Leave a Comment

XPToronto Talk – Understanding and Dealing with Technical Debt by Amr Elssamadisy

Tonight Amr Elssamadisy from GembaSystems presented at the XPToronto/Agile User group.  There was a big turnout of almost 40 people and I think one person didn’t actually have a seat.

What follows are a series of notes from the talk without too much editing…

People’s reasons for wanting to hear about Technical Debt tonight

  • People with short-term focus
  • Technical Arguements
  • Is it worth refactoring
  • Currently living in Legacy Land
  • Business value of paying down technical debt
  • How?  (to fix)
  • Best Practices
  • Root causes

Examples of Technical Debt

  • I have spent 3 years building legacy code web site with no unit tests.
  • Code that has been copy and pasted.
  • Code that is difficult to get under test: large classes, methods.
  • Branching and duplication of the application.
  • Duplication of functionality written by different people.

How does technical debt affect behaviour?

New requirements

  • Dumbed-down solutions
  • Fear of change.  Not sure what will happen.
  • Question to ask: How hard is work this year compared to last year?
  • Splinter IT group into siloed green team

Design

  • What design?
  • No new design
  • No changed design
  • Tons of band-aid solutions
  • New features need to be workaround

Defects

  • Only critical ones
  • Lots and time and effort in regression ? $$$
  • Many bugs don’t get fixed – bad code
  • Often sketchy manual testing

Maintainability

  • Goes down with technical debt
  • Dead core after 5 years
  • Inventor’s dilemma – productivity goes down over time.
  • Difficult to get new people who can work with the code base.

Why do teams fall into this trap?

People follow cost of change curve.  It rises exponentially: requirements to analysis to design to test to production.  Code is fragile for everyone but the author.

Test-first development makes the cost of change linear.  Courage?  Not needed so much since you have a test harness.  Tests act as a signaling system to people working on the system that there is something they need to pay attention to.

“Programming as Theory Building” – this can only be learned through apprenticeship which is not practiced in corporate America.  So what do you use?  Documents don’t work – this results in a new paradigm and the level of mismatch leads to additional cost.  Perhaps pairing is the new apprenticeship model.

Breaking dependencies and adding test to legacy code

Low coupling and high cohesion are main design principles. –> Get teams to agree to “do no harm” to the design

Example of adding code into a function.  This will make cohesion worse.

  1. Take the code to be modified and move the code to a new function.  (Extract method refactoring)
  2. How hard is it to create the main object?  Probably really hard.
  3. So, refactor to a new class (a sprout) instead so you can create it and test it.
  4. And may need to create mock objects to make this work due to parameters.
  5. Use refactoring to aggregate related sprouts.

Read Michael Feather’s book - Working Effectively with Legacy Code.

Like most things, this is a people problem.  And then we had an interesting digression into Christopher Avery’s material on personal responsibility.

Comments (1)


       Follow MichaelSahota on Twitter  
    
         XPToronto and Agile User Group
       Certified ScrumMaster Certification
       Certified Scrum Professional Certification