Scrum for Managers

I had lunch with my old general manager and friend at Microsoft recently. He told me he is building a new agile and wanted to know if I knew of any developers that would meet my criteria that were looking (I have a high bar). I said I knew of a few and asked him how his current people are responding to him looking for more agile focused people – specifically what he is doing with his “lead developers” – the people that are one level up from individual contributor and typically have three to five direct reports.

“I set them straight by saying I hire leaders not managers and I expect leaders to lead and do work” he said. We continued our conversation and where the issue lied was that there was a sense of superiority with a couple of the leads – a sense that their job was now to manage people, to direct them, manage their time and monitor their progress as it pertains to development tasks. This was the complete opposite of what my friend was looking for and these development leads were having a hard time doing actual work.

This then takes us to Scrum – what is the role of a manager is Scrum? My last eighteen months at Microsoft were spent helping teams get started with agile principles and Scrum and XP practices. Through this and working with companies since leaving Microsoft in late 2006, I have come to notice management behaviors that are absent in the teams that fail and present in the teams that succeed. Let’s look at them now.

A Common Set of Principles:

First, the managers that had the successful teams clearly understood the agile principles and values and were able to distill these values to their people. People were aligned and understood why they were working the way they were and they understood the vision and goal of the entire organization. The why is extremely important because without the why, all that is left is the how and the how can be quite confusing without knowing why you’re doing it. The vision and goal is equally important as it creates a rallying cry, giving people the knowledge needed to do the right thing and to solve problems without asking higher power to make the decision for them.

Multitasking

The next thing I observed is that teams were able to stay focused. As I investigated, I found teams that were working on one project and one project only – full time – all day long. The teams that failed were always working on multiple projects splitting their time. This was fascinating. The teams that were dedicated to one project were able to not only deliver faster due ot the elimination of switching costs but were also significantly happier. Further, due to having a common set of principles and values to work from, these teams were able stay extremely focused and deliver systems that always delighted the end users. The teams that were multitasking across projects often lacked the vision needed to delight the end users and, as a result, more projects were needed to fix that problem, creating a never ending cycle.

Rewards for Failing Early

Performance reviews are all about how a person does against a set of goals or commitments. When people fail to meet their goals, they are often penalized. If people accomplish their goals as expected, they are rewarded and if they take a risk and succeed, they are rewarded greatly. The problem is when people take a risk and fail. When this occurs, they are often penalized with no reward and a perception that they are failures, at least in the short term. As a result, people seek work that is in their comfort zone because it is the safe bet for success. This behavior limits growth opportunity and creates a company based on strict functional roles, not cross functional teams.

Failing Early

How I have seen managers get around this is by rewarding for failure, but only if it happens early. Failing late is not acceptable. In this model, people that stayed in their comfort zone received a minimal reward – say a base cost of living increase. People that took risks and failed were given the average reward and people that took risks and succeed were given a high reward. The difference here is the shift from staying in the comfort zone. This builds complacency and does not create a learning organization, neither does negative reward for failure. This model allows people to learn from their mistakes early, when the impacts are low.

The other thing that this shift does is drive innovation. When people are taking risks, they are learning and when they are learning they are often innovating. Everyone in software wants innovation and creativity, and the enlightened manager will realize this and shift the reward structure to enable it.

Protection and Transparency

Too often I have seen people get filleted by customers or senior managers while their own managers stood by and let it happen. This spineless behavior drove teams into their comfort zone. However, for the managers with a good understanding of why (going back to the values and principles), they understood that this was unacceptable behavior and would not only defend the teams but would often shield them entirely, allowing them to stay focused on innovation and delivery while they played the political games that plague our companies.

Providing this protection was dependent on transparency. The teams who were open, honest and truthful about their projects gave their managers the ability to provide the protection they required. The teams accomplished this by having daily reports (burndowns), regularly scheduled demos at the end of each sprint with everyone invited and a common definition of done so that there was no question at the end of the sprint or a release if the teams were “really” done. What was most important, however, is that the teams highlighted both their success and their failures. This builds trust among management and the customers.

Accepting Transition Costs

We have all learned how to ride a bicycle, yet when we first started we were not that good. Our parents did not yell at us and tell us we were worthless, instead they guided and coached us until we were able to understand the basics of balance and motion on our own so we could learn and grow our skills.

Too often I encounter managers who have read about Scrum, often hearing about teams and companies that were able to achieve greater results, higher quality and be faster to market while spending less. They then believe that if they implement Scrum that the benefits that may come with it will be theirs. All they need to do is get buy some books, get people trained and voila! the cure to all their problems!

Unfortunately, like learning to ride a bicycle, adopting and doing Scrum takes time. Doing it overnight is not acceptable and will cause more problems than it solves.

In my observation, most (e.g. 80%) teams can be off the training wheels in three months and can be an entry level racer at six months. After a year they may be achieving output that is five to ten times greater than their original output.

In Closing

It is the managers job to allow the team to learn and grow on its way to greatness. First is to understand that this curve exists in life and next is to understand the items written above. Failing to do so will likely result in a bad Scrum implementation and will all but certainly guarantee failure.