How to Build a Large Agile Organization
Written by Mike Cottmeyer Sunday, 28 March 2010 12:54
Okay… consider this scenario. We have a 300 person IT shop responsible for developing control systems that automate large buildings. These systems require front end developers, middleware developers, firmware developers, and hardware engineers. A feature in this system requires us to write code that touches every layer of the overall systems architecture. As it stands right now, the teams are organized around the major subcomponents within the overall solutions framework.
How does a company like this adopt agile? First inclination might be to break up the component teams and create cross-functional feature teams. Each team would have some number of front end developers, middleware developers, firmware developers, and hardware guys… right? The general idea is that any one of these cross functional feature teams would be able to write software for any part of the overall system. Everyone on the team becomes a specializing generalist.
While it’s not impossible to cross train someone who specializes in UI development with someone passionate about firmware (or hardware)… but my guess is that most folks aren’t up for it. My bet is that most organizations don’t have the test coverage to make this kind of experiment safe. I’ve talked with several organizations that have given this a shot, and the change was so disruptive, they couldn’t get anything done. Seriously… nothing done.
I’d like to suggest for a moment, that our goal here isn’t really creating cross- functional feature teams; the goal is to build teams that have everything they need to build an increment of working software. I think that there is a difference between the two. To be agile, we need to to build teams that can stay together over time, become high performing over time, and build trust with their customers over time. They need to build working product.
We tend to assume that in order for this to happen, we need to organize teams around end-to-end features. I agree with this approach when we are talking about small teams and small products. This advice breaks down when we talk about larger teams, and larger… more complicated… more technologically diverse product lines. The agile community needs a more stable, more robust scaling metaphor for discussing these kinds of organizations.
Here is how I have started thinking about this over the past few weeks, and I am starting to think that the language works… let’s start talking about building teams around those things in our organization that are least likely to change.
If we are a small product company, with a single product… the thing that doesn’t change might be a product. If we are a larger product company, with a more complex product offering, I might organize teams around a somewhat static grouping of features. If we are in a really large organization, one with multiple interdependent products, where investments are not level over time… the thing we organize around might be a component or some set of services.
The thing is… it’s not always the flow of features into a product that is often the least transient. Sometimes we can’t build a team with enough specialists… or specializing generalists… to get the job done. When that happens… and at some scale it will happen… we want to start looking for the stuff that doesn’t change. When we find the stuff that doesn’t change, that is where we start building agile teams. That gives us our best shot at keeping teams together.
When you take this approach, you have to keep in mind, that there is no longer any one team that is responsible for end-to-end value delivery. Each team delivers ‘done-done’ work every iteration, but as an overall enterprise, you’ll have to develop the capability to manage the flow of value effectively across each of your various agile capability teams. This is where agile stops giving good guidance and we need something else.
That something else is Lean/Kanban.
So think about this… build agile teams around the persistent objects in your enterprise, whatever they happen to be. Use Scrum or XP or Kanban or whatever other agile method floats your boat at the team level. The teams can become hyper-productive and have as much agile goodness as you can get out of them. To scale all this agile goodness, use a Lean/Kanban approach to manage the flow of value across teams.
So, getting back to my initial question… what’s the most effective agile strategy for our large control systems company?
Organize agile teams around the front end, the middleware, the firmware, and the hardware. Create an enterprise backlog of value features that get broken down into user stories and distributed across teams. Subordinate each team’s backlog to the enterprise backlog, and create a pull system, where new features only get started once the teams have capacity to work on them. Set work in process limits for each team to reduce the amount of work we can get started before we roll back up into a value feature. Invest in constrained capabilities to improve the overall flow of value across the system.
Make sense? Any questions?