For someone who regularly criticises classroom training imagine my surprise to find myself in an agile project management course run by @agiledave of @agil8. To be more specific this was a SCRUM course, a particular breed of project management (PM) which some of our suppliers are currently using. I wanted a certificate and often it reassures people if you have a shiny sticker. Perhaps I’m pandering to the system that I spend so much time decrying, but as Snoop Dogg probably said, “don’t hate the player hate the game”.
I thought I’d see if I could condense two days in the classroom to circa 1000 words of text and also share how I think you could apply SCRUM in your work. Here it goes!
What is SCRUM?
Transparency, Inspection and Adaptation. For me this makes total sense and aligns very closely with how I try to operate in work; be open and collaborative, look at yourself and ask for feedback, be agile and work around barriers. In practice we are talking about a way of “reflecting regularly, to tune and adjust to become more effective” To paraphrase @shackletonjones; bad processes make good people do bad things, so it stands to reason that good processes can make good people even better and bad people half-decent.
What’s the alternative?
The idea of what is termed “waterfall” project management is that you outline your requirements, and then complete all the necessary tasks in sequence. This process is tracked in a Gantt chart; coined by Henry Gantt between 1910-15. The problem of course, is that doesn’t work for 95% of all projects because by the time a project is nearing completion, the requirements have changed, and/or the whole environment has. In the 1910s they were still calling computers “tabulating machines” and I don’t think it makes sense to use a PM method developed before computers became “computers”
Waterfall is great for very short-term projects that need to be delivered quickly. Rubbish for anything else.
Cool stuff you can use from SCRUM
Here are 6 ideas you might like to try in your projects.
- 15mins Stand-up
The clue is in the title really. This meeting is held with the whole project team and facilitated by the “SCRUM Master”. It lasts a maximum of 15mins and there are 3 questions which each person in the team covers.
What did you do since we last met?
What are you going to do next?
What are your barriers?
2. The whole project team are part of the same team
Typically a SCRUM team is a maximum of 9 people which includes a Product Owner and a SCRUM facilitator. The team includes everyone needed to get the job done. Forget having to navigate the silos and corporate red tape; waiting for 2 weeks to get a response from IT. In SCRUM the approach is that everyone knows everything and are clear on their roles.
3. Working in “Sprints”
A sprint is usually between 1 week and 1 month and is the core of the SCRUM process. The idea here is to end up with something you can test at the end of each sprint. This way of working means you can keep very close to your audience and stakeholder requirements. It’s a process which creates a constant feedback loop for the team allowing for continuous course correction.
4. Relative Estimating
We’ve all been in meetings where stakeholders are demanding to know exactly how much something will cost, and how long it will take to make. The problem we have as human-beings is that we are terrible at estimating things. SCRUM’s process is to assign tasks a number based on difficulty, and then to compare tasks to each other. For example, writing this blog might be an 8, whereas turning on my laptop might be a 2. You will have realised that these numbers are pretty much meaningless, and you’d be right. The aim is to work out how many tasks you can complete in a sprint which gives you an accurate view of the project completion or product launch. At the start of each sprint you estimate the number of tasks you’ll be able to mark as “done”, and at the end you count up the numbers which is your project “velocity”. If you know your velocity is 80, you will be able to make a pretty good call on how many sprints it will take to get to the end of the project.
5. The contingency is built into the Scope of the project
Rather than trying to hit impossible deadlines and trying to do everything by x date, you can ensure the project team is successful by expanding or contracting the project Scope. In SCRUM the team’s target should be around 60% of the project requirements, this leaves a decent amount of contingency for resolving inevitable issues.
Guess what, people tend to ignore lessons-learned reports! Dave Hicks also said that in the SCRUM teams he’s seen, it’s the Reflection pillar that this most susceptible to being undermined. SCRUM builds feedback into the end of every sprint both from a team and a audience perspective. The cool part is how the team’s feedback is implemented:
- Step one is that people note their ideas on post-its
- The duplicate ideas are grouped
- The team votes on the ideas, the number of votes each person gets is the number of ideas, divided by 3, add 1. You can weight your votes if you think an idea is especially valuable.
- Lastly, the team discusses how the top 3 ideas can be implemented.
I like this because it’s not asking the team to do everything. It offers a manageable number of changes and as people have voted on the ideas, they feel a sense of ownership of them.
And that’s it. 2 days condensed into 1010 words. I hope it’s useful inspiration! For more information on SCRUM, check out https://www.scrumalliance.org.