If you're not keeping up... you've got some homework to do. My last post called "What Do I Mean by a Complex Product" is required reading before you read this post. If you've got a minute, go read that post and then come back to this one... thanks! - Mike
Okay, so let's explore our Credit Card Processing team a little more. They are in a large organization that is delivering large, complex products. They know that the traditional way of planning and building software isn't really working. The big up front requirements analysis and the the big up front design is really slowing the organization down. It routinely takes 18 months or more to bring any new product offering to market. This company is at risk of having smaller, faster competitors take their market share. This team wants to do something about it.
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.
We'll unpack this more over the next few posts... for now, let me know what you think.
Subscribe to Leading Agile
Right. Localized Scrum isn't enough for an organization to be successful. I agree totally on that point and look forward to the next few posts from you on this topic.
ReplyDeleteBut that doesn't mean the local team should not try to improve. Although it might not matter for the eventual success or failure of the enterprise (due to the failure of another team or due to the failure of senior management to optimize the whole), it matters to those individuals who will be downsized. It matters to them that their skills are sharp, that they feel good about their output, and that they can find new work more quickly than average.
Mike,
ReplyDeleteI like where you're going with this epic... And you are absolutely right about team based agile within a larger system being tough. Distributed scrum teams e.g. when outsourced development is used to complement in-house development struggles with similar issues. How can only part of the extended team adopt agile/scrum and expect to be successful? Jeff Sutherland has written about "Distributed Scrum" implemented by hyperproductive offshore development teams as a solution to this challenge. I look forward to reading about what you suggest as a solution to the challenge that you posed. Thanks!
Thanks Gavin... I've got a few more posts in me... but not written yet... so we'll see how the muse moves ;-)
ReplyDeleteAndrew... let's flip your question around:
ReplyDelete"Why shouldn't the team improve?"... or... "why should the business invest in something that isn't going to get them any value?"
My fundamental assertion is that the team 'feeling good' about their work is secondary to results, so that argument doesn't resonate well with me.
I'm not saying that the team in this scenario shouldn't do Scrum... I am saying that the organization won't get the value from it they expect if they stop there.
Over the next few posts... I'll start talking about what you should do to compliment your Scrum adoption. Hard to get these ideas out in 500-700 words bursts.
Truths about software and development:
ReplyDelete- The customer does not care about the process or the tech, only the business value
- The "company" does not care about the process only the bottom line
Its all about delivery
- Deliver to the bottom line and keep your job next week
- Deliver to the customer and keep you job next month
I am currently working with a team that has become fixated on being agile and lost focus on delivering. Producing a stinking mess while being "agile" is still producing a stinking mess.
Its critical to remember that SCRUM is a tool to aid delivery not the deliverable
Okay, we're in agreement. Thanks for the clarification. And for being provocative.
ReplyDeleteHi Mike,
ReplyDeleteThe feeling of being let down by the company is very strong in this case. However there is still a streak of light. If the majority of the people who did perfect scrum are retained within the company, then they can turn into scrum evangelists within that company. The positive result would be that if the company has the will to continue down the scrum road, they will have passionate scrum mentors to help the non-scrum teams. The negative result might be that the people loose their faith in the magical powers of scrum in particular and join the non-supporters group for ever.
The key factor here is to keep the scrum supporters active and talking. If there is no management support for organization-wide scrum implementation, then the only hope it to at least raise the awareness. Maybe some day, the lucky news will hit the ears of the correct silo leader... I hope…
Greetings.