Is Your Business Model A Good Fit For Agile?
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
Comments (24)
Ron Jeffries
What if your assumption, that Agile doesn’t fit Convergent models, was wrong?
I ask, because I suspect it is in fact wrong.
That’s not my assumption Ron. My assumption is that team based Scrum in complex organizations in insufficient. The typical emergent strategies articulated by many in the agile community won’t work for convergent business models. It’s all about defining your problem and determining what is the best approach. I’m laying down a pattern language… some concepts to build on in future posts. I’m not finished telling to story. That said, if you’d like to elaborate, I’m all ears.
Bryan Campbell
Although this thread is quite old the topic is still very relevant. I agree that convergent models require a different way of thinking about how Agile can/should be applied. There is still plenty of room for Agile mindset and practices but they need to be orchestrated in a different way. A large SAP upgrade for example is different than developing a new mobile app. I think this is where true hybrid models of Agile development exist. They need to co-exist with more traditional organization structures and evolve to bring both into a more responsive, value driven environment with sufficient structure to satisfy organizational spending and management priorities.
Brad Williams
Mike,
Epiphany regarding your statements on software business models and that process needs are different for each. Thank you.
“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.”
This is your approach to convergent business models? I hope you provide more details in follow up posts.
Yeah… definitely have more to write. What I’m doing right now is explicitly laying down some foundational concepts to start building the argument for how we scale agile in large organizations. Like I said in the first post in this little series is that, in order to get to where you can have an intelligent conversation around scaling agile, you have to deconstruct some myths and preconceptions, that people hold, that just don’t work. It’s frustrating seeing people try and fail with Scrum without understanding why.
Matt Block
Great post Mike! I like the analogies. Looking back I’ve definitely been in some of these situations, living in a company that has traditionally had a convergent business model but is looking to move to agile. While I’ve definitely tried to steer them towards a more emergent model, I don’t think we’ve ever been explicit enough about it or had buy in at a high enough level. So I’m sure you can guess that caused quite a few struggles.
In your experience, do you see a lot of software product companies that think they are trapped in a convergent model? I feel this may be true, especially for products in more established markets. Software products in these markets have been around for a long time, and a vast majority of the players have had convergent models. Being the first to switch to an emergent model, even if you think it is the right move, can be tricky. Not only is this a major change inside your company, especially for your sales force, but it is also a change for your market. Your clients are used to operating in a convergent model and dealing with companies using that model. They are likely going to feel like they are losing power in this new arrangement, so obviously the sales force would have to be able to deal with those concerns. My personal opinion is that an emergent model provides more benefit to everyone involved, but making the switch in a situation as I described above would definitely be a difficult one.
I agree with you Matt, it’s tough. Dealing with them in their current state is what we are really trying to address. Folks at the team level are not going to convince execs to adopt agile along with an entirely new way of conducting business. The execs basically say, you guys go do that agile stuff as long as you still operate within fixed time, cost, and scope boundaries necessary to run our business. The good news is that there is thinking and approach to help lay the foundation for a successful agile adoption in a convergent company, that respects the current state, but positions them to become more emergent. That’s where I’m headed with my next few posts. I’ve got the next one written… I think it’s scheduled for Monday ;-) Thanks for reading.
Eddie
Very thought provoking piece, I look forward to the next posts. It’s an interesting dichotomy that you’ve set up Mike, I don’t necessarily agree fully with it but that’s because I’m looking at it from my situation and experience, which one shouldn’t generalize from. Regarding the chess analogy, for me on my current “Scrumfall” projects in a fixed time/cost/scope environment it’s more like the game is constrained (fewer pieces on the board, maybe not so many squares, not all the moves available, etc), we can still play chess but it’s less creative and often frustrating because we know it could be better if the restrictions were lifted, but we still get to the end successfully rather than fail completely, and benefit from the greater visibility and adaptive controls Scrum provides.
Thanks for the comment Eddie. My point is that lifting restrictions in a convergent company will create chaos. The way these companies are today, they have to commit. Being a little better by adopting some of scrum isn’t enough. We are going to start exploring the patterns that allow convergent companies to be successful with agile without having to change (at least initially) the underlying business model.
Paul
Really excellent post, Mike – I think you’re spot on with your analysis. I can’t believe any Engineer or Product Manager who has worked in a’traditional’ (i.e. convergent) company has not experienced aspects of what you describe. Your Emergent/Convergent paradigm really clarifies the key issues that define success. My only objection would be a subjective one: don’t Convergent companies NEED to adapt if they are going to survive in the digital age? Google, Facebook and Amazon have business models that work and are well positioned for success in the future – if traditional organisations don’t follow their example then are they doomed to go the way of Blockbuster? i.e. Analogue in a Digital World?
Absolutely Paul, but pretending they’ve adapted when they don’t have the underlying structures, governance, or metrics in place is dangerous. That is where this thread of posts is actually going. How are we going to orchestrate a real, systemic transformative change program to get companies really more agile. Thanks for the comments and kind words.
Eddie
@Mike, you’ve summed up the issue brilliantly: “lifting restrictions in a convergent company will create chaos”. I can very much relate to that as I attempt to move Agile thinking into upper levels of my organisation; it’s certainly helped shape my thinking and subsequent actions.
Steven Gordon
I like analogies, too, and I am also a games aficionado.
Chess is more like a convergent business model (it is a game of “perfect information”), whereas many other games, such as backgammon, are games that are more like an emergent business model. In backgammon, it is unpredictable how the game will play out, so you are better served by a shorter planning horizon and flexibility. Chess would favor deeper planning.
Nevertheless, in either game, there can be surprises, so responding to the reality at each point in time should take precedence over the plan. Likewise, I have never seen a business plan that is immune to surprises.
Thanks for the comment Steven. The Chess analogy wasn’t so much to illustrate emergent/convergent as to basically say, you are following the rules and playing the game as not.
I agree that plans change and we need to adapt. As we go deeper into this, we’ll find there is a middle ground between making no commitments and committing at the right level of abstraction and knowing how to negotiate in the small.
Right now, I’m just untangling some language and laying down a conceptual foundation for future conversation. Thanks for the comment!
Brendan Marsh
I’m with Ron, if your assumption is that an Agile mindset is not suited towards a convergent business plan, then you’re treating it as a process and not a commitment to continual improvement & short feedback cycles. Feedback is not just customer, marketing or user focused. Iterative delivery should provide feedback from other factors that are vital towards planning and hopefully meeting a delivery date, such as feedback from your team or feedback from your system (automated tests for example). Using an emergent delivery method allows you to learn about these factors sooner, rather than later. Agile is not a process, its a commitment to being realistic about what your team & your organisation can accomplish & continual improvement. Fixed scope, budget & time or not, this is still hugely important and I would argue for emergent methods to solve ANY complex problem. At the end of the day, if your business plan & delivery outline is completely and utterly unrealistic, don’t you want to (start to) find out in a few weeks rather than wait till its too late?
So Brendan… you are basically saying that agile works for convergent business models because companies should recognize reality and adopt an emergent business model?
Just so you know where I’m going… over the next few posts I’m going to continue to lay the foundation for my argument and then lay out how to adapt agile to convergent organizations. Telling organizations to deal with reality and become more emergent doesn’t work.
You may have great success with a team or two, but I’m talking about enterprise agile at scale. Just my take.. of course you are welcome to your opinion, we probably just don’t share the same experiences. I sincerely appreciate the time you took to leave a comment!
Itamar
Hey Mike,
Really like this series. The common theme that I see in this comments, and ties well to the question that I had as well, is that the terms “Agile” and “Scrum” have lost clear meaning as they became more commonly used. Jim Benson called this phenomenon “Semantic Extension” in his LKNA ’13 talk.
So when you’re arguing that practicing Agile/Scrum creates friction with a Convergent Business Model it’s being interpreted inconsistently, since different people have different definitions for Agile/Scrum.
It’d be great if you can be more specific in calling out the particular concepts/practices of Agile/Scrum that you feel create the most friction with that business model.
Thanks Itamar for the comment. At the end of the day, it’s not really the practices of Scrum that are the problem, it’s often the attitude of the practitioners. I was talking to someone yesterday who said “we are agile, we only plan two weeks at a time”. The problem with that mindset in predictive-convergent companies is that we have no vision for the future and no way to commit to a larger scope. If I had to pick on a practice in particular, it’s the flat, stack ranked backlog. As you know, we prefer maps of user stories with different management constructs (lean, kanban) for each level of the hierarchy and different planning horizons for each level of abstraction. I like the idea of making commitments, and setting budgets at the higher level of abstractions, and collaborative rolling-wave requirements decomposition on three month planning intervals. Techniques like this allow us the mindset to converge on business outcomes rather than make it up as you go. I don’t think anything in Scrum specifically precludes doing this, but it’s not how Scrum is commonly articulated, and really far from how Scrum is commonly practiced. Thanks again for the comment.
San
Mike, I just came across this and this is very interesting blog on the convergent/emergent models. I have worked in large organizations that had small functional teams and Scrum worked – since the functional team had autonomy to keep them in the emergent mode. Now I am in another large organization – who claims that they are playing chess – but I do not even recognize the board they are playing on. It is extremely convergent and the management thought of doing “real-scrum” is considered as a befitting process for prototyping only and not for real product development. I am getting curious on your build up and I will surely follow this. There is never a one size fit all!!!
SMK
Good article.
Elijah Connor
Hi, I liked this post a lot.
I don’t think it’s that easy to get oriented in what doing Agile means for different types of businesses. I had this problem myself a while back. We thought we were agile, because we had spritns, but other than this we did everything else like we always have (doing reports, holding a meeting every other day. It wasn’t until someone brought in a consultant (yes, we needed help), that we got the difference.
Just read a nice little post on this, which could have helped us along back then: http://kanbantool.com/blog/how-to-assess-your-business-agility, that I’d like to recommend to others.
I really look forward to reading the other posts in here, very good!
Linda Fane
Hello Mike – I just ran across this post and wanted to let you know that it provided me a major “aha” moment that I am still contemplating. I never have had a name for the emergent versus the convergent business models but definitely have had a “feel’ for them being an experienced PM for many different types of clients. I am passionate about agile as a revolution in organizational mindsets and its healthy challenge to “command and control” . I hadn’t thought about the business model impact. Something to ponder. Thansk and I look forward to finding your follow on article.
Ritchie Poon
Hi i thought the Convergent Business Model will more go towards the Water Fall model (and then those undefined part and be on a sub model based on Scum). Eg. Building a Restaurant has those FIXED model, however then certain lower level details… of Design / Product Mix / Pricing… then the Agile will catch up..