Recently I had an opportunity to participate in a two-day training program on Scrum. Scrum is a flavor of Agile project management allowing mixed teams to scope, prioritize, build, and launch products during two-week ‘sprint’ cycles. The teams are generally cross-functional, comprised of experts with specific skill sets needed to accomplish the specific goals.
We practice Scrum at NPR so when the opportunity to join this training came up, I was keen to participate and see how I might incorporate these principles to my workflow. Here’s what I learned.
Principals of Agile
Scrum is a framework rooted in Agile development, which is based on the principles of the Agile Manifesto (below).
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions OVER processes and tools
- Working software OVER comprehensive documentation
- Customer collaboration OVER contract negotiation
- Responding to change OVER following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Many of these values can be applied to areas outside of software development. ‘People over process’ and flexibility (adapt as you discover, re-calibrate as you learn) stand out as key components to many organizational strategies.
Scrum Training Exercise
Our trainer, Jim York from FoxHedge Ltd, has been working with NPR for years. His teaching method applies a variety of case studies, interactive exercises, and actual group work with ‘mini-sprints’ designed to simulate a full sprint cycle.
The attendees represented various levels of experience with Scrum – from complete newbies (me) to experienced developers who were stepping away from current sprints to attend.
I was fortunate to work on a team with most technical colleagues who shared my curiosity about applying Scrum to recruiting. Together we worked on ‘Project Moneyball’, a multi-pronged approach at identifying and engaging talent. The program is still in development, but it was a great introduction to Scrum and did lead to the development of what may be the first paper-responsive prototype (above).
Below is a summary of how I feel the components of Scrum can be implemented into non-technical teams.
- Scrum Board: I was already a whiteboard nerd, but having all of my projects arranged by ‘To Do/Ideas’, ‘In Progress’, and ‘Complete’ is a great way to stay organized when you’re managing multiple projects concurrently.
- User Stories: User stories are a reminder of what drives your projects – covering the who/what/why that helps you prioritize.
- Note Cards: I used to list my projects out on a white board. Note cards provide more flexibility and allow you to easily shuffle projects based on shifting organizational priorities.
- Alignment: I assigned numbers to each user story, then tagged each project with the user story they support. This helps me better visualize project alignment and co-dependencies.
- Time Boxes: Hard start, hard stop – period.
- Sprints: Scrum teams typically work together for two-week cycles called sprints. These are cross-functional teams as outlined in the opening paragraph, where all member’s sole focus for those two weeks is the agreed upon product releases. This doesn’t really convey to many non-technical teams, as our day-to-day is a mix of ongoing responsibilities and reacting to situations that come up in real-time.
- Scrum Meetings: I love the idea of daily huddles for all team members to discuss what they accomplished yesterday, what they’ll work on today, and any impediments they’ve encountered. It’s great for transparency, accountability, and collaboration. Given the lack of committed all-in team collaboration in most non-technical initiatives, a traditional daily stand up may not add value. I’m actually a bit torn on this one, as I think the more a team is dialed in on what everyone’s working on the better, but I also think its important to minimize meetings.
- Points: In Scrum, you assign points to each item in your product backlog (i.e. ‘to-do list’). You then calculate and tracks points and time to measure things like velocity and burndown. I didn’t feel this applied to my interpretation of the Agile framework as it wasn’t a true sprint, though I created an ‘alignment’ variation (detailed above) that illustrates project weight.
That’s my initial take on how non-technical teams can implement Scrum. More of a project management tool than a full-on process commitment.
Have you incorporated any aspects of Scrum, Agile, Lean, etc in your non-technical workflow? If so, please share what’s worked for you and what you’ve learned in the comments.