Scrum is a simple, powerful framework created to manage the development of complex products. But seeing Scrum as a silver bullet is an easy trap to fall into, as this post illustrates.
Scrum is a simple, powerful framework created to manage the development of complex products. But seeing Scrum as a silver bullet is an easy trap to fall into, as the following story illustrates.
I was recently asked to help a client apply Scrum to its localisation work to make the progress of work items more transparent. The client had already used Scrum in product development for some time, and spreading it to other business areas seemed like the next logical step. To better understand the client’s context, we held a workshop and performed a value stream analysis – walking through the entire workflow from issuing a localisation request to delivering the finished piece of work. Visualising the process showed that two steps in the process caused problems including delays and defects. But unfortunately, the workshop participants were not able to back them up with empirical data.
Reflecting on the value stream map, I was not able to see how Scrum could be effectively applied to the process. There was no team and no need for close teamwork; there was no product that could be built up incrementally – requests were worked on independently and concurrently by translators in different countries; the localisation backlog was neither dynamic nor made it sense to detail its items at different levels; and work was pushed from one step to another with the project manager chasing requests and individuals.
To help the localisation team better manage their work and collect important data such as where and when impediments occur, how long it takes to complete a certain type of localisation requests, we simplified the value stream map and created a simple Kanban board captured in a Google spreadsheet. The board itself does not improve the process at all but it provides a simple high-level view of the entire process visualising the progress of individual items. We colour-coded different request types and decided to mark blocked items in red. The team now has the right tool to collect the necessary data to quantify their problems and calculate the business impact. What’s more, the board makes it easier to manage the work thereby reducing the project management overhead and encouraging collaboration.
Once the data is available, it will help promote process improvements including changing the process from push to pull and increasing the stakeholder participation. Interestingly, clarifying the ownership of localisation requests will be fundamental to making significant progress – moving from handing off requests to close collaboration. But product ownership and the role of the product owner in a lean, Kanban-based context is the topic of a future post.