Abstract: The Digital Media division of National Public Radio (NPR) recently went through a period of growth that required scaling up its small sysadmin team to an Agile DevOps team. Initially, it was very tough for the team to let go of their old, ad hoc way of working and adopt new methods they perceived as “too formal” and “adding unnecessary process,” especially while going through institutional change and team expansion. This experience report discusses how I overcame that resistance to change within the team, why we struggled with our initial choice of the Scrum framework, why we wanted to try Kanban, and how we settled on Scrum plus Kanban as the right fit for a DevOps team working within a primarily Scrum-based division.
Lessons Learned from Your Experience:
- Here are the key takeaways I’d like to cover in my report:
- Too much change at once produced change fatigue and a resistance to new ideas or processes, so I want to share how we overcame that with baselines, clear goals, and phased approaches.
- Another key lesson was the importance of making implicit processes (the ad hoc system of emails, slack pings, “hallway conversations”, and ops cave chats that made up work intake, division of tasks and follow up before Scrum) explicit to demonstrate that establishing an Agile framework actually wasn’t more complex than their current system.
- I also want to stress the value of continuing to inspect and adapt through retrospectives and other channels, as that’s how we learned that Scrum alone wasn’t the best framework for a DevOps team, and how continued experimentation led us to Scrum plus Kanban.
- And finally, I’d like to share a brief overview we set up Scrum plus Kanban to handle our specific DevOps challenges and how it might be adapted for other teams that handle both urgent, interrupt-based work and ongoing project work.
