There Are No Spherical Chickens!

Just in case you are wondering… I’m not suggesting that our Credit Card Processing team shouldn’t do Scrum. I’m not suggesting that they shouldn’t improve. What I am suggesting, is that if the organization stops with this one team, they won’t get the business benefit from Scrum that they expect. All the value created by the Credit Card Processing team will be obscured by the underperformance of everyone else. Furthermore… you shouldn’t be surprised when your Scrum team gets downsized, outsourced, or reorganized… just like everyone else who didn’t deliver.

If you don’t have the ability to influence the rest of the development organization, it probably won’t make any difference if the Credit Card Processing team adopts Scrum. Sure, the team will probably enjoy their work more. Maybe if they get really good at delivery, they can jump in and help out some of the other teams. If the culture is open enough, maybe everyone else sees the benefit of Scrum, and they become the catalyst for more widespread adoption. That just hasn’t been my experience with this kind of grass roots hopefulness.

Most large companies I have worked with are full of silos, full of politics, and full of protectionism and fear. Accountability structures don’t necessarily reward working well across teams. Incentives are geared toward individual performance first, and team performance second… if at all. Organizational or divisional objectives are so far off people can’t directly influence them. We are allowed to build empires that only serve to grow the headcount in our particular group, often at the expense of our ability to work well with those around us.

The thing we most often forget when adopting agile, is the impact that agile needs to have on the culture of our organization… and the impact it needs to have on the fundamental structures that reinforce that culture. So… I have to tell you I am a bit cynical about the whole… give agile a try and everyone will be enamored with it’s goodness routine. Most people would rather try to be individually successful in the system they know, than risk being unsuccessful trying something risky and new.

In a complex product, all the pieces and parts have to work together to deliver end business value. If you agree with that fundamental premise… and you are willing to agree that team level adoption does not typically spread (unintentionally) out to the rest of the organization… you are left with two options. You can 1) subordinate your Scrum team to the delivery cadence of the rest of the enterprise… or 2) plan to systematically introduce Scrum everywhere else, and learn how to manage the flow of value across the various Scrum delivery teams.

I am clearly in the camp of option 2.

Before we wrap for the day… I want to go back to why I think this topic is so important. A year or so ago, Ken Schwaber famously said, and I paraphrase: ‘75% of the organizations using Scrum won’t get the benefit that they hope from it”. If you care about agile, and you believe in the value that it brings to people and teams, and you have seen it work, that is a really depressing statistic. Our community’s response seems to be… get more dogmatic about Scrum. If you aren’t doing Scrum by-the-book, that is why you are failing.

I’m sure there is some of that going on, I am sure that there are some people bending Scrum to hide their dysfunction. My take is that this complex product idea strikes more the heart of why the underlying dysfunction exists. Vanilla Scrum does not work for these organizations because the value stream is bigger than a single team. Rather than assume that we live in a world of spherical chickens, I’d like us to explore how agile works, why it fails, and most importantly… what are our options for making things better when we can’t wave a magic wand and change our cultures and structures overnight.

So… in the context of our financial services organization, and our Credit Card Processing team in particular… I want to explore a bit more why, in the absence of a broader change initiative, you have to subordinate their performance to the cadence of the rest of the enterprise. After that we’ll get into how to scale Scrum from the single team, to multiple teams, to projects and portfolios, and then the enterprise. We’ll explore blending approaches, how to leverage Lean and Kanban, and how to deal with multi-tiered values streams. We’ll talk about how to break down requirements, deal with architectural challenges, how to do planning and context setting, etc.

I might take me a while… be patient.