Saturday Morning Ramblings… Bloody Stoopid Mary

Last Updated on Thursday, 15 November 2012 12:35 Written by Mike Cottmeyer Saturday, 16 October 2010 03:19

Good morning everyone… I’m on a plane up to Philly to do a little work with the PMI Agile CoP. Delta bumped me to first class and I’m halfway through my second Bloody Mary. I’m asking that you be patient with me while I ramble on here a bit. I’ve got a nagging issue on my mind that I want to explore with you guys while I’m in transit this morning.

I was on my way home last night, on my way to the Buford High School homecoming football game, when my good buddy Dennis Stevens called and asked if I wanted to get together for a little while. I had a few hours until I needed to be anywhere, so I was like sure. You’d think that after a few years of knowing each other, we could find something else to talk about, but the conversation quickly turned to Scrum and Kanban.

Hyperproductivity in Scrum

Last Updated on Thursday, 15 November 2012 12:50 Written by Mike Cottmeyer Monday, 14 June 2010 12:59

Last year sometime, I had the pleasure of hearing Jeff Sutherland speak at the Agile Atlanta group here in town. One of the things that Jeff always brings up in his talks, is that Scrum creates hyper-productive teams. I asked him how he defined hyper-productivity, and how he measured it. He told me, but rather than explain my recollection of what he said, I want to reference how he explains it in print.

According to his paper Shock Therapy: A Bootstrap for Hyper-Productive Scrum:

“We define Hyper-Productivity here at 400% higher velocity than average waterfall team velocity with correspondingly higher quality. The best Scrum teams in the world average 75% gains over the velocity of waterfall teams with much higher quality, customer satisfaction, and developer experience.”

Pretty impressive, but I am curious what the improvement is measured against. Going deeper into the Shock Therapy paper, the results from their MySpace experience say that:

“The baseline velocity (100%) is established for a team during the first Sprint. The Product Owner presents the prioritized Product Backlog in the Sprint Planning meeting. This is estimated using Planning Poker and story points. The team selects what can be accomplished during the first Sprint and the Product Owner determines exactly what is “Done” at the end of the Sprint. The number of points completed is the baseline velocity.”

When I first read that, I was like “what am I missing here”. Hyper-productivity is defined as improvement over the first iteration of a brand new Scrum team. That didn’t strike me as a very fair metric, you’d think *most* brand new teams would get dramatically better after a few weeks of working together, using Scrum or not.

But here is their key assertion that supports the measurement:

“At MySpace, the baseline velocity is often significantly higher than their previously chaotic implementation of waterfall, so the baseline is conservative”

I don’t know about you guys, but I’m kind of bothered by the assumptions, and the numbers that support them. Can we always assume the first sprint of a Scrum team is better than the same team doing Waterfall? I’m not sure. Are all Waterfall projects chaotic? I can tell you first hand they aren’t. It might also be interesting to see the team stabilize first, and then see how much better they’d get by systematically removing impediments.

These numbers have been nagging me ever since I read this paper and first heard Jeff explain them. Is it only me? What am I missing here?

Subordinating the Scrum Team

Last Updated on Thursday, 15 November 2012 12:50 Written by Mike Cottmeyer Monday, 17 May 2010 01:01

Agilists intuitively get that it’s a bad idea to build an inventory of detailed specs way ahead of when they are going to get turned into software. Why? Because we know that as our product emerges, we are going to want to make changes to those requirements. There is a real risk that a lot of that work will end up being waste. That’s a big part of why we document agile requirements as user stories… we want the placeholder now, but we don’t need the details until we get closer to building that part of the product. It keeps our options open and our overhead low.

Building an inventory of requirements has a more insidious impact than just opening up the possibility of waste. Sure, we risk specifying stuff that the business might not need, but we also build in assumptions and risk that can’t be validated. Everything that we define now, everything that can’t be built and tested immediately after specification, represents something that we’ll have to validate or mitigate somewhere down the road. Those uncertainties make it really hard to forecast when we are going to get to done. They make it tough to be predictable.

Furthermore, requirements gathering an analysis shouldn’t be done in a vacuum. We know that we’re going to want some help from our development team to discuss what’s possible from a technology perspective. When we pull our team into meetings to discuss these things, we are taking their attention away from the task at hand. Our team is working on the highest priority features, and here we are pulling them away to help forecast lower priority requirements that may or may not ever make it into the product. It’s a pretty solid formula for going slower than we have to.

Even though we may have some capacity to do the requirements work… and it would be nice to get ahead of the game a little… it is not something we generally do on agile projects. Managing all those requirements changes, tracking all those assumptions and risks, and absorbing all the productivity impact to the development team is just too great a cost. We KNOW it is going to cause us problems down the road. Any benefits we’d gain from getting ahead of the requirements work would be lost due to the overhead necessary to maintain our requirements inventory. That inventory slows us down and makes us more resistant to change.

We understand… in this kind of a scenario… that the team has to subordinate the requirements gathering process to the overall production cadence of the delivery team.

Now, let’s extend this metaphor up a little and talk about our financial services company… and specifically our new hyper-productive Credit Card Processing Scrum team. With regard to the rest of the organization… our Scrum team is able to produce working software much faster than everyone else around them. The question we’re dealing with is… SHOULD they produce working software much faster than everyone else around them? In this context, under this set of circumstances, I’m saying no.

I’m suggesting that the Scrum team in our complex product organization becomes very much like the requirements gathering function in our earlier example.

When the Credit Card Processing team builds software features faster than the rest of the organization can consume those features, they risk the possibility of waste and rework. They introduce assumptions and risks that have to be managed and mitigated throughout the life of the project. They will disrupt the other development teams around them and force those teams to multi-task. The other teams will be forced to pay attention to features that they won’t be ready to build for another several months. All that code will slow us down and make us resistant to change.

While it is technically possible for the Credit Card Processing team to get a head of the game… and it might make them feel more productive… it might be great for their team morale… ask yourself what impact they are having on the rest of the organization. It might not be as positive as you think. So… for all the same reasons you might ask a PO or a BA to slow down writing requirements to fill the product backlog, you might want to ask your Scrum team to slow down building software until the rest of the organization can catch up.

It’s counter-intuitive, but if you start thinking past the single team, it might be exactly what you need to do.

There Are No Spherical Chickens!

Last Updated on Thursday, 15 November 2012 12:50 Written by Mike Cottmeyer Wednesday, 12 May 2010 11:40

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.

Can I Do Perfect Scrum and Still Fail?

Last Updated on Thursday, 15 November 2012 12:50 Written by Mike Cottmeyer Tuesday, 11 May 2010 01:54