Scrum – The Pilot
I just finished rereading Scrum: The Art of Doing Twice the Work in Half the Time, by Jeff Sutherland. When I finished, I suggested the book to both my son James and my apprentice at Sustainable Evolution, Andrew Wilt. They both LOVED it. Andrew was enthused enough to suggest we start running weekly sprints and daily standups. In the coming weeks, I will write a book review and he will add his thought in a Scrum blog piece. I’m sure we will have follow-up posts as we move forward with this pilot and adopt this approach to working together. Since Andrew lives in one state and me in another, we will have to use technology to close the gaps.
To start, here's a brief explanation of Scrum for those that are less familiar. Scrum was created to solve some of the problems we had (and have) in IT with delivering a solution that achieves the desired outcome in an acceptable amount of time. The name "scrum" comes from a rugby scrum, where two rugby teams hug each other and try to move an oblong ball down the field in one direction or another. Everyone that is needed to score points is on the field and they work well enough together that plays look like directed chaos. Scrum is applying this strategy to developing software. A team is assembled that has everyone needed to make decisions and be successful on a project. They sit in the same room and don’t spend a lot of time with upfront planning. Instead, they create a future state vision and definition for what the minimally viable product (MVP) looks like and gets started making the functions and features that are in the MVP. As they go, they learn more and make adjustments to the plan to better achieve the outcomes. There is total transparency in Scrum, so a task list is created with To Do, Doing, and Done columns. Ideally, the task list is posted on a whiteboard with the three columns, and sticky notes are created for each task that needs to be completed. The work cycle lasts for one or two weeks and this is called a sprint. The team looks at the backlog (the To Do column) and agrees on the priority of the backlog list. And then, the team figures out how many things they can get done. As team members start work on something, they move to the Doing column. As they complete it, they move it to the Done column. At the end of the sprint, the team provides a demonstration of the things that are done and anyone can attend those meetings. As teams grow experience working with each other, they are better able to understand the workflow unique to each person, which speeds up delivery on tasks. Since everyone is in the same room, if a question arises, all the team members are there to make the decision. Since the team is focused on the project they are on, there is no delay due to wait time for someone to make a decision.
Some groups will modify the overall Scrum process, but we all use some of the techniques. Here at SEI, we should become more efficient than we are now, but we will not be as efficient as we would be if we all worked in the same room and worked on one program or project at a time. Since we will be remote, we’ll use technology to replace our whiteboard with a virtual whiteboard. About five years ago I started using Trello, a free easy to use program that has all the functionality we need. We have set up our three columns and each of us will move things between columns as needed.
As each of us finish what we can do towards a task, we’ll switch ownership to another person and as the other person has time, they’ll move the task forward. As we learn what each other’s strengths and weaknesses are, we’ll put the strongest person in an area on a task they will do well, and pair them with the weakest person in that skill area so they can grow their skill.
I am looking forward to reading Andrew’s blog post on Scrum--as it will do a much better job than I did above--and hope you look at our coming book review. As we continue with our pilot, we will keep you updated on our discoveries and how we continually improve our process.