Why the Re-think?
One of the consistent areas of feedback Dennis and I got on the book proposal was that folks didn’t like the title. The initial reaction from our publisher was that many folks haven’t even ‘thought’ about agile in the enterprise… never mind being in a position to ‘re-think’ about agile in the enterprise. We decided to leave the title for now with the understanding that we might change it later on.
Just in case the title totally goes away… I want to explain why we chose ‘Re-thinking the Agile Enterprise’ for the Cutter paper… and ultimately for the book. First… I am a sucker for subtle jokes and puns. I know it’s low humor… but I can’t help it… it’s the way I am wired. Second… the ‘re-think’ in the title is actually a reference to something meaningful to the premise of the book. It’s a subtle little play on words that I’d like to take a minute to explain.
Dennis Stevens and I have been working on the ideas behind this book for almost a year now. Prior to our partnership, Dennis worked with Ric Merrifield and Jack Calhoun on a Harvard Business Review article called ‘The Next Revolution in Productivity‘. Without going into too much detail… the article is about understanding your desired outcomes… understanding the stuff you do that supports your desired outcomes… identifying the capabilities supporting each activity… figuring out which are most important… and ultimately designing a more efficient operating model for your business.
On the success of that paper… Ric Merrifield published ‘Re-Th!nk: A Business Manifesto for Cutting Costs and Boosting Innovation‘. Ric’s book builds on the ideas in the HBR article and establishes a new language… a new framework if you will… for thinking about the performance of our organizations. The basic premise is that most organizations spend way too much time, money, and energy thinking about HOW we get work done and not nearly enough time thinking about WHAT the value is we are actually trying to deliver.
The idea is that companies often fall into a HOW trap… where they get so focused on process improvement… they forget what the heck they were trying to accomplish in the first place.
So… with that as our backdrop… let’s get back to the title of the book.
Dennis and I are writing a book to help software professionals… Development Managers, Project Managers, Directors, and Vice Presidents… get past the dogma of methodology… past the dogma of best practice… and start thinking about WHY they are doing the things they are doing… and back to the WHAT they are actually trying to deliver. The agile practices we talk about are often really HOWs… HOWs that allow those primary WHATs to manifest in our organizations.
We’ll see how the book title plays out… for now I wanted you guys to understand the reference and why we thought it was important.
Comments (3)
MMaham
Hi Matt-
Very good post. I think you may have understated your case when you say "We believe this is the secret to sustainable agile adoption in the enterprise" and posted on this at http://lessmayhemmoresoftware.blogspot.com/2009/08/what-more-than-how.html
A lot of failed improvements efforts I've seen are a direct result of focusing on the HOW and losing site of the WHAT. Glad to see you helping people keep the main thing the main thing!
michael
Anonymous
Good afternoon Mike,
Really enjoyed meeting you at AgilePalooza, and *especially* appreciate the advice, insight and wisdom you offered up on our transition to Agile/Scrum…Now to my comments on your post – Totally concur on your thought process, however, when PBIs are properly "groomed" and release planning session is successfully conducted, shouldn't the WHAT just naturally evolve and be realized either before or in tandem with determining the HOW? Shouldn't User Stories being created for a release/sprint give the team enough of a "WHAT" view to accurately determine the "HOW"? Am I expecting too much out of the Scrum teams and the Product Owners??!
Regards,
Winona Robertson, RMIC
Mike Cottmeyer
That goes both ways, I really enjoyed meeting you too.
Think about this… the WHAT you need is the prioritized, groomed backlog. A backlog with enough information that the team can go off an build it. The WHAT you need is someone to answer questions for the team, answer business questions, and make technical trade-offs.
The Product Owner is a HOW to get those WHATs.
If the PO model breaks down… what is more important… making sure we have a PO… or making sure we have a prioritized, groomed backlog with enough information that the team can go off an build it and someone to answer questions and make technical trade-offs?
If a single PO can deliver that WHAT… then the PO is a sufficient HOW to deliver the WHAT.
In many cases… the Scrum PO HOW is insufficient to deliver the WHAT required to do the job. When faced with that dilemma… is it better to force the organization into the single PO model… or come up with something that is a better fit for your team based on the WHATs we need to deliver.
Make sense?
I might be confusing myself with all those HOWs and WHATs ;-)
Mike