Skip to main content

The Anti-AMM: Sculpture, Not Pyramid Building

Get a bunch of agile evangelists together, and we like nothing better than argue over the details of our favorite Agile Maturity Models (AMMs) over a few beers, the more complex the better.  "But HOW can you make a REAL DIFFERENCE until you TACKLE HIRING PRACTICES FIRST!" we holler, having (unfortunately) switched to tequila shots a little later in the evening.  Our client practices are raw boulders, and we are going to help them build a pyramid!
http://science.howstuffworks.com/engineering/structural/pyramid.htm
If only our clients will listen to us, we think, we can help them "start small," and gradually evolve into high-performing teams like the ones we're used to.  First they might try Stand-Ups and Burn-Ups, we say.  Then if all goes well, we will try test automation.  Refactoring for extra credit, but only once the analysts have been trained.  Sequence is all, and it gives us a lot to argue about.  Let's build that pyramid!
AMM rendering of the first verse of "The Sloth" by Flanders and Swann
Fellow agile thinkers--have we really stopped to think about what we imply when we use the word "maturity" to describe what we are helping clients build?  Our slide decks feature aggressive use of primary colors, and we tacitly use the word "immature" in close proximity to the words "CIO," "CQO," and "CFO."  What have we been thinking?  This isn't just wrong, it's bad business.

What we need is the exact opposite of a maturity model.  We need to know Nirvana in its pure and complete beauty, and then we need to let our clients help us to sculpt away our assumptions, to make our model even more useful.  We had it backwards:  clients aren't in the infancy of building our Nirvana state.  We are in the infancy of being able to cut Nirvana into the right pieces to efficiently help our clients.

What Does This Big Block of Nirvana Look Like?  First, let's freely admit we need to always have Nirvana with us.  It could even be a Nirvana borrowed from the top of someone else's Agile Maturity Model.  In Nirvana:
  • Product Management knows how to design a software product so that it can be tuned on the fly--try out the "A" and "B" models simultaneously, and if "B" makes more money, flip a switch and turn "A" off.
  • We can release new versions of software to production every week.  Hour.  Second.
  • We have room to make mistakes because we have a portfolio strategy which constantly checks to see that the return on investment for any given project is rising from one iteration to the next, not leveling off.
  • We're satisfying our customers in a fast-changing world, and our code quality is incredibly high, so we can change it on a dime and release something new tomorrow.
How do we do this in Nirvana?
  • all teams are small and collocated, and 
  • they work solely on brand new software, or maybe software that's a year or two in age, 
  • but all of it is swaddled in a Continuous Deployment pipeline 
  • hitched up to 
  • an automated testing framework that 
  • handles all possible levels of testing 
  • either at check-in, or overnight, if the thing to be tested takes a long time.  
  • Also, in Nirvana, all applications are web applications with virtually zero fixed cost for releasing to market.
All teams in Nirvana
  • are self-organized, and 
  • all members of those teams are team-oriented geniuses 
  • who understand that agile is not a fad, but a collection of productive goodness, 
  • who can do anything, and 
  • who would never let you down.  
There is no ill-will in Nirvana, no politics, no personal ambition except Getting the Job Done.  Everyone is competent and no-one is new, except for the occasional hyper-smart individual we hire and quickly train through effective use of pairing.

Sculpting Nirvana to Fit the Real World. How useful is our vision of Nirvana to the average executive?  Not very, especially when it is accompanied by an Agile Maturity Model that measures each company by how much it doesn't match, and calls for fundamental corporate change "before we can even get started."

What must we do to make our vision useful?  Stop thinking in terms of "maturity."  We're not looking to help clients build our ideal pyramid.  Or if we are, we have to stop.  We need to think instead of Michaelangelo's concept of the "non finito:" the thing of beauty constantly emerging from the rock.  Our clients are helping us evolve our vision by testing it against reality (again).
http://raeleenmautner.com/?s=non+finito&submit=Search
But concretely, if you will pardon the word, what do we do?  Here it is:
  1. Pack.  We pack up our big old block of Nirvana and take it with us to visit a client.  But we leave it out in the truck for the initial meeting.
  2. SWOT.  We have a SWOT analysis, whether formal or implied, with our clients.  Not just "what are your pain points," but "what are your opportunities and threats?"  Not "what are your software development processes," but "how can technology minimize threats to your business and capitalize on your opportunities?"  Think like a business person.  Think about increased revenue, decreased operational costs, increased customer satisfaction, creating a new market, lowering cost of business as usual, shrinking time to market, retaining the best staff and being a destination employer.
  3. Rethink.  In two stages:
    1. We take the facts of the actual client business situation, as we understand them, back to our block of Nirvana in the parking garage, and we start chipping away at our own assumptions.  Wow, our client is building middleware with a team on three continents, and they've been through three major "process engineering" fads in the last six months.  Gee, the product management group hates the technology people.  Hm.  The developers don't unit test, and they get mad when testers send code back to them to be fixed.  Yikes!  Eight different "stage gates" with hundreds of employees who will lose their jobs if we try to cut down the bureaucracy.
    2. Once we have thrown away the "all or nothing" view of Nirvana, what can we propose from our Agile bag of tricks that will actually give our client a positive return on their investment for hiring us?  What reasoning and proof can we give that our suggestions will work?  What can they do in 3 months?  A year?  3 years?
  4. Propose.  We go back to the client with a "business proposal," not an AMM.  We suggest things that can be done in 3 months, a year, or 3 years.  We give them our price points for helping them reach these achievable goals, and we give them metrics to suggest why they will see a business return on their investment.
  5. Drive home.  Note that nowhere in this process do we force the client to come out to the parking lot to view our big old block of Nirvana.  It is a model which is the thing that powers our thoughts and provides bounteous patterns to us in every engagement, and it's something we keep refining.  But it is our luggage, not theirs.


Comments

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica