I am an Agile Plumber

I am an Agile Plumber – I eliminate waste, remove blockages and increase flow.

This week we had an agile workshop to establish some goals and create some epics for next quarter’s release for the agile change team at an organization I am coaching.

One of the items we covered in the workshop was to come up with a new team name for our agile change team as a result of some organization changes.  Some of the names included:

  • Agile Change Team (A.C.T.)
  • Agile Capability Delivery Centre (AC-DC)
  • The Enablers
  • Centre for Agile Practices

….and there were many more.

When we went to vote on a name, a clear winner was Agile Plumbers.  This name was quite humorous at first and we all got a good laugh, but the name is symbolic and there is some serious intent behind it.

An important aspect of agile and lean is about eliminating waste, removing blockages, and increasing flow which can really can change the way you build software.

There are many forms of waste including partially done work, extra processes, extra features, task switching, waiting, motion and defects.  By looking at the waste that is in the steps you are doing and removing the waste you can do more with less.

We also have failure modes because we’re not paying attention to what it really takes to be agile.  There are many roadblocks and blockages to getting to success.  There are roadblocks that occur within teams and projects, but there are larger organizational roadblocks which are impediments to any agile approach.  Agile touches on many aspects of an enterprise organization and changes many existing organizational processes that are more acquainted to waterfall.  Examples include:

  • Procurement, such as selecting and working with vendors.
  • HR, especially what type of people we want to recruit, and changing manager’s KPIs to align more with a collaborative culture.
  • Finance, how we structure the organization’s funding model to align with agile approaches and incremental delivery.  Also funding may need to change to support a lean pipeline of work (continuous flow of work), rather than ‘individual projects’.
  • Legal, how we write contracts that support agile teams and approaches.
  • Training, creating training programs for agile (not only including agile specific topics, but also leadership and soft skills that are required in a collaborative organization).
  • Governance, most traditional governance does not work with agile.
  • Add your own organizational impact and blockage here that needs removing.

Finally, a goal of lean and kanban is increasing the efficient delivery of value through limiting the work in progress (WIP), making work visible and increasing the overall flow.  Optimizing the entire value stream, from initial concept to consumption is fundamental to increasing flow of value through the organization.  The idea is to get an idea into the development pipeline and out to the customer as fast as possible by looking at the existing processes and improving them and in the process eliminate waste and create value.

The other advantage of being called an Agile Plumber is that the name creates an memorable impression.  In a large organization with many business units and organizational teams, one thing that can be difficult is being able to identify where agile help can be found.

So next time you need someone to help eliminate waste, remove blockages and increase flow, call your nearest Agile Plumber!

2 Comments on “I am an Agile Plumber”

  1. Hi Chris,
    Thank you for providing us with a wonderful (and conversationally provocative) analogy. Let me return the favor.

    Although it may be true that “you can do more with less” (and we often hear admonitions for teams to do so), I would offer that this isn’t the point; it is actually to simply “do less”. This is is one of the hardest lessons for teams and organizations to learn, and will always provoke at least some quizzical interest and hopefully further conversation.

    Aslak Hellesoy gives a great presentation (http://skillsmatter.com/podcast/agile-scrum/cucumber-from-the-horses-mouth/zx-1334) where he not only mentions the oft quoted Standish Group study on percentage of features that are delivered but never used at all, he also shows a slide detailing _when_ mistakes are made (about 56% in requirements phase and another 25% in design). These both result directly from the “you-only-get-one-chance-to-say-what-you-want” syndrome; that is, the business throws in everything they think the _might_ need because they’ve been burned before on the cost of “change orders” used with outmoded development models.

    There are two lesson here:
    1. It’s not only the “development” (the coding and testing portions) that are done in small bits/short iterations, it’s also the requirements, the design, and the deployment. You might hear some FUD here: “Oh horror. Incremental design?! How can that possibly work? No self-respecting architect is going to go for that!”. But on the flip side, how much better will the result be if the limited budget available is focused on stuff the customer is actually willing to pay for, i.e. that they value. (You might also hear “OMG. You want an actual customer to see _that_? But .. but .. it’s .. it’s not shiny.”)

    How do you know, absolutely, if the customer is willing to pay for it until you put it in their hands. Folding the requirements/analysis/design activities into one end, and deployment activities into the other end of short iterations is by far the most difficult part of delivering value, but also the most rewarding part.

    2. Only if you do this (get working software into the hands of the customer early and often) will a second benefit accrue; they get to see what they _told_ they wanted in time to change their minds and apply what they’ve learned on the way there. How refreshing is that?! Who knows? They could actually end up trusting you after that sort of experience.

    Anyway, while it may seem crazy, provocative, etc. doing less (the right stuff) actually _gets_ you more.

    Thanks again for a great analogy,

  2. Bob, totally agree.

    The “you-only-get-one-chance-to-say-what-you-want” is a viscous cycle.

Leave a Reply