The Gist of My Agile Dev Practices Talk

I know this is really high level... but I want to see what kinds of questions this level of description generates. Does it make sense? I'm really trying to figure out how to explain some of these ideas with fewer words.

Talking Points

1. Scrum works under certain conditions, if it works... use it.

2. Scaling scrum works under certain condition, if it scales... do it.

3. Scrum requires significant transformation for most organizations.

4. People underestimate what it really means to transform.

5. Transformation is too disruptive for many companies, these people will fail.

6. We need a credible transition strategy for everyone else.

If you are an 'everyone else', go read my last post... I'll wait.

7. Define a static organization model.

8. Find the constrained capability, create an agile team there.

9. Do agile for a while with that team, do it again with a few others.

10. Define your first agile multi-team project. Use expand and collapse Kanban, across teams, to limit WIP.

11. Define your next few multi-team agile projects, now you have a portfolio. Use expand and collapse Kanban, to limit projects in progress (PIP?), and manage WIP across teams.

12. Define capabilities outside of IT... extend agile to them.

13. Wash, rinse, and repeat

Key Concepts:

1. Scrum will break in complex product organizations.

2. Use a Static Organizational Models as the basis for agile pilots.

3. Use Lean and Kanban to intentionally limit WIP at the project level and the team level.

In general the talk was well received. A handful of people walked out... maybe this wasn't what they expected, maybe they just needed to use the restroom ;-) A few folks challenged the ideas I presented... Bob Galen and I had a follow-up conversation. More than a handful stayed after, talked to me in the hallway, and took business cards.

This is not everyone's problem... but if it's your problem, you need to go into your agile transformation with your eyes wide open... and some credible strategies for incrementally adopting agile.

Subscribe to Leading Agile

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.

Subscribe to Leading Agile

Scaling Agile Past the Team - Agile Dev Practices Edition

If you guys have been following my updates here and on Twitter, you know that I'm out at Agile Development Practices in Vegas this week. I'm speaking in about an hour... and just putting the final touches on my presentation. The content is not fundamentally new, I think though I'm learning how to talk about this stuff better. So... here is the slide deck I plan to go live with. Have fun, and let me know if you have a group that would be interested in this topic. Depending on your schedule and mine, I might be able to come out and do the talk for you live and in person!

Scaling Agile Past the Team - SQE Agile Dev Practices West

View more presentations from Mike Cottmeyer.

Subscribe to Leading Agile

Adopting Agile Presentation

Last night I had a great opportunity to deliver this slide deck to the Turner Agile User Group here in Atlanta. The talk was on Adopting Agile in the Enterprise. I am still working on the overall message and consider the presentation in beta. This will end up being the deck that I do for the Oredev conference in Malmo later this year.
Adopting Agile

View more OpenOffice presentations from Mike Cottmeyer.

Subscribe to Leading Agile

Subscribe to Leading Agile