As the 20th
anniversary of Scrum approaches, I’m struck by how the idea has spread. Tens of thousands of people are certified in Scrum. Thousands of companies across the globe use Scrum. The US Department of Defense has a mandate
to be Agile. Gartner Group
says that waterfall is dead. What’s next?
The future is Scrum outside of IT. Recently, we’ve mentioned initiatives like eduScrum
bringing Scrum to the classroom by motivating students, encouraging self-organization around learning objectives, and teaching them to work as a team. Scrum is also moving beyond IT in increasing numbers of companies.
Historically, development was always “the problem”: running late, over budget and releasing too many bugs. Now that development is not always the problem, we see other departments wondering, “Why can’t we use that Scrum thing?” Recently I saw a great example of this while visiting a client.
In this company as in so many others, software was never on time. Despite many Gantt charts, nobody really knew when the product was going to be done. Top management was not happy. It was painful. Then, two and a half years ago, some of their people in Europe heard about Scrum, and managers across the globe were gathering to figure out how to pilot Scrum. Slowly and steadily, Scrum teams were formed. Some doubled velocity, but Scrum wasn’t a silver bullet. The development teams faced impediments around dependencies on non-Scrum departments in the production chain. Soon the “ripples” of Scrum began to gain momentum.
The first ripple hit Production, as teams needed new equipment to test the code sooner. Production became involved and shortened their turnaround time on test equipment from 2 months to 2 weeks, and developers could uncover bugs during the Sprint. Another ripple hit Mechanical Engineering when problems with the equipment quality were found during testing. Mechanical staff received immediate feedback about problems, and worked with Reliability on a fix. Hence, the “Technical Scrum of Scrums” was formed to bring all these departments together in a more formalized way.
Today, the Technical Scrum of Scrums meets every day after the development teams’ standup meetings. Representatives of the teams (pigs) meet with the chickens, managers from Electrical Engineering, Mechanical Engineering, Quality, and Reliability. Some of these other departments have started incorporating a daily status meeting in front of a Kanban board into their daily cadence.
As Scrum teams succeed in solving difficult IT issues, we see many instances of this kind of inter-department collaboration. It fosters a sense of common purpose in building a product, creates a more common goal, and breaks down barriers of us versus them. This is the future of Scrum.