Skip to main content

Coming to Consensus

Mike Cottmeyer Chief Executive Officer
Reading: Coming to Consensus

It’s one thing to do stuff… it is quite another to write about what you do. It is tough to be clear and articulate; always making sure to leave your reader in a better place than when you got them. I’ve learned that the hard way over the past few years while doing papers for VersionOne and writing this blog. That said, collaborating with Dennis on the framework for our book has taken this challenge to a whole new level.

Over the past few days I stopped writing about the book because we hit a bit of a wall. We knew some of the words we were using were overloaded. What we didn’t realize was how much that overloading allowed us to have a conversation without having any idea what each other were talking about. Okay… that might be a little strong… but getting through it was pretty frustrating. Having two strong willed, capable dudes… both with a strong vision and sense of direction… trying to merge complex ideas into something simple and digestible has proven pretty challenging.

That said, I think we made some headway this week around our use of the word Capability.

Last week I talked about three types of capabilities: Value, Core, and Supporting. I had described Value Capabilities as the stuff we provide back to the business… stuff we might sell to an actual customer. Our problem wasn’t that Value Capabilities don’t exist… it’s just that in our model all capabilities have a value attribute. I inadvertently overloaded the word Value as well as the word Capability. From here out we are going stop using the expression Value Capabilities and replace it with the idea of Product Capabilities. Same concept, different language.

I’ve never been a big fan of how we were using the expression Core Capabilities. Again… it’s not that these kinds of capabilities didn’t exist… its just that describing them as core didn’t prove descriptive enough and led to some confusion. We’ll keep the category basically the same… it will include all the stuff we directly do to deliver the Product Capabilities… stuff like writing software and testing… but we are going to call them Delivery Capabilities. It seems a little more descriptive for the purposes of our conversation.

Finally, we talked about the idea of Supporting Capabilities. I had described these as the things you need to be good at to support your ability to deliver Product Capabilities. I had included environmental things like building CI environments, invoicing and collecting payments. I had also included stuff like managing the project and communicating status. Dennis has convinced me that we need to separate these into two categories. To that end, we are now going to think about these in terms of Supporting Capabilities (CI environments, invoicing and collecting payments) and Controlling Capabilities (managing the project and communicating status).

Again the specific capabilities in each section might ebb and flow as we get deeper into the conversation but I think we have the major categories right. The story around capabilities is really important to our core message. As you adopt and scale agile… the core things you DO to deliver product get expressed differently at each level of the five phase adoption model. For us and for the book… this was an important idea to get worked out early in the writing process.
Next Interesting Post... 9/6/2009 through 9/12/2009

Leave a comment

Your email address will not be published. Required fields are marked *