Scrumming from First Principles
Have you ever been to an actual sprint ceremony? Well, I have never, until last week that is. Even the actual ceremony itself is daunting — it’s driven not by a central authority figure, but at the full behest of the team. Most events are spontaneous, and self-managed. It’s absolute chaos for the uninitiated, and for those much used to command & control style meetings.
But somehow… it works. Feedback is generated, changes are incorporated, and a product is formed. It’s the dream of every high school teacher! But how?
I admit, the journey for a beginning Scrum practitioner is daunting for me even at the level of each sprint event. But I think we can make it by being open, reflective and sharing our respectively learning journeys. And most importantly, by speaking to a coach.
And that’s what I did today! Much of the content below is reproduced from what I can remember sub-verbatim from his sharing. If there’s only one thing you take away from this article, it’s to remember that successful Agile and Scrum is just like any other concept — we master it by mustering the mindset beneath, and not by muscling the activities around it.
At the heart of Agile and Scrum is a specific mindset of how improvement of a product is achieved.
It is important to recognise the context within which early Agile and Scrum practitioners operated in. For a huge part of the early community, they were software developers.
Software development is fundamentally the creation of knowledge and value through a highly conceptual process, resulting in a non-physical product. It is unlike physical manufacturing where the processes are physical and machine-driven, and the end-product is purely physical.
Therein lies the challenge — the artefacts and processes in software development are not continuously open for inspection in a transparent way. Thoughts are held in individuals’ minds until fully conceptualised in a software product. Without this ability to inspect transparently, there is no opportunity for adaptation to improve the product until the product is formed.
And by then, it’s too late. In a highly competitive environment like the tech sector, the success of innovation is highly dependent on the availability of transparency-inspect-adaptation cycles. Such cycles subject the product to rapid market and user validation, so that any deviations from what is ideal for the market can be rapidly incorporated into the product.
In short, the three principles of transparency, inspection and adaptation form the entire basis of how a software product is improved upon rapidly. And improvement leads to user satisfaction and market demand.
Scrum is a framework to realise these three principles at each level of the organisation, and at each stage of activity.
Hard to crystallise until someone talks you through it. But essentially, that’s how we should be viewing the entire Scrum framework of sprints and sprint ceremonies.
For example, at the level of task planning, we have the daily Scrum. A group of developers get together, pow-wow their progress, flag out impediments and give mutual constructive feedback. At the level of the task, this creates transparency where team members communicate their progress, opportunity for inspection when team members have the chance to give feedback, and adaptation when feedback or some change is incorporated.
The sprint planning event implements the principles at the product level. When we select items from the product backlog for inclusion into the sprint backlog, this is essentially an optimisation of the product. The entire process of creating the sprint backlog is an instance of adaptation and updating the product. The definitions of done yield transparency for the entire team. Finally, the entire product backlog is being scrutinised and dynamically refined — a perfect example of inspecting the product.
At the level of people, processes & tools, we have the Scrum Retrospective. Here, we take a step back from the product and optimise at a sub-level of the entire organisation — the team, how they’ve interacted, the tools they’ve utilised and even the organisational impediments they’ve faced. This is transparency-inspection-adaption lifted from the dimension of the product onto a dimension of the organisation.
And so Scrum events are meant to provide that heartbeat-like cadence that instils a baseline frequency implementation of the three principles.
Left to our own devices, software developers are but human. We default back to working in conceptual and physical silos, where there is no tangible artefact for inspection, much less adapt for improvements. Scrum is a framework that forces teams to put those principles into practice.
Wow, high rhetoric Yong Kiat. Time to sleep and face another day.
