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.