Agile Zone is brought to you in partnership with:

Mike is a certified PMP project manager and a certified ScrumMaster. Mike was involved with the creation of the DSDM Agile Project Leader certification, holds this certification at the Foundation, Practitioner, and Examiner levels. Mike was named an honorary member of the DSDM consortium and served on the board of APLN and the Lean Software and Systems Consortium. He currently co-leads the PMI Agile Community of Practice. Mike is a DZone MVB and is not an employee of DZone and has posted 143 posts at DZone. You can read more from them at their website. View Full User Profile

You Need a Static Organizational Model

08.17.2010
| 2328 views |
  • submit to reddit
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.
References
Published at DZone with permission of Mike Cottmeyer, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Emma Watson replied on Fri, 2012/03/30 - 5:55am

Yeah, agree with Mike, the PO is an utter dysfunction, designed by programmers for programmers because they didn’t like speaking to business people. That we speak about these processes here as if they, and a dysfunctional role, are important really does show how mucked up our thinking has become.

Swing

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.