Recent years have seen an explosion of orgnisations adopting agile processes or claiming to do so. This has led to an explosion of organisations claiming to assist in the adoption of these processes and managing the change process.
Along the way many who quote the agile manifesto as a mantra have managed to lose sight of the principles behind it. And suddenly agile has evolved into a methodolgy all of its own with organisations defining processes, attempting to standardise these and rigorously policing them. Recently I overheard a Scrum coach announce I'm sorry, but as a Scrum coach I cannot allow you to sit in the daily meeting.
So why Scrum?
Scrum is an incredibly simple framework that is easy to adopt. Ok its not that easy because an organisation won't magically become agile because the development team decides to adopt Scrum (but that is a different conversation). It is also the most popular of the agile frameworks for very good reason. It works. If you are looking to make improvements to your product development process Scrum is an excellent place to start, whether you are a new team or an established team wanting to make improvements. Note I haven't actually mentioned software development. It is very relevant for software products but also for other types of products. If you are looking to make improvements to your product development process Scrum will help. Period.
Back to those principles!
I'm going to focus on just two of them (you know where to find the rest)
Simplicity--the art of maximizing the amount of work not done--is essential.
Does this mean we only develop the features we actually need?
Does this mean we don't do unneccessary work on features that will never be implemented?
OR does it apply to everything we do?
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This is more clear cut. It's clearly about the way we do things. In Scrum we use the phase Inspect and Adapt.
How does this work in real life?
Some time ago I worked with a mature team that had become very effective at creating requirements. Over time they learnt that small stories are better than large ones and their stories tended to be in a narrow size range - say 3, 5 and 8. The Product Owner was part of this team so there was no customer / supplier relationship or point gaming. One day in a retrospective one of the team members innocently asked why do we bother with planning poker? The rest of us realised this wasn't a lack of knowlege question and the Scrum Master and Product Owner agreed to assess the usefulness of planning poker (in the context of this team).
The team had been together on the same project for several months so they had real data to assess. The SM and PO looked at the velocity trend and completion forecasts based on the current backlog. As a starting point they changed the estimates for each of the remaining stories to 5 (the middle value). They discovered that the forecasted completion date was almost identical (less than 1% variance). Hmmm - so why do we bother with planning poker?
The Scrum Master, a keep it simple person, proposed they stop counting points and simply count stories. The Product Owner, a more analytic person, countered that this may be a mistake because there was no guarantee that the team would continue to produce stories within the same range and they needed to monitor variances in case a future course change was required. No need for extensive debate, they agreed that all future stories were automatically 5 points, stopped planning poker and continued to monitor the team velocity for variance.
Some would argue that this was unacceptable because it deviated from the process. In terms of the principles behind the agile manifesto it was absolutely the right thing for this team to do. What was the outcome? The team's average velocity improved by around 3%. This may not seem like a huge result but it did correlate. The team had been spending an average of 3% of their time on planning poker. Since it was already a high performing team that decision proved to be a quick win to achieve an even higher level of performance.
In reaching this decision the team applied both principles, they modified their behaviour by inspecting and adapting. They also increased the amount of work not done. This didn't start working any less less, they eliminated needless work that had become part of the routine tand no longer added any value.
Scrum remains a valuable framework and a highly recommended one. But we do need to think carefully before blindly enforcing practices, artefacts and ceremonies because the book tells us to do so. The framework is based on sound principles which are shared between many lean and agile frameworks as well as traditional methodologies. It may turn out that the team outgrows other Scrum practices in their quest for continued improvements and end up as an incredibly efficient team that no longer uses the Scrum framework. This does not reflect a shortcoming of Scrum, instead it reflects a team that had successfully accepted the challenge of continuous improvement.
It would have been a mistake for this organisation to rewrite its process manual to remove planning poker based on these results. Just because this team had reached this level did not mean that the same applied to the rest of the teams. If you are really concerned about maximising the performance of every team you won't be looking to standardise the way that improvement is achieved.