Jeff Sutherland describes 3 types of scrums A, B and C in progressing levels of maturity.

Jeff didn't invent this stuff btw, Toyota and a whole bunch of really smart japanese manufacturers did.

Jeff just puts it into words and a nice little package/framework called scrum along side Ken Schwaber and Mike Beedle.

Anyhow, the three types:

Regarding Type A scrum :

Documents (artifacts sometimes they're called):

Sprint Backlog, Product Backlog, and Burn down chart.

Ceremonies: Sprint planning, scrum(standup, daily) meeting, sprint review

Roles: Product owner, Scrum master, team

Technically, if you 'have' these at all, then you're doing scrum.

However, do you have any improvements to make on them? sure, why wouldn't we :)

Over the next few days, i'm going to start going down the list more in depth and reflective over the past few years of my utilizing 'scrum' (even when sometimes i didn't know that's what it was).

I'm facing some interesting 'impediments' regarding operations with development work and it occurred to me there really is a cultural boundary to cross for large corprations as far as operations.

we have things like big monolithic change management and control.

surely there's an 'agile' way to do that

Then think about server ownership.

We share a server with 7 scrum teams for 1 single product and they ALL have administrator privelages on that... hmm do you see a problem there?

What if each team had their own development, test, qa, and production areas that they had access to and ONLY access to. Then we could get rid of all the barriers like change controls and server restrictions/permissioning.

So the standard questions are:

What did you do since last scrum meeting?

What will you do after this scrum meeting?

what is in your way?

imagine modifying those to this wording:

What did you get "DONE" since last scrum meeting?

What will you get "DONE" before next scrum meeting?

What is keeping you from getting your NEXT task "DONE" right now?

Think about it for a while, try asking it at your scrum meeting.

try asking things like "So it's really done? it's checked in? it's refactored? it's tested and passed? there's no defects? it's ready to ship?"

try asking things like "So i noticed you got nothing "DONE" yesterday, why didn't you get anything done yesterday?"

This is hard. It takes courage.

... And that is why you fail.

Mike Vizdos gives us a happy little cartoon and talk about it... go check it out, i'll wait.

I see it quite a bit.

...but we can't refactor because we don't have unit tests

...but we can't unit test without refactoring.

...but we aren't like that company.

...but we're not an engineering company.

I preach alot.

AND

I get called out on it.

AND

I guess sometimes you have to just do it for them to believe.

...think about Yoda.

So you're on a project with the standard product manager who has the 50,000 foot view but refuses to take a look at the lower level feature functionality and play that "Real product owner" role of scrum.

How do you make it clear that it is their BENEFIT to do so? Honestly, that's the question I keep asking myself because it's happening to me and I don't know how to make it visible.

So first, here's the idea behind a project burn down/up.

Your the PO and you want a widget thingy. To make the example more clear let's use a 'real' example. You want a website that allows people to post things for sale.

You mark it down as

"Website that allows people to post things for sale" aka BUC1

you also want:

"Website that allows people to use their mobile devices to save documents" aka BUC2

you also want:

"A social networking website." aka BUC3

so let's say somehow you sit down in sprint planning and you say that the sizes are this:

BUC1 : 700 hours

BUC2 : 500 hours

BUC3 : 500 hours

and you all agree to work on BUC1 in sprint 1 (just bear with me)

2 weeks in (with 5 employees at 100% committed to the sprint) is 400 hours but you are not "DONE" with BUC1.

Your burndown would look like THIS:

What? but we worked 400 hours why didn't we get any credit for that?

Because this is how earned value works. You did not get any of those items to "Done" so therefore you are 0% complete. You have absolutely NO certainty that any of those 400 hours were validated or assertable because NONE of that work met your definition of "Done" from the customer.

Now let's say you have really smart develepers and they break down things into smaller and smaller use cases (or user stories, or requirements) or whatever, but IN THE END the PO is only thinking about the high level 50,000 foot view thing.

You might get something like this

BUC1.1 100hrs, BUC1.2 100hrs, BUC1.3 100hrs, BUC1.4 100hrs

Well, NOW you're getting a little more granularity on completion but the developers are breaking these down... you now have USURPED control of the project from the Product Owner and given it to the developers... in fact they are now the 'acting product owners'. They now have the full ability to drive you over a cliff by focusing too much on technical instead of BUSINESS VALUE.

So then here's the other 'opportunity'. your product owner says "Well, i don't care about buc1.1, 1.2, 1.3... none of them give me any value at all until i have all 3 of them. Well, that's a fair statement to make, but are you sure?

Let's look at it a little bit more closely. Suppose you make BUC (business use case) 1.2 and it's the part of our auction website where people are making payments electronically. And you know that in your organization anything to do with MONEY has to go through the legal department, and they are HORRIBLY slow. Wouldn't it be WISE, even smart, maybe even MORE VALUABLE to consider THAT particular use case at a HIGHER PRIORITY?

Well, i'll let you ponder this, and if you can think of a way for me to convince my product owner to get engaged with our team, let me know :)

some other info: Obviously, it's a failing scrum master who allows teams to commit to items that are BIGGER than their sprint knowingly (like i did :) :) )

Think about these two comparisons in MS Project :)