The Two Faces of Agile
Some folks are using agile to invent. They are trying to figure out the right products to build for markets that don’t even know what they want. They are experimenting, learning, and adapting their approach based on super-fast feedback cycles… and the outcomes, the products they are trying to build, are emergent. The end goal isn’t necessarily clear at the start.
Other folks are using agile differently.
These guys are also trying to figure out the right products to build, but their markets have a predetermined notion of what to expect. These teams also experiment, and learn, and adapt their approach on super-fast feedback cycles… but the outcomes, the products they are trying to build, need to converge around set expectations and emergent outcomes aren’t always valued.
To effectively introduce agile into your organization… you need to know what kind of organization you are living in. An organization that needs emergent outcomes may reject keeping a fine grained story backlog or doing any kind of long term release planning. Likewise, companies that need convergent outcomes may reject sitting with a client and figuring it out as you go.
It always, always, always comes down to context.
Both an emergent approach and a convergent approach can work just fine, depending on your particular context. The trick is knowing the goals of your business and adapting your language and approach accordingly. If you are struggling to get senior leadership to see the merits of agile, maybe your are selling emergence when that’s not what your execs are really buying.
Comments (7)
Bob Marshall
Surely an attribute of each product (or product line) rather than of the organisation as a whole?
– Bob
Peter Saddington
Agree, but we need to take a deeper approach to understanding how to engage effectively with executives, etc. :)
Depends on the organization Bob. You might have an R&D group where emergent outcomes are valued and a Product Development group where convergence is the way to go. It’ s very situationally specific. I hear agilists talking all the time about inspecting and adapting and trying to figure out the best product to build. Sometimes agile can be, and should be, applied in a what this is focused on early risk reduction, proof of concept, and convergence on expected outcomes. I’ll probably write some more on the differences in the coming weeks.
Don Kim
I find that I can be in a emergent or convergent situation based upon the project within the same organization. Sometimes simultaneously. This despite the fact that the organization as a whole is “convergent” or sustaining type.
For me Peter this is less about team dynamics and more about business objectives. If I sell a fixed price, fixed scope, fixed time deal to a customer… my goals as an agile development team becomes different. I’m not trying to figure out necessarily what to build… but what can I build within the time and cost constraints I’ve established. This is less a discovery model and more a rapid risk reduction model. In both cases there is some aspect of customer collaboration, making sure we are building the right product, and so on… it’s just that the openness to learning may have shifted and the outcomes are more predictive out of the gate.
I’m not advocating that this is how we run our businesses… my point is that this is how many businesses are run. While we are shifting to a more collaborative model with our customers, we need a credible strategy for optimizing business outcomes, managing expectations, making and meeting commitments, etc. If we don’t ‘sell agile’ in language that our business stakeholders understand, it won’t resonate with them and it won’t be worth the investment. Agile can go a long way toward increasing predictability and ultimately building trust with our clients and that can lead to more openness to a broader set of possible outcomes.
Ben Linders
Fully agree that fir Agile (or any methodology) to succeed, it should provide a solution to the problem at hand. Or better stated, the problem as it is percieved by the stakeholders. If there is a need to innovate, then Agile can help you, and there are lot’s of good ideas in Lean Startup. If you need to get your product out to your customers more quickly, take a look at lean software development. Which will probably also lower your costs by removing waste in your processes. If you have a complex problem at hand where a solution is needed, Agile can help you to work together effectively and iterate towards solutions.
So yes, it depends, and depending on what you need a different approach can be chosen. Which has to be clear for all involved to succeed.
Thanks for the comment Ben!