Scrum in a nutshell

I wanted a way to quickly and succinctly explain what the agile framework scrum is all about, and try to put across why I’m so passionate about it.

Unfortunately I think my passion has caused it to creep slightly out of nutshell and into a chocolate covered nut selection box, but hopefully it still has some value.

What’s all this scrum nonsense?

A scrum in rugby is an ordered formation of players, used to restart play.

 

 

The scrum agile framework is also intended as a way to keep the game moving and get the ball back into play.

It’s just a different way of controlling projects, that fits particularly well for IT and development projects.

 Managing projects

In projects you usually have 3 variables, time, resource (inc money) and quality

 

 

So if resource and time is no object you can have amazing quality, or if you have a short deadline but loads of money/resource you can still have great quality.

Otherwise there needs to be a trade-off somewhere, do it quick but low quality, or get it quick by adding extra resource.

If you’ve ever worked on an IT project you’ll understand by Scrum was borne out of developer frustration at constantly being nagged at and blamed for work being delivered late, and their perceived inability to be able to commit to when new work can be scheduled for delivery.

 In reality the reason the projects usually overrun or fail is due to poorly defined requirements, lack of customer engagement, scope creep, and developers being forced to spend hours on trivial things just to get the customer to sign off.

 We should also remember that developers are also usually very bright individuals. They don’t take kindly to constantly being interrupted and bugged by Project Managers asking and moaning for things. Particularly when what they are being asked for is completely unachievable to start with, and was never actually something they agreed to.

How many times have you been given a project plan that already has a milestone dates on it before you’ve have any real involvement?

Surely it’s not possible to know when something will be finished before you’ve been asked how much work will be needed from your team or when you might be able to schedule this in?

 

So why is scrum different?

Scrum is different because

•      Fixed time and cost for projects

•      No Project Manager – therefore no micro management (Team is responsible for themselves and customer (product owner) also has responsibilities)

•      Meetings are rare and TIME BOXED! (they can’t overrun)

•      Requirements are clear and prioritised – if they’re not it’s for someone else to deal with (product owner)

•      Focus on one thing for a set period of time – (a sprint) if you’re being distracted, it’s for someone else (Scrum master) to sort out

•      People are forced to really think about what they want and why they want it

•      The whole process is visible - I’ll show the value of this later

 

Ultimately Scrum provides some certainty – we know that we are going to work on one product for a fixed length of time (a sprint) and at the end of that period, we will deliver something.

 We don’t even think about starting work until we have all the requirements laid out, and commitment that the customer will be there if we need to ask questions or demonstrate new features.

 If not everything is delivered in the first sprint, then it is either written off as no longer important, or another sprint is scheduled in the future.

 

Next section:   Focus and the minimal shippable product