Scrum: The Art of Doing Twice the Work in Half the Time

I was only halfway done with the book when I committed to giving a 45-minute presentation on Scrum. My goal is to implement the process into the Aggies in Tech program so the Cohort 1 student can better manage their resources while building their apps. If that works out, it's sure to be a great blog post. The problems that Scrum claims to solve were all visible while working on my AIT app, GnoME. A retrospective article about that project's development shortcomings could also be beneficial. Anyway… enough transcribing my inner monologue, the book.

I had heard of Scrum before reading this book, as well as Agile, but I hadn’t done a whole lot of research into the two. Scrum: The Art of Doing Twice the Work in Half the Time was a great introduction to the concept. It was a bit preachy at times and gave a very one-sided argument, but the logic behind its argument seemed sound. Written by Jeff Sutherland, the creator of Scrum, and his son J.J. Sutherland, the book details the steps of Scrum, why they are important, and where they have worked in the real world.

Scrum is a rugby term that refers to the way, "the ball gets passed within the team as it moves as a unity up the field." The process was first referenced in a 1996 paper by Nonaka & Takeuchi titled The New New Product Development Game. Inspiration for this paper came from the way Japanese companies like 3M, Toyota, and Honda approach product development.

The most popular way of planning projects, since WWI, has been with Gantt charts. They follow a waterfall method which assumes a linear development of a project. The problem is that product development is never and should never be linear. There needs to be reiterations, involvement from stakeholders, alignment between a team, and a focus on creating value. Pre-Scrum product development was unable to do those things, so companies ended up missing deadlines, overspending on projects, and creating waste.

According to Toyota’s Taiichi Ohno, “Waste is a crime against society more than a business loss.” Scrum prevents waste by breaking down silos and prioritizing value creation. Silos are created in companies when titles are given out. The Head of Consumer Research may not want to collaborate with someone in software development on what should be included in a product because that’s their job and they don’t want to risk looking disposable. This is something I experience with team members and find myself guilty of all the time. It prevents value creation because not only is this hypothetical feature list going to have to be changed later, but the developers have to wait while it is being made and are unable to prepare for whatever feature list they are about to get. As soon as titles are removed and there is transparency, value can be created faster. Value is what determines what gets worked on in Scrum. Whatever is going to yield the highest value to the consumer should be completed first. While having different fonts is nice, consumers need their software to function while completing its primary purpose.

Scrum starts by breaking an Epic down into Stories. Stories are features in a project which is called an Epic.  Stories are written in the format, “As a _____, I want _____, so I can _____. For example, “As a user, I want to check my feed, so I can see what my friends are doing,” or “As a project lead, I want to show ads in users’ feed, so I can generate revenue.” Once a list of features has been created, those features are ordered in order of value and assigned a number that represents the amount of work each task is relative to other tasks. Size numbers are assigned through “Scrum poker” and use numbers in the Fibonacci sequence to make the relative difficulty of each task clear. These ordered and numbered stories are usually written on sticky notes and put in a column on a Scrum board labeled backlog. Besides the backlog column are the to-do, in-progress, and done columns. The Product Owner is the person in charge of the backlog and decides where the value lies. They are not necessarily the boss but more of a figure meant to persuade the team to follow their vision for the product. The Product Owner must know the stakeholders to know where the value is coming from.

After the Scrum board has been set up, a team will run Sprints which are usually 1–2-week periods where selected stories are set to be completed. At the beginning of a Sprint, a team will select which stories need to be completed during that Sprint that will add the most value to a project. This group exercise allows team members to help where they think they could help other team members. The selected stories are moved to the to-do column until they’re being worked on and they are moved to the in-progress column. The person who oversees how fast stories are being completed is the Scrum Master. The speed at which a team completes stories is the team's velocity. The Scrum Master’s goal is to get velocity to be as fast as possible. Daily Meetings are held during Sprints where the Scrum Master will ask three questions to gauge the performance of the team.

·         What did you do yesterday to help the team complete the Sprint?

·         What are you doing today that will help the team complete the Sprint?

·         Is there any obstacle blocking you or the team from achieving the Sprint Goal?

For a story to be complete, there needs to be a clear definition of done. Under Scrum, it is best to avoid having to come back later to polish something up. There is an observable switching cost to coming back to an old project to fix bugs. The Project Owner must communicate to the team what a story should look like when it's done.

At the end of the Sprint, there should be a finished product. Something that can be tested by stakeholders. Incremental testing by people who are going to use the product allows the team to see how their product is performing in the real world. They can then reevaluate the value of their stories and add stories to meet the needs of their stakeholders.

Within the framework, certain mentalities are necessary for its success. Sutherland discusses the importance of happiness and creating an environment devoid of cynics set in the old ineffective ways. There should not be an emphasis on the amount of time spent working, but rather the amount of work that is being completed and its quality. Time spent is not an indicator of value output. Studies have shown that quality will start to drop after an employee reaches a certain threshold.  Also essential are PDCA (Prepare, Do, Check, Act) and OODA (Observe Orient, Decide, Act). These thought processes are what Scrum is based on.

That’s essentially Scrum. It’s not very complicated. I’m still not sure how Sutherland managed to fit over 200 pages on the concept without being extremely repetitive. The book did go through a lot of real-world examples to support the practice’s validity in the real world. As I mentioned earlier, however, it was a very one-sided argument. Like how one Scrum-loving company, WIKISPEED, has only managed to produce three working engines for the cars it manufactures, and only two were produced at the time of publication. I’m eager to implement Scrum into the group projects I’m working on. I’ve thought about introducing the concept to my NSAC team or unknowingly implementing it with my Marketing Strategy team. First, I’m going to see if Cohort 1 of AIT will adopt the process after I present it next Monday. If I can refine the process over the rest of the semester, then it could become a mainstay for the way the program approaches app development. Scrum was after all made specifically for software development.