Guaranteed Success With Scrum
Written by Mike Cottmeyer Saturday, 7 May 2011 03:43
At this point in my coaching career, I’ve worked with lots of teams, in lots of companies, trying to adopt Scrum. I’ve seen teams do exceedingly well… and I’ve seen a few totally crash and burn. I want to share a few things I believe to be non-negotiable if you are going to give Scrum a try.
1. Teams – You have to have a cross functional group of people that are dedicated to burning down the backlog.
2. Backlog – We have to have an extremely clear, fine grained, prioritized list of stuff to build.
3. Cadence – There has to be some agreed upon interval against we measure progress.
4. Done – The team has to know what done looks like at the end of each interval and some way to know they got there.
For me, that’s the non-negotiable core. Just about everything else in Scrum is derived from one or more of these basic needs. For me, that means everything else is negotiable. It also means that if you can make these four things happen, you wildly increase your chances for success.
Hm, in this particular case you were not so sure about the first point: http://www.leadingagile.com/2010/03/how-to-build-a-large-agile-organization/
So, give up upon idea of Scrum in Enterprise?
Maybe number 5 (or 0?): a management which is for Scrum and supports it.
I’m all for Scrum in the Enterprise, I never implement, or advocate, anything called Enterprise Scrum. The order of the words matters, think about it
sure, management that supports Scrum would help. A product owner or a ScrumMaster might be helpful too…
but I’d suggest they are not first order needs, they are a derivative of my need for one of the first four.
What about changing the team size to get more done? Is that inherent in #3, knowing your cadence?
Mike
never mentioned Enterprise Scrum either; no idea what you are talking about…
Would be interested in getting more meaningful reply from you, though…
Denis… I think you undervalue the quality of my response
You asked if I had given up on doing Scrum in the Enterprise. My answer was ‘no’, I have not given up on doing Scrum in the Enterprise. As a matter of fact, my post was all about how to be successful doing Scrum in the Enterprise.
You also referenced my earlier blog post, which was about how to build a large scale agile organization. In that post, I make the case to create teams around the persistent objects in your organization (business capabilities), give them everything they need to be successful, then let them use Scrum, or Kanban, or whatever they want.
That post was about Enterprise Agile… not ‘Enterprise Scrum’ or ‘Scrum in the Enterprise’. A scrum team has to have everything it needs to be successful… that does not mean that in a situation where more than one Scrum team is required that every Scrum team will have everything it needs to deliver end to end business value… success will be defined differently for that team. In that case, you need an agile way to coordinate the value across teams… thus lean and Kanban.
The reason why I answered you the way I did is that there is a difference between enterprise agile, enterprise scrum, and scrum in the enterprise… the sound deceptively similar, but are really extremely different. That’s what i wanted you to think about and see if it made any difference.
Maybe you could explain to me why you think that my earlier post made you think I had given up on ‘scrum in the enterprise’. that might help me give you a better response.
Karen… curious… why would you assume that changing the team size would help you get more done. What if I have three uber programmers and add a fourth junior programmer? Do those folks go faster? What if I have a great team of 6 programmers and testers and add someone who is a real jerk? Would the presence of this person help or hurt the team? In either case, being able to increase the team size to make the team go faster (true or not) would not make the cut for my list of core requirements for successful Scrum.
In your case here. You don’t care what the person is called who fine tunes the backlog. Call it a Product Owner or a Lampshade… as long as it gets done.
Peter… yes for sure… but I’m going to explore this a bit over the next few days. Just curious to see what folks have to say about this base idea.
If you define team as “cross functional group of people that are dedicated to burning down the backlog”, may I ask how you deal with bugs: Are bugs handled by some dedicated firefighting teams (that are not dedicated to burning down the backlog)?
Michael… the backlog is inclusive of new features and bugs.
[...] Read Original Post [...]
Interesting article. I think agreed “product vision” is important to the success of team too.
From the Scrum team’s POV, I don’t care about a vision, I care about a PPBL. I’d suggest that having a vision, while important, is a derivative of the need for a prioritized backlog.
Sorry, actually that is the answer I wanted to hear, but what I was asking about the team makeup was if #3 covered the idea that you don’t play with the team members? That the team stays as a unit (without additions, changes, etc ) to be able to create a cadence, not to mention velocity.