Making myself redundant in 6 months with Scrum

April 2, 2009 by Peter Stevens

“My job is to make myself redundant.” That’s what I told my customer 6 months ago as we started our Scrum coaching project. The development group had been working for almost 2 years trying to develop a software package which would make the company’s very sophisticated hardware attractive to its potential customers. They were “close” to a release, but the release always seemed to recede into the distance like the horizon. Six months later, my assignment is finished: what did the team accomplish, what did it not accomplish, and did I achieve my goal of becoming redundant?

My First Day

I spent the morning with management. In the afternoon I met the development group. The team was under a lot of pressure to make a release “soon.” I realized as I looked around the meeting room, all managers (including myself) were sitting on one side of the table, the developers on the other. Hmm.

Given the pressure, I didn’t think anyone would be willing to take an hour or two for a real retrospective, so we started with a Blitz Retrospective. I asked the team to split into two groups of three, take 3 minutes, and identify the top two issues to work on to improve the development process.

First came a moment of silence, then all the managers jumped in together with their ideas. The developers and testers just remained silent. Nobody wanted to wait the three minutes -- or even use the time to think. And even though the team had been trying to do Scrum for months, self organization wasn’t happening.

This incident has become a fable I use to explain the problems of introducing Scrum. Self organization is not the norm! Management is accustomed to thinking and speaking for its workers. These habits are deeply ingrained, both among the managers and among the staff, and are not easy to change.

I reminded everyone that this was an exercise for the team (and by implication that I wasn’t interested in what management had to say on the subject!) and that they need to come up with the answer. When finally asked, the team came up with good points -- 3 flavors of communication (between developer and tester in the team, between product management and the team, and between this team and the offsite team in North America) and software quality. The team prioritized the issues, communication first, and this established the mandate for moving forward.

What did we accomplish in 6 Months?

Getting the team to solve problems as a team is perhaps the most important result of transitioning to Scrum. There are many dysfunctions of team. “I’m an XXX developer? What do I know about YYY?” “I’m a developer, why should I waste the company’s precious development resources on testing?” What impact do these attitudes have on morale and productivity in the team?

“Accomplish the sprint goal and get as many of the stories done as possible.” That is a team goal. Achieving 100% utilization of every team member (working only on tasks in their chosen specialty) is a personal goal. Which is more important?

When everyone realizes the team goals are more important and that they can and need to help each other to achieve the team goals, magic happens. Work becomes more fun, the team becomes more productive and the project makes measurable progress toward achieving its goal of releasing software.

The turning point came after about three months, just before the first release. All the functions had been developed and tested and the major bugs had been fixed. The Product Owner had exactly one issue, a performance problem, to fix before releasing and that was the only issue he prioritized for the last sprint. For the first time, the entire team worked on just that one problem. They discussed their work every day. At the end of the sprint, the performance improvement was enough that the Product Owner approved the release.

More importantly, the team realized that they could work together as a team and that it was fun to do so.

Improving on the Nokia Scale

The so called Nokia Test provides a simple Litmus test for evaluating the state of a Scrum team. If you’re team scores less than 6, it probably has serious dysfunctions that need to be corrected. 6 or 7, and the team is probably doing OK, but there are still serious impediments to productivity. An 8 means the team has established the prerequisites for achieving much higher than average productivity.

While I don’t think it’s possible or advisable to use the Nokia test to drive an improvement process, as the team gets better, the score does improve. When I started working with the team, they scored 2, maybe 1, on the 8 point Nokia scale. The team was working in iterations, but stories weren’t really being specified, and tended to explode during implementation, so whether the team qualifies for that point is dubious. The definition of done was “the product owner says ‘thank you’” and testing was manual and often caused rework.

Today, the team is challenged mostly by knowing it velocity and external influences. Protection from management is hard to achieve because it requires recognition from successful people that what they are doing is non-optimal. Knowing its velocity is related to getting things done which is in turn related to creating stories that meet the “INVEST” criteria. This is probably the hardest single aspect for the developers, because they must rethink how they develop. Score: definitely 5 maybe 6.

The Hard Challenges

Engineering skills need time to build. The discipline of Scrum demands top engineering skills. Until Scrum is being practiced, the team couldn’t recognize the need for improving their engineering skills, much less commit to improving them. Having Scrum in place makes the consequences of inadequate engineering practices visible and motivated the team to do something about it. The product owner can play an important role by insisting on a good definition of done and asking questions in the Sprint Review which confirm that the team is adhering to that definition.

Protecting the team from Management and other outside forces is perhaps the most difficult to achieve, because it is out of the control of the team. Even if management says it wants the team to do Scrum, this does not necessarily mean that they have understood and committed to the changes it means to them. And when a genuine emergency happens, it is difficult to argue that management made the wrong decision from a company perspective.

Retrospective and Improvement Potential

The high point was that the team did release its product, several times, to positive reviews from their customers and colleagues. The first release was an elephant’s birth - very difficult and we needed to do a stability release a few weeks later. This release was 4 weeks late. The third is just two weeks late. The trend is going in the right direction.

A low point was realizing that I really had achieved my goal of being redundant. The team was able to self organize, work effectively and do reasonable Scrum. I think parents must go through this when they realize that their kids are able to take care of themselves, even if they are less convinced than their kids that they can really do it. But their kids do fine (usually).

Every experience is a learning experience and next time I plan to do some things differently. I will get management more deeply committed to Scrum early on. I’ll insist on better training for the team and other stakeholders at the beginning. I’ll start raising issues the affect the next levels of management earlier. I really do want to be redundant at the end of my projects. And I am wondering, “How can I have more confidence next time that the team and the customer can continue without me?”

Permalink