At a recent training class, one of the delegates spoke about their present company, about how it was the most “Agile” place he had ever worked. The teams at his company had well established cadences for their Scrum events; well-oiled Daily Scrums that are done within 15 minutes and result in transparency of what the team will do for the next 24-hours. They have regular Sprint Planning and Retrospective events, and hold their Sprint Reviews with business stakeholders in attendance. They are releasing software after every 2-week sprint. Why then after the first day of training with us would he comment “I realise now that we are not Agile at all!”?
Reading between the lines, I think he saw the difference between going beyond an implementation of the mechanics of Scrum and embracing the true Agile mindset. The Scrum Guide is explicit in stating that Scrum is a framework. Get the basics in place and yes, you are doing Scrum. But is having the roles, events and artifacts in place enough to make you “Agile”?
Increasing velocity is great, but pointless if the effort is not generating real value. Stakeholders attending Sprint Reviews is awesome, but a waste of time if the event does not elicit healthy feedback and result in the adaptation of the Product Backlog. Delivering frequently is a brilliant place to be, but less so if there is no validation of what was delivered, or adaptation based on the results. The list goes on of examples whereby a team or an organisation may have great mechanics of Scrum in place but have totally missed the point.
The Scrum framework is a great place to start, but it should in no way be an end destination. Scrum is an enabler for real agility to emerge through the continual inspection and adaptation opportunities that applying the framework gives us. Without the Agile mindset, Scrum just adds unnecessary overhead. Scrum Masters have a part to play here; the role is much more than ensurng the Scrum events take place for example.
By the very implication of the use of the word “framework”, Scrum is something to be built upon. It is intended to allow the addition of complementary practices. The arguments of Scrum vs Kanban / XP /
The very best teams that I’ve worked with have gone beyond – while still keeping in place – the core elements of Scrum. I’ve helped teams adopt Kanban metrics in addition to their Scrum practices to aid predictability and bring greater focus to some of the Scrum events. I’ve run workshops to teach teams how to pair program and do Test Driven Development properly (a frustration of mine is how poorly misunderstood TDD is, but that is a subject for another time).
In another example, the Scrum guide states that a potentially releasable product Increment is created during the Sprint. As tooling and practices have improved – politics and people aside – it is easier and easier to release more frequently. The Sprint is the container for all of the other Scrum events but a release is not a Scrum event. There is nothing in Scrum to constrain releasing to the end of the Sprint only – no rule stops us releasing during the Sprint. More frequent delivery and releasing multiple times per Sprint has the benefit of earlier delivery of value and faster feedback to name but two, and are at the very heart of Agile.
Returning to our class delegate, at the end of the two days of the training class, I’m proud to say that he left full of enthusiasm and ideas to take back to his team. I’ll be staying in touch, but I have a feeling they are already on a path to greater agility.