Scrum basics: The process

As the start of my new series looking at the basic elements of Scrum, it seems best to start with the end … the end goal.  The end goal of Scrum is a team which is smoothly and effectively delivering business value on a regular basis.  Some will say that this is the goal of most, if not all, methodologies, but Scrum is the most effective in achieving this goal IMO.  As a developer, it is also the methodology which I have found to be the most fun!  But more on that later.

Now Scrum is really a pretty simple process to follow and there are a number of resources around on the web which can supply details.  What I’m going to try and delve into is not only the basic rules and mechanisms of the process, but I will give you advice from my experience on the things that do and don’t work.  As with all advice YMMV.  During the series we will be straying into human psychology, communication methods, testing methodologies, user-centred design and a number of other topics that may look unconnected, at first glance.

The basic parts of scrum are:

Some specific further topics which merit some discussion are:

  • Burndown charts
  • Taskboards
  • User stories
  • Team velocity
  • Release planning
  • Continuous integration
  • Variations on the estimation process

I’ll link from here to my posts, as they’re published.

August 17 2011

Sometimes bed is not an option

 

"What passed for society was a loud, giddy whirl of thieves and pretentious hustlers, a dull sideshow full of quacks and clowns and philistines with gimp mentalities."

Hunter S Thompson - The rum diaries

How many times do you hear that to do the right thing is “Not an option” because of your client engagement.

I sometimes suspect this is much more driven by fear of the Consultants engagement than by the actual need – Sometimes being unpopular is the only option. Let me illustrate a fairly common scenario for you.

You have a piece of work where the client hasn’t actually agreed to the tech and visual design yet, this piece of work may be quite important and needs to be done very soon and as a team you might really want to get it out of the way? – The correct response is to NOT do it until we have a consensus on what the functionality should do – Hold off it – drop it – The product owner may be unhappy in the short term but then it saves you generating waste willingly. The problem is you don’t actually know what they want so are you building it because;

You are arrogant enough to think you know your product owners business better than they do?

Or because you are in the “More haste less speed” camp of “How wrong can it be?” (See above)

Now this happens all the time but let’s take this situation out of its comfortable context and put it somewhere where it really shows its flaws.

You take your car to a mechanic (You are now the Product Owner and the mechanic is the team) and the mechanic states that there is some serious damage to your engine. He will likely be able to get away with re doing the head (£x) but thinks it is wise to replace the engine (£3x)

If you have a good quality late model car maybe the engine replacement makes sense

If it’s an older car you are considering replacing in a year or two most likely the head

If it is an old banger you will probably tell him to not bother and scrap it.

How do you think you are going to feel when you decide to tell him to scrap it, call him up, and he says “We got bored waiting so we put in a new engine. You owe us £1800”

I reckon you are going to be a little less than pleased.

June 8 2010

Its Scrum (But)

 

"Call on God, but row away from the rocks"

Hunter S Thompson

So I ran a retrospective for a team a couple of weeks ago

Nothing exciting in that per se I thought but the most interesting thing happened at check in!

For those of you unfamiliar with this process it is a time at the very start where you go round the room and get everyone to say a few words. The thing they talk about is usually unimportant, what is important is that everyone speaks; it helps to engage everyone and empower them to talk further during the retrospective. So I usually ask something straight forward about the last sprint, how it made you feel etc.

Having not run a retrospective for this team before I figured I’d ask them what they hoped to gain during the retrospective and I have to confess I was surprised by some of the answers. One of the team members said “What do I hope to gain? Nothing!” which was a little disappointing but by far the most interesting was one of the tech guys. “I want to get pink cards!!” 

Now as a short explanation the pink cards are the items they keep their retrospective actions on, these go on the task board as reminders of the areas we want to improve upon. So a sensible answer you would think?

No I don’t think it is.

The telling point is he was focusing on the Artifact and not the purpose, it could just as easily be couched as “I want somewhere to park what’s going wrong so I can highlight that I have acknowledged it and no longer have to do anything about it”

Interestingly we came up with, I think, 4 pink cards? – at the next retrospective the self same team when answering “How did we perform against our last retrospective actions” are going to have to answer “We didn’t!”

 

How much business value is in your tech debit backlog??

 

"A man who procrastinates in his choosing will inevitably have his choice made for him by circumstance."

-Hunter S Thompson

So I was thinking the other day about tech debit - Where does it come from and how do we wind up with so much of it? 

so some of the scenarios that might ring (alarm?) bells are when you start finding extra details that need doing to get a piece of functionality to work and someone yells "Put it on the tech debit" or when all the Yack Shaving you are doing to get a story in is dumped on to the tech debit back log "For tracking"

Now I don't agree with this tactic and I'll tell you why - How much business functionality are you putting on a backlog that the product owner DOESNT PRIORITISE ??

Think about that for a bit while I try and disguise what I am doing enough to give you a concrete example.

Lets say you have a down stream system that is handling your orders for example - Now the guys building that system are behind you so you stub out the functionality and it looks good - What do you do with the integration piece? what does THAT user story look like?

"As a down stream system I want to communicate to a live up stream system so I can *Do some stuff*" 

OK This sounds like a tech debit story - The user doesn't really care about integration so we shouldn't bug them with it right?

Or hang on a second - What if we never did this ?? Then our down stream functionality is utterly useless - It is the proverbial lipstick on the chicken.

Suddenly it is starting to sound like our business user *Might* care about this story - But when you start saying "Upstream, Downstream, Integration etc ……… oh my god! I just bored myself!! Your product owner is unlikely to react much better. So what IS the business benefit of this piece of work.

I know! 

How about!

"As a business user I want my interface to book on to a live system so I DONT LOOK LIKE AN ASS WHEN I BOOK Y AND NOTHING HAPPENS !!!!!"

You may want to taylor the "so that" clause a little but the sentiment is there - The business value of the application *Actually doing something* is, I think, pretty clear. So I suggest the following - When you are next confronted with a bunch of tech debit stories that you are trying to shoe horn into a sprint around the eye candy your product owner is busily trying to prioritise (Ohh shiny!!) maybe see what the actual user story is? Start by thinking "if I never did this what would the end user experience? and would that experience result in no change to me or my p45 on my desk tomorrow?"&n

If the answer is the P45 better re couch it in terms your product owner understands 

Nobody likes to see another unemployed IT professional :-) 

 

 

May 13 2010
Newer Posts Older Posts