AGILE Project Management with Scrum -A book by Ken Schwaber

Prior to the Certified ScrumMaster seminar I attended in August 2008, I read the book by Ken Schwaber called Agile Project Management with Scrum based on a recommendation from Mishkin Berteig.    After attending the seminar and becoming certified as a ScrumMaster I re-read the book.   The second reading was much more valuable than the first for I had a much better understanding of Scrum.   Here are my comments on this book.

What have I learned?

1.    The adoption of Scrum methodology is more about changing roles and behaviours than it is about embracing a new process.

It was obvious to me and to Ken that one of the greatest challenges facing those individuals when moving from a their current environment to a scrum environment was that they would need to change their behaviours.    In the former environment the team member would be directed and inspected based on what their project manager told them to do.  The PM is the boss and the team members are somewhat powerless.  In Scrum the team members take responsibility for their commitments and communicate their accomplishments on a daily basis.  The hardest change occurs when the project manager is asked to become a ScrumMaster.  The project Manager is familiar with assigning tasks and personally inspecting results. In the scrum environment they are the servants of the team, removing obstacles and facilitating the process.   As Ken states in this book some project managers have great difficulty transitioning into the ScrumMaster role.  They are unwilling to give up the power and position as a project master.   It is hard to move from the leader of the pack to become the sheep dog herding the sheep!

2.    Scrum is unforgiving for if you do not apply the fundamental principles it is likely your efforts to adopt Scrum will fail.

As I reviewed the numerous case studies Ken chronicled is was apparent that when organizations, Team members, Product Owners and ScrumMasters followed the terms, conditions and guidelines of the Scrum methodology, they tended to deliver on their commitments.   When they misunderstood, misused or deleted some portion of the methodology they tended not to accomplish their objectives.   The methodology is well thought out and works in many situations when used appropriately.

3.    Scrum enhances individual and team expertise.

I agree and totally support Ken’s opinion about the value of Scrum.   I have no doubt the individual team member is empowered and has a greater sense of achievement.    Obviously based on his case studies, Ken builds a strong case that Scrum allows the team to deliver quicker.  The process is more change adaptive, responsive to customer needs, timely and economical than traditional methods.   Greater energy and capacity is released in the team and individual team members.

One of my favorite books is Good to Great by Jim Collins.  One of my other favorite books is Freakanomics by Steven Levitt.  This article, From Good to Great … to Below Average, takes an interesting look at what has happened to the Good to Great companies in the intervening years.  I found the comments to be particularly valuable to read.

I recently started writing a book review on Crystal Clear: A Human-Powered Methodology for Small Teams by Alistair Cockburn. Check out the first part of my review. I have read Chapter 1 entitled Explained (View from the Outside). It was a very interesting chapter that set Crystal Clear as the answerer to Alistair Cockburn. It made many aspects of the Crystal family clear in my mind. I enjoyed the questions, and the answers were insightful and helped me to put the ideas into a whole picture.

At the moment I am reading Chapter 2 entitled Applied (The Seven Properties). Frequent Delivery, Reflective Improvement, and Osmotic Communication made sense to me and aligned somewhat to my own beliefs. When I started reading the fourth property, Personal Safety, certain parts seemed fine, while others set off warning bells. I believe that the purpose of any team is to progress. This is achieved through trust, respect and unity.

Cockburn says “Once personal safety and amicability are established, a useful, playful dynamic may emerge. People may wage competition with each other. They may argue loudly, even to the verge of fighting, without taking it personally. In the case where someone does take it personally, they sort it out and set things straight again.” – page 31.

The statements above concern me. Cockburn addresses trust by saying that people will not take it personally. Respect is lost because they “… May argue loudly, even to the verge of fighting”. I would be unable to say that I respect someone if I yell at them or even raise my voice. Now unity is completely destroyed. For some reason our society and many societies around the world not only condone competition, it is seen as a way to judge attributes of excellence in an individual. This is not a good sign for our progress towards unity in human civilization.

I agree that being polite and not stating one’s opinion is harmful for trust. However, it is preferable to use consultation instead of competition. Imagine that a team is encouraged to compete with itself to achieve better results. Would there not be feelings of resentment or heightened levels of stress? Now imagine a team that is encouraged to consult and raise the team together without focusing on individual success. Would not this team feel excited to be around each other? Would they become fast friends and grow as a unit? Would family members of the team be enthusiastic to be included in picnics and socials?

Now the big question:
What is better, individual success or team unity that add value to not only the team but all who interact with them?

I will continue to read this book and post my reviews. I find it interesting that this book has helped to see the confusion that is happening all around the world in terms of progress, success, and human development.

I welcome any comments on my posts.

I have just started reading Crystal Clear: A Human-Powered Methodology for Small Teams by Alistair Cockburn. I was not too sure what this book would provide for me in the way of relevant learning.

I am intrigued that this work came out of years of experience by Alistair. This quote from the book “Crystal Clear does not aspire to be a “best” methodology; it aspires to be “sufficient,” in order that your team will shape it to itself and then actually use it.” gave me hope. I work on a small team and I wonder about which practices will best suit our situation. I also wonder how our team can use tools and processes then reflect on their usefulness to decide if we will continue their implementation.

I am interested in reading the whole book, but a little concerned that there will be too much techno-words used throughout. I have a background in business, marketing, and the web but not to the degree of the some of the other books that I have read.

What learning have you gained from working on small teams? Have any of you read this book? If so, did you gain any insights that would help my team to develop?

I have been reading a book entitled “Agile Project Management with Scrum” by Ken Schwaber. It is an interesting read. The examples and stories that he shares of companies who have struggled with Scrum and those that have succeeded are fantastic. The way Schwaber breaks up the book and explains all the roles then gives example makes it a great learning tool. It is also really funny and clever.

One complaint I have with the book is that it is very technical, it seems that the reader is assumed to have many years of software development experience. It is interesting that the projects that Schwaber discusses that have the most trouble with Scrum are those that are “stuck” in their old ways of working. It’s almost as if the old saying of “A little knowledge is a dangerous thing” is true for Scrum implementations. “Scrum means doing things in small cycles – so I will do everything the same except in shorter cycles.” Anybody ever heard of that type of reasoning?

I definitely recommend this book for those who have considerable experience in the technology field. For those who don’t this book might be challenging at times, espcially with the computer language words that are used.

I want to continually learn for my own personal and professional growth. So I  would like to know which books do you suggest? Are there any books that share examples and stories that are not focused on software development? If you disagree which my review of the book please comment.

It has been a long time since I read a book in a single day. Yesterday I started and finished reading “The Brain that Changes Itself” by Norman Doidge, MD. As an educator, father and individual interested in self improvement, I was absolutely astounded by most of what I read. As an agile methods coach, I discovered some important, directly applicable ideas. Read on for a review of this book.

Myths of the Brain

You have probably heard or read somewhere that different parts of the brain control different parts of our body. Wrong.

You have probably heard that after a serious stroke, a person is crippled for life. Wrong.

You have probably heard that mental decline in old age is inevitable. Wrong.

“The Brain that Changes Itself” provides specific compelling evidence to show that these and other beliefs about the brain are dead wrong. Our brains are remarkably flexible, malleable… plastic. This basic point of the book is shown through a multitude of compelling examples. There is the story of the woman born with half a brain who is able to function almost completely normally. There is the story of the surgeon who had a stroke that paralyzed him on one side… only to have total and complete functionality restored to that side. All of these stories are backed up with rigorous scientific investigation and a complete set of notes.

About the Book

The book itself is written in a compelling fashion. The style of writing is light and accessible, the stories are well-told, and the scientific details are present yet unobtrusive. Some of the stories are deeply moving.

On the other hand, some of the material is a bit stretched. There is a chapter on talk therapy which is over-long. There is a chapter describing some deviant behavior which children should not be exposed to and which even sensitive people would probably avoid to their benefit (Chapter 4).

The books is pure text… and it suffers from the lack of pictures or diagrams. There are numerous places where a diagram of the physical structure of the brain, or a photo of a miraculous device would really make for a stronger presentation. For example, there are numerous discussions about how our physical body is “mapped” to areas of the brain. I have seen diagrams of this mapping in other texts and they would help make the idea much more concrete.

The book itself is a good-quality hardcover. It consists of 427 pages including eleven chapters, and two appendices. The table of contents can be found below for your reference.

The books is full of stories that bring fresh optimism to my work as an agile coach. Often I encounter individuals or organizations that don’t seem to “get agile”. This book provides some interesting guidance on how to overcome these mental blocks and has resulted for me in some insights.

The first insight is just practice. Actually doing agile is probably the best way to learn it and “get it”. The trick here is to follow an exact and complete set of rules until they are perfected and only after that try variations. By perfecting the rules, we allow our brains to demonstrate that we have truly internalized (or mapped) agile methods.

The second insight is also practice… but related to time and frequency. I have long believed that shorter iterations are a more effective way of learning agile methods. Shorter iterations allow for more repetition of the basic rules and structures of agile methods, which allows for more effective internalizing of agile practices. Under the right conditions, brain maps change quickly (minutes), but in order to “stick”, the changes have to be reinforced over the course of months.

The third insight is the importance of coaching itself. In order to change brains, it is necessary to get it right. The most reliable way to get it right is to have a coach who can help a team by demonstrating, guiding and sometimes correcting.

The fourth insight is the importance of practice when I am delivering training (rather than when I am coaching a team). My courses would be much better off if they were simply packed with a mini project that was executed over multiple extremely short iterations.

The Brain That Changes Itself: Stories of Personal Triumph from the Frontiers of Brain Science (James H. Silberman Books)

Great book… hard to find! Beyond the Culture of Contest: From Adversarialism to Mutualism in an Age of Interdependence

I’ve almost finished reading The Wisdom of Teams: Creating the High-Performance Organization. I wanted to share a couple of paragraphs that give a great example of the idea of Generalizing Specialists that is such a key part of Agile Work. Here’s the passage:

The [Connectors Team] made several decisions that solidified its common team approach and sense of mutual accountability. First, it set some rules. Everyone on the team had to identify two others who could serve as backups during vacation and sick days. To eradicate the attitude of “it’s not my job” from the team, it was agreed that whenever anyone needed help, the person asked had to respond even if the activity was not in his or her area of expertise. And the team also agreed on a peer appraisal system that gave everyone the opportunity to evaluate everyone else and, through [their team leader], feed it back to the person being evaluated. Clear-cut rules of behavior like these are an important element of all successful teams.

Second, the team eliminated the two managerial positions that had retarded empowerment. This effectively modified the membership of the team because only one of the two managers whose jobs were eliminated chose to stay. The other believed he could not take a perceived demotion and left. By January 1991, however, the Connectors Team was a dramatically more effective group of people than it had been at its formation a year earlier.

Energy and enthusiasm reached higher levels as the team started pushing itself harder and in more innovative ways. One of the engineers, for example, decided to become completely qualified as a purchaser as well. Instead of being threatened, the purchasers on the team worked hard to teach her the basics of the job. The peer review approach worked so well that the team agreed on the additional – and, for many teams, difficult – step of directly providing each other feedback instead of relyinng on the team leader for this task.

There are several great points in the above story:

Backups: many agile methods do not explicity talk about this, but there is a need to make sure that the Truck Factor increases. A low truck factor can be a real problem and I strongly recommend that the Queue Master (Product Owner, Customer) in particular needs to have backup. As well, this hints at the idea that eventually the roles of Process Facilitator and Queue Master should eventually go away to be taken on by the team as a whole.

Skills: the example of the engineer learning to be a purchaser is a great example of a brave soul really taking to heart the idea of working for the good of the team by becoming a generalizing specialist. In my own coaching work, I have seen purely business-oriented Queue Masters become technical contributors to the team through a process of both deliberate and “accidental” learning. Every human being has an incredible capacity for learning. In a high-performance team, everyone takes that ability very seriously – to the point of it becoming a responsibility.

Rules: one of the simplest, yet most profound, ways that a group of people can start on the process to becoming a high-performance team is by working together to agree on some ground rules about team behavior. One team I worked with, among other rules, decided that no “stinky food” was allowed in the team room. The passage above notes the non-trivial rules. Both “trivial” and non-trivial rules are important to the team for two reasons:

1. Develop a set of expectations that individuals can hold each other to in order to avoid or deal with conflict.

2. Become aware of the team’s power to set their own working conditions, independently of management or other “leadership”.

Management: regrettably for most managers, in a high-performance team the value of formal, traditional management is much reduced. However, there is now an opportunity for two different types of work: the generalizing specialist work on the team, and the servant leader work of supporting the team. The servant leader is someone who is exceptionally good at problem solving, organizational change, and working through influence rather than authority.

As I continue my enthralled read through “The Wisdom of Teams: Creating the High-Performance Organization” I am moved to share another core concept that deserves to be considered essential for Agile Work:

The Performance Goal

This concept and practice is an essential condition for a team to become a high performance team. The Performance Goal is a specific, measurable, challenging goal that is given to and/or adopted by the team. It is a statement or description of a goal that answers “why?” and “what?” questions, but specifically avoids answering “how?”. It is not a description of activities, it is a statement of desired results. The team is left with the full authority to answer “how?” and implement it.

This concept is essential for setting the initial boundaries of self-organization. By defining “what” and “why”, the team is left free to be creative about the solution. The Performance Goal is also essential to building team accountability (as opposed to individual or externalized accountability). Every action, plan, mistake and success are oriented around the Performance Goal.

From the book:

The hunger for performance is far more important to team success than team-building exercises, special incentives, or team leaders with ideal profiles. In fact, teams often form around such challenges without any help or support from management. Conversely, potential teams without such challenges usually fail to become teams.

I would also like to point out a great blog entry I found that shows some of the other side of dealing with teams and present some cautionary words about the potential pitfalls of working in teams.

Teams as a Double-Edged Sword

However, simply delivering value at the end of each iteration is probably not going to sustain the development of a high performance team for very long. Rather, the overall objective or goal of the project has to be important and compelling. Much work these days is _not_ important and compelling. In fact, many people become cynical about work because they are stuck doing a high proportion of work that is bureaucratic or due to chaotic circumstances.

As a reminder, the books “Good to Great” and “Built to Last” both discuss the importance of challenging, important goals. The wording is different, but the concepts all map to the idea of a Performance Goal. In “Good to Great” it is the “Hedgehog Concept”. In “Built to Last” it is the “Big Hairy Audacious Goals” (no kidding!). I imagine this concept comes up in many other good books about team and organizational effectiveness. I would love suggestions on other good books to read about this! Please write them in the comments.

I’ve read a lot of books lately about agile, organizations, teams, work systems, lean, etc. This one really stands out: “The Wisdom of Teams: Creating the High-Performance Organization” by Jon R. Katzenbach and Douglas K. Smith. Right now, there is a huge discussion on the ScrumDevelopment Yahoo! group about, among other things, the importance of Self-Organizing teams in the definition of Agile/Scrum. Without doubt, this book demonstrates over and over that Self-Organization is a critical component of high performance “real” teams. I haven’t yet finished the book, but already it is proving invaluable to me as an Agile coach, inside my family, and in my understanding about how to develop my own business. The following is an extract from the book:

Teams also need to develop a common approach–that is, how they will work together to accomplish their purpose. Indeed, they should invest just as much time and effort crafting their working approach as shaping their purpose. A team’s approach must include both an economic and administrative aspect as well as a social aspect. To meet the economic and administrative challenge, every member of a team must do “equivalent” amounts of real work that goes beyond commenting, reviewing and deciding. Team members must agree on who will do particular jobs, how schedules will be set and adhered to, what skills need to be developed, how continuing membership is to be earned, and how the group will make and modify decisions, including when and how to modify its approach to getting the job done. Agreeing on the specifics of work and how it fits together to integrate individual skills and advance team performance lies at the heart of shaping a common approach. It is perhaps self-evident that a working approach that delegates all the real work to a few members (or staff outsiders) and thus relies on review and discussion meetings for the only “work together” aspects of the approach cannot sustain a real team. (p56)

The book goes on for several more pages about the “common approach” aspect of real teams. There are examples and other details which constantly resonated with my specific understanding of self-organization.