Scrum

16 Dec 2020 at 19:44 // under Productivity

After my recent post about moving beyond personal productivity, I picked up Scrum by Dr Jeff Sutherland. Scrum is a way of team working that is very different from waterfall, the way most companies traditionally work.

In a waterfall company, plans are made by the higher paid helpers. Before any project is started, it is fully planned out, with specifications and Gantt Charts. Projects move from team to team, often passing gatekeepers at multiple stages. The teams are usually organised by discipline, and they are expected to simply implement the requirements that was passed to them.

The problem with waterfall and all these plans it that they are often fantasy. As soon as the ink has dried, the plan is out of date. Some things that seemed easy to implement turn out to be difficult or impossible. Extra requirements get added. Others are often not really required, but because they are in the spec and the plan, they must be followed. Any change just adds to the cost and the time for the project.

Scrum attempts to get around some of these problems by avoiding creating big detailed plans. Instead, teams work in short cycles, adding a feature or bit of work at a time. At the end of each period or "sprint" as they are known, the team seeks feedback from the end users, before deciding what to work on next. This way changes to requirements are easy to make before you spend too long working down a blind alley.

The team must be a multi-disciplinary team, with the authority to actually make the decisions and complete the work. Teams should be between 5 and 9 people in size. Any larger, and it becomes too difficult to keep everyone in sync and understanding what the rest of the team is working on.

My thoughts and concerns

My main thought with Scrum is that most of the names are stupid. The name scrum itself is supposed to refer to rugby and that the team “tries to go the distance as a unit, passing the ball back and forth”. Except that ‘scrum’ is a very specific part of rugby when there is a knock-on. Eight bodies from each time boned up and shove each other as much as possible not really getting anywhere while the ball is thrown in the middle, and they try to kick it back to their own team. I am not sure that is what the software guys were thinking of when they started to use it.

On top of that you have your "Scum Master" a sort of authority-less leader who is supposed to improve the way the team works together, and a "Product Owner" another authority-less member who is supposed to guide the team about what they should be working on next. I am not sure what the actual team manager is supposed to be doing.

I have got a few concerns about the process, though I suspect most of these come from not understanding how it actually works in practice.

My first concern is how you help junior members to develop. Normally if you are working in teams of your own discipline, you can learn from others, ask for feedback or help as you become more competent. I am not sure how you help a junior engineer develop if they are working in a team of engineers from a different speciality.

Scrum also mostly focuses on an individual team with a single product or goal. The size of a team is limited to 9 people, so I am not sure how you work when jobs require many more people. I assume you work is separate teams, but it wasn’t explained how these teams coordinate well together without getting bogged down in long meetings and requirement documents.

There are a few other concerns I have as well, but as I said earlier, I suspect most of these come from not understanding the process. The book definetly focused more on the background of where Scum came from and why it was developed. It don't cover the nuts and bolts in much detail or how things may need to be tweeked to work better. I will definitely be doing more reading on this in the future.

Go Top