You Need a Static Organizational Model
Okay… I want to make an assertion here. In order for agile to work, you’ve got to understand the static organizational model for your company. Why? If you are organizing around things that are transient, like projects, you are doomed to fail. Agile requires teams that stay together, period.
Most organizations are organized around one static model, the resource team. This is our much beloved organizational pattern where we pull all the BA’s into one group and all the developers into another group. People are assigned to project teams, but the resource organization is the strong side of the matrix, the project organization is the weak side. Resource teams don’t deliver value by themselves.
Agile asks us to organize around the parts of the business that deliver value, and in common practice, that is usually the product. It makes sense, we make products, let’s organize around the stuff we make. This is where we get the whole, give the team what they need to deliver, and they’ll give you working software at the end of every sprint routine. Single PO + Single Team = Delivered Business Value.
That works awesome in small product driven organizations. In the complex organizations we’ve been talking about here, this approach is problematic. Why? Investment is not always level across products. Sometimes I need a full staff and sometimes I don’t. Sometimes I want to improve one set of product capabilities and just keep the other capabilities in more of a steady state.
Uneven investment in products over time is what drives our obsession with project work. We know that we don’t need the same people doing the same thing all the time, so let’s deploy ‘teams’ to go build some value for us. When they’re done, we can break them up and have them go do something else. From an agile perspective, the problem is that this approach doesn’t keep teams together over time, and that makes it really hard to really do agile.
I’ll admit, you could create multi-disciplinary teams and run your project work through these static teams. This is on the right track, but still breaks down when the skills required project to project ebb and flow. I’m all for building teams around specializing generalists and bringing work to teams, but in complex organizations it is a stretch that every team is going to have every skill they need to do every project.
So… back to our static organizational model. If we are going to keep teams together, we need to organize the teams in our complex product organization around the things that aren’t likely to change over time. We need a static model for the organization that is resilient. One that reflects the core delivery capabilities of the enterprise, capabilities that can be staffed and deployed to solve specific business problems
In our complex product example, the delivery capabilities might be the various products delivered by the organization. The services they provide to external customers, or to other internal products, become the capability the organizations is expecting them to deliver. A capability could also be something like marketing, or sales, or support, or even some external service provider that you depend on for a fully functional product.
Before you begin your agile transformation, you need to think about your organizational structure. Ask yourself if you are building teams around stuff that will predestine them to be broken apart when the work is done. Are you piloting something that has no chance of long term successes when it get’s out into the wild? It is important to understand what the non-transient, static model for your enterprise looks like, first.
Then, and only then, should you decide where to pilot your first agile team.
Comments (6)
Paul Boos
Interesting post; there has been some talk about reorganizing our administrative division here in EPA/OPP. We support not only IT work for the organization, but also human resources, budgeting/finance, and a few other administrative tidbits. I'm not privvy to the details of this thus far, but within the branch that develops and maintains software, we have been slowly moving to organizin it a bit by the portfolio of applications. We coudl extend this in the IT portion of the division by creating a team that deals with hosting and security of it as well as engagement of our business lines (perhaps creating a long-term position for the business side to be a part of the team). This would increase our stability of teams on delivering value over the full life-cycle.
And that last sentence will pick-up on what I have noticed a lot about Agile Coaching, so maybe we need to tweak our language a bit. We do tend to talk about delivery of value as projects, we talk less about the full life-cycle of a system (the app, hardware, people, and process). We tend not to talk about sustainment.(I say tend as there are some discussions, but not as many as I think the business side may want to here.)
I'll leave it there as I don't have any answers yet, but nothing more than a bit of an observation.
Cheers!
Paul
Karl Scotland
Thanks Mike – you've just given me an insight which completes both sides of a coin.
I've long thought that just reducing batch size in a "waterfall" process will deliver benefit.
This post suggests that just changing the org model to be capability based could also deliver benefit.
Combining the two, org model and batch size, is when you get really powerful change, and is at the core of Agile.
Karl
Mike Cottmeyer
Karl, I think you hit the nail in the head. I tend not to talk quite as much about small batch sizes, although that is a critical factor. Smaller projects, smaller MMF, smaller user stories. All increase flow!
@FlowChainSensei
Nice presentation of the issues here, but draws the wrong conclusions, imo.
Aside from organisations rarely being static, there's the question of whether projects add any value (I see them as a zero-sum game at best) and whether teams are the best solution to some of the challenges you describe (I believe not).
"FlowChain" is an alternative organisational model which addresses these challenges without either projects or standing teams.
– Bob
Mike Cottmeyer
Bob,
I tend to think about organizing around business capabilities. I can build agile teams around these capabilities, maybe similar to how lean things about a work cell. Then I'll use a theory of constraints, lean value stream model across the delivery teams to manage the end to end flow of value.
I really like the idea of agile teams managing the complexity within the work cell. I don't like the idea that value streams are a string of individuals manipulating the product (not sure if that is what you are saying or not). My personal belief is that humans desire connection and being part of something.
I think lean and agile are complimentary, but only if we are taking into consideration the human side and the need for connection.
@FlowChainSensei
Mike,
I agree entirely about the human side and the need for connection (and belonging). Almost nothing is more important that that, imo. I just don't think that the standing agile (e.g. 5-7 people) team is necessarily the only or even best way to make that happen.
As for business capabilities, better (from a business owner's perspective) to vest that evolving capability in "the organisation" rather that individuals (whether within teams or no).
BTW I don't like the idea that value streams are a string of individuals manipulating the product much, either :}
HTH
– Bob