My first introduction to agile software methodologies came several years ago when I stumbled on Kent Beck’s book “Extreme Programming Explained: Embrace Change”. I remember that some of my first thoughts were that the current approach to creating software was not working and a radical change just might be the answer.
Finding that book started a journey for me. The journey continues today – it is to find better ways to create software and to improve the way in which teams work. There are several flavors of agile in use today but Scrum is one of the most well known and accepted.
I stumbled on this book while browsing around Amazon a while back and finally decided to buy it. The author, Jeff Sutherland, is the co-creator of scrum. I decided that the insights he might provide would be very interesting. At about 250 pages it is a pretty short book and a quick read.
The book really focuses on the “why” of Scrum. There are three key things I got from the book:
1) There are some descriptions of projects that have successfully been coached in Scrum and had extraordinary outcomes. The author shares experiences he has had in turning projects around It is interesting to understand the history and evolution of Scrum.
2) Understanding of the roles and processes and “keys” to successful Scrum.
3) The use of Scrum in non software work.
Here are my more detailed thoughts on these points:
Evolution and Success Stories of Scrum
I found it very interesting that the author had been a pilot for the US Air Force in Vietnam. He related that his Air Force training had taught him to do four things to control risk. The acronym is OODA: Observe; Orient; Decide; Act. As soon as these steps were complete the pattern would need to start again, observing the new reality, orienting to the new possibilities, deciding on the best course of action and executing those decisions.
He relates stories of several projects that he was a part of or that he was brought in to help with. The story of the birth of Scrum is recounted in his work at Easel where his team transformed the way they worked which helped them to deliver their product on the assigned 6 month schedule, under budget and with a lower rate of bugs than the team had previously been able to achieve.
The second story that really struck me was the salvaging of project “Sentinel” for the United States Federal Bureau of Investigation (FBI). While there are challenges with any project, especially large ones, this had the added headaches of being a government project. It had technical challenges to be sure, but it also had to deal with a wide array of stakeholders. And while it might just be the cynic in me I believe that not all of the stakeholders were as focused on the potential results of the project as they should have been, but possibly more interested in how they could leverage their involvement into political clout or gain. After years of work, and the expenditure of most of the budget, an assessment was done that estimated it would take another 6 to 8 years and another $350 million to finish the project. The net result of switching the approach of driving the project to Scrum was finishing the delivery of the project with a smaller team, for a small percent of the original budget and delivering it in 20 months. When you see those results, especially in what could be considered a difficult environment, it is worth looking into. To get a more of the details of the FBI project drop by a bookstore and browse through chapter 1 of the book.
Keys to Successful Scrum
My thoughts about the keys to successful Scrum are influenced by several factors including my experiences, my recent training to become a Certified Scrum Master (CSM) and things I’ve read. This book included many points that validate what I have learned and experienced in the past as well as giving some new insights.
The key that continues to stand out for me is trust. I do not believe that success is achievable without trust between all people involved in Scrum.
The team members need to trust each other. I have typically found this to not be too big of a problem – but if you see it you must attack it quickly and come to a resolution. This supports another key point of having self-directing teams. When teams trust each other they are better able to take on and support others in their tasks. It is also somewhat cyclical, when you trust people tend to perform which leads to even greater trust.
I have worked in consulting for several years, and it is something that I really enjoy. Unfortunately I have seen a lot of mistrust between the client and the consultant. And this often goes both ways. I believe that it is difficult to establish this trust, but when you can, and each party performs it becomes cyclical just like it does in the Scrum team.
I find that often trust issues result from a failure to see things through the eyes of others. The author brings up the point that it is natural for us to see our actions as being driven by circumstances and others actions being driven by character. When we make “poor” choices we rationalize it as responding to the current environment. But when we see others make what we consider “poor” choices we attribute it to a lack of character. These attitudes kill trust!
Then next couple of keys I identified from the book were again a validation of my previous thinking and experience – but they were enhanced by the language and the examples in the book.
The core key here is that people must be dedicated to the project – not in the sense of their attitude to the work, but rather in their work assignments. We act today as if multitasking is a good thing. We often pride ourselves on our ability to juggle multiple tasks and priorities. Research has shown that is a productive way to work. One of my favorite time management techniques is the Pomodoro Technique. The key to that is to focus on only the most important thing for 25 minutes, then to break for 5.
In Chapter 5 a study is presented that shows that multitasking is not only a drain on productivity, but it also makes you stupid. If you believe that study, and you want a productive, and smart, team working on the project you can see the point of focused assignments of projects. The other point backing up this key is actually the title of Chapter 5 – “Waste is a Crime” – let that one sink in and read the chapter for the authors thoughts!
The author also talks about the team size having a major impact on the success of Scrum. There are different thoughts and “rules” about this in the industry but he recommends that a team should be 7 people (plus or minus 2). Most of the projects I have worked on have been made up of many teams, and the typical team size is larger than that. Because of this I can’t really confirm this point, but I know (from experience) that multiple teams and large teams do create many challenges!
The next thought is that a happy person is a more successful and productive person. It seems that most of our reward systems today are based on the completion of achievements. There is a lot of research that tells us that those rewards (carrot/stick mentality) are actually harmful to attitudes and success. I’ve recently read another book that focuses on that directly (Drive: The Surprising Truth About What Motivates us – by Daniel H. Pink).
We need to keep ourselves and our teams happy and enjoying the day to day work of the project. What motivates most people is not the end of the journey, but the journey itself (I recently tweeted this: It is said that happiness is not found at a destination but rather from the journey. Are you on a journey of happiness?). I believe that – but it can be difficult to remember that in the daily battles that we find ourselves.
For those that have not worked in a well functioning Scrum world you will find that it is a real change of culture. It is much more that just learning and following some techniques and ceremonies, it really does require a change in your thought process, your interaction with others and the way that you work. Really a change in attitudes and focus!
Non Software Work with Scrum
The final point that really struck me from reading this book is the areas in which Scrum is being used. Scrum was developed in a software/technology focused environment. I have always worked in the same type of environment so naturally that is how I have seen the world, and how I have seen Scrum.
I found it very interesting that Scrum is driving cultural changes in many non-technical businesses. This includes education, journalism, manufacturing, volunteer humanitarian efforts and even government to name just a few.
If you are interested in how Scrum is changing the non-software world be sure to read Chapter 9!
What have you read?
What books have you read on agile methodologies that you would like to discuss or recommend? My reading list is long, but I’m always looking to add good books to it!
