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.Learn More
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.Learn More
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.Learn More
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
They’ve heard quite a bit about Agile and Scrum and like the idea of getting to hyper-productivity in just a few iterations. Let’s say that this team moves mountains and gets everything they need to be successful… they get the team through agile bootcamp and bring in a coach… they get a top-notch product owner, identify a scrum master, they build the ideal cross functional team, they do all the right XP practices, they do iteration planning, daily standup meetings, demos, and retrospectives.
This is a team that would make Ken and Jeff proud. No Scrum-but here.
The product owner does a great job working with all the stakeholders… both her external customers and the other product managers in the organization. She balances the needs of her market with the needs of the other products that are dependent on her product to be successful. She crafts a backlog that is full of the right features, in the right order, to get everyone all the features they need when they need them. The team starts building… and starts getting really good at delivering done-done software every two weeks.
Just as it should be… right?
We’ll… yes and no. The PO for the Credit Card Processing team is probably doing a great job satisfying the needs of her Credit Card Processing customers… that is a good thing. It also sounds like she is doing a great job meeting the needs of her internal stakeholders. But what about that new Payment Processing product that the business is counting on for a significant part of next year’s revenue? How has Scrum impacted the overall flow of value for the entire company? The short answer is… it hasn’t.
Clearly, this Scrum team has done it’s part. I’m not even suggesting that this is a Scrum problem. But, if the Payment Processing initiative fails, where does that leave our Scrum team? It leaves them in the same boat as everyone else… downsized, outsourced, and reorganized.
But Mike you say… what else can I do? The only part of the system I own is the Credit Card Processing engine. I’m doing the absolute best I can with what the people and resources I have been given… I have been successful to the best of my ability. You know what… you’re right… you have been successful to the best of your ability. That is what is so frustrating with localized Scrum implementations, it just doesn’t matter how good you do Scrum. How well your team adopts agile doesn’t matter… how well you adopt Scrum doesn’t matter… at the end of the day, all that matters is the value the business get’s from your efforts.
In this case, they didn’t get the ultimate benefit and the Scrum team suffered. Here is what you have to keep in mind… if the system is bigger that your Scrum team… if the enterprise value stream requires more teams that just yours to deliver… you need to take that into consideration as you adopt scrum. Getting good at team based agile is NOT ENOUGH when it comes to adopting agile in the enterprise… it is NOT ENOUGH when you are part of larger, more complex products. All the pieces have to work together.