Scrum Methodology and Approach

As part of our research experience, we read JJ Sutherland’s “SCRUM: The Art of Doing Twice the Work in Half the Time” as a way to learn more about SCRUM and the Agile process. I have long been curious to find out what is really at the heart of Agile. While I see that reading this book may be only a start, it has already been transformational for my own work, as well as a key focal point in important networking conversations.

Here are my notes and musings from my read through the book:

• The theme of basing a system off of how people actually work, rather than how they say they work (waterfall versus agile).

• I liked learning where the term SCRUM comes from– moving a ball down a rugby field– and the principles of “careful alignment, unity of purpose, and clarity of goal”

• Real progress and development happens not in a linear planned fashion, but in discovery of problems and bursts of information. Something about this helped me understand why following the scrum questions “what did you do yesterday, what will you do today, are there any impediments in your way” This question about impediments and the process of clearing blocks helps cultivate flow, creating more happiness and productivity at work.

• There’s also the question of what we prioritize- he mentions that in software, 80% of the value is in 20% of the code. What I take from this is that we have to focus on the right tasks, the most valuable ones, and then as he says later in the book we need to finish tasks to completion. So when we pick the 20% of code that will give us most of our value, to work on those features to completion.

• Then he talks about ‘complex adaptive systems’ moving from one state to another and how important it is to actually build in change, discovery, and new ideas. Building in the infrastructure for this growth allows the new pieces to be integrated in a functional way, rather than creating ‘problems’. When he said this I could see very clearly some of the flaws with the waterfall approach– as developers, we simply have so much more information by the end of a process than we do at the beginning, it’s not worth it to plan out the end of the project because we don’t know what the specifics of the tasks will look like yet so it’s a bit of a waste of time. There’s also this piece he mentions about how humans are notoriously bad at measuring the time it will take to do something.

• The story about the robots in the lab that learned to walk for the first time every time they walked was nice

• Create Plan Do Act (do lots of small experiments throughout a teams growth to find new habits, strategies, approaches, etc. that work)

• Then he goes on to talk about teams and often it is at the level of teams that greatness happens. He talks about when teams can be greater than the sum of their parts, which I have found inspiring. I wonder how conversations around best practices for teams are shifting as the people going into tech become more diverse. I imagine that there might be different needs in a homogenously identified team than in a team with a lot of diversity.

• He told the story of the scrum team manager at salesforce who said that if her scrum teams are identifying with the product they are working on then she’s happy and if they identify more with their specialty, then she knows she has more work to do with them.

• He also spent a bit of time talking about how throwing more people at a problem often makes it worse and that very large groups often do less than smaller groups because of the human brain’s limitations

• He talks about focus, and minimizing distractions because there is a cost to context switching. He also talks about minimizing ‘half-done’ things, and that the best time to solve a problem or fix a bug is right when it comes up.

• He told a story about when he was consulting and was helping this company plan for a project. They had a two foot high stack of papers that were project requirements, and no one had read the whole thing. As a team, they all went through the stack and cut out the relevant information, over half the stack of duplicated, wasted time and space was left over. He then helped them organize these requirements into tasks by asking “what has to be created?” and “How do we know when it’s done?”

The steps to practically apply scrum, as laid out in the book’s appendix:

1. Pick a product owner (this person is responsible for managing the backlog, organizing tasks into stories and epics, and prioritizing them)
2. Pick a team (best team sizes being 3-9 people)
3. Pick a scrum master (this person is responsible for making sure the scrum principles are correctly followed: running the 15 minute standups, keeping them short, running the retrospective at the end of the sprint, and then the sprint planning at the beginning as well.)
4. Create and prioritize the product backlog (listing out everything that needs to be done and identifying the tasks that have the lowest risk and the highest value)
5. refine/estimate product backlog (clarify the size of task in something other than hours, and identify the standards and tests we must meet for the task to be considered done)
6. Sprint planning: Measure the velocity of each sprint and try to increase it each sprint. Decide on a clear sprint goal for each upcoming iteration.
7. Make the work transparent and visible to everyone (such as a scrumboard with to do, doing, and done columns. I’ve tried using jira software for sprint planning before and that worked okay)
8. Ensure there is a daily 15 minute standup or scrum. Any pair problem solving can take place after the meeting rather than during it
9. Sprint review or demo to show progress. These meetings are traditionally open to anyone interested. retrospective - identify a kaizen (process improvement as well as acceptance tests)
10. Start next sprint cycle

I look forward to eventually reading this book again and developing more discernment about how to effectively apply SCRUM and Agile practices.