Is Your Business Model A Good Fit For Agile?
Written by Mike Cottmeyer Wednesday, 8 January 2014 09:02
After I’ve asked a room full of executives what problems they are trying to solve, the next thing I’ll often do is try to help them understand… and me understand… their operating model. I want to know if they are in a business where it is okay to make it up the product as you go, or one where you have to make and meet commitments based on specific dates and deliverables? You can probably guess how most people answer the questions… but let me explain further… just to make sure I am clear.
Many of the web based companies we hold up as idols… Google, Amazon, and Facebook… have the luxury of having basically invented their markets. They can put product into market super fast, measure the impact of any changes, and adapt what they are doing based on real time customer feedback. Furthermore, if you think about what (a company like) Google sells, it comes down to advertising. As long as the features they introduce sell more advertising, it doesn’t matter what features they add.
I define these kinds of companies as having Emergent Business Models. The feature set isn’t defined, they are more goal oriented, and the ultimate product definition doesn’t matter as much… as long as the goal is met. In Google’s case, you can build GMail, or Android, or Chromebooks, or Maps… as long as each new product or feature sells more advertising.
Contrast this with other companies that are more sales driven. Being sales driven results from the sales guys committing to features that must be delivered based on direct contractual obligations to external customers. You might have marketing making commitments to a customer base that is expecting a relatively fixed feature set in a relatively fixed period of time. Either way, there is a different dynamic at play. What features we deliver matters. When we deliver them matters. We need to deliver them all and we need to deliver them profitably.
I define these kinds of companies as having Convergent business models. The feature set is pretty well defined, they are not necessarily goal oriented, and the ultimate delivery date and product definition matters a great deal. What really matters is that we’ve met the contractual obligation, explicit or implied.
Either model can be successful. Either model can deliver economic return for our investors. I’m not making any judgement. Personally… if I were building a company from the ground up (and I am by the way) I would always go for an Emergent business model… it makes more sense, it’s more adaptable and it’s more resilient. But that’s my opinion. My opinion aside about what a company *should* be… it’s important to understand what our company *is* before we make any assumptions about what processes to adopt.
Most agile methods assume that you operate in an emergent business model when most companies trying to adopt agile have a convergent business model.
Here is the rub… most companies (when they first encounter agile) read the literature and assume that agile will work (as described) regardless if they are operating in an Emergent or Convergent Business Model. They read a story about an Emergent company that used agile to great success, failing to realize that they are a Convergent company and the same rules don’t apply. They work in a company where you can’t make it up as you go, where you can’t have a process based on fast adaptation because your company doesn’t support that kind of adaptation.
I read once where Ken Schwaber compared Scrum to Chess. Ken was making the point that it is silly to ask if Scrum works. Asking if Scrum works was like asking if Chess works. Of course Chess works… you are either playing chess or you are not. You are either doing Scrum or you are not. You might not be good at Chess… or at Scrum… but they work. I agree with Ken on this, but I want to explore a little more deeply, and tie it into the Emergent-Convergent conversation. Here is my point…
If you are a Convergent company trying to use Scrum, it’s like trying to play Chess when you have a different sized Chess board, you don’t have all the normal Chess pieces, and the pieces you do have play by different rules. You can try to play Chess but it is never going to work. Trying to adopt Emergent Scrum when you are in an organization that focused on Convergent outcomes and fixed time, cost, and scope objectives is never going to work.
You have a choice…
You either adapt your company so that you can successfully play by the rules of Scrum… move from a convergent business model to an emergent business model… or you adapt the rules of the Scrum to accommodate your current reality. Again… no judgement here… you can do what you want. You can play Chess or do Scrum without all the right foundational elements… just don’t be surprised when it’s tough to win the game or when your agile adoption doesn’t work out like you planned.
A big part of what we are implementing with our clients is a blend of what works in Scrum with XP and Lean and Kanban and even traditional program and portfolio management and governance techniques to craft processes that can work at scale. It’s not Scrum per se… you might even say it’s not agile… but it’s agile enough for most companies and it works. You can use Scrum at the team level, wrapping the teams in a Lean/Kanban based value stream, focus on small batches and limiting WIP at the enterprise level, and really craft a strategy that is effective at scale.
Pretending to play Chess when you aren’t really playing Chess doesn’t help anyone and just frustrates the players. Before you can have any rational discussion around agile and what agile practices you want to adopt… take a good look at your business model and ask yourself if the basics of Scrum will work across your enterprise. If Scrum isn’t going to work, look past Scrum to the palette of tools that are available to you in the industry now and blend as necessary. Remember the goal is never Scrum, it’s business agility… whatever that takes.
I’ve got one more foundational concept that I want to introduce in my next post. It’s an oldie but a goodie about how agile handles time, cost, and scope… then I’m going tell you about the house I was going to build over the summer and what it taught be about agile program and portfolio management. Thanks for listening.
Read the previous post, What Problems Are Executives Trying To Solve With Agile?
Read the next post, How to Make Commitments in the Face of Uncertainty