Successful leadership with Scrum: a case study
by Walter Bachl and Thomas Spielhofer. In this text you find: what are the success factors in introducing Scrum from a leadership perspective based on a case study
During a management workshop we came to the conclusion that we needed a new product, and thus we launched a new project. This project was critical for the company because it was the basis for a strategic reorientation of the company. The new product had the following characteristics:
- Use of new technology: there was no experience within the team and since it dealt with cutting edge technology, there was limited possibility to bring in help from outside.
- Extremely tight time frame: within 4 to 5 months the system had to be ready for the start of sales and marketing.
- Unclear scope: the scope was only defined on a very high level. To put it in Scrum terminology: the vision was clear, but we had nothing more than that. There was no chance of getting a more detailed scope at an early phase of the project.
We had two managers who could work on the project: Walter, who had been with the company for some years, but was not familiar with Scrum, and Thomas, who had already introduced Scrum, but was new to the company.
The decision process within management
The company was used to working with a waterfall approach with several releases per year. Thus we tried to approach the project the traditional way even though the necessary information for a project plan à la waterfall was missing at the project start. This turned out to be hopeless – a situation that led Thomas to the suggestion of trying Scrum. We had many in depth discussions about the pros and cons in our so-called “Reflektionsleberkäs” (a “Leberkäs” is a Bavarian type of meat loaf popular in Germany and Austria. One usually eats it warm in a roll: a “Leberkässemmel”). We used the time we needed to buy and eat the Leberkässemmel for our discussions with the result that the project should be conducted with Scrum.
The next step was to convince the remaining management peers to use Scrum. They had no special role in software development but led departments with high dependency on the result of the project. After that we had to convince the board of directors. It was relatively easy when it came to our management peers, since we included them very early on in our discussions concerning the methodology. The board of directors represented a challenge. To convince people to switch to Scrum you need deep knowledge about what it entails. Therefore an attempt by Walter to convince the chief technology officer failed, yet a second attempt by Thomas and Walter together proved successful. At a later stage also the chief executive officer had to be convinced, but by that time Walter was able to present the advantages of Scrum to a better degree and was therefore able to win him over. We thus started off with a good alignment within the management. We kept up regular briefings and discussions within management throughout the project to ensure it stayed that way.
Subjective view Walter
It was obvious that the project would end in failure, if it were conducted with the established engineering methods of our company. It would take too long to reach the necessary status of fine granular and comprehensive requirements. Additionally, there was a high probability of necessary changes arising after the first implementation steps. I had read about Scrum earlier and knew one thing about it: developers tend to have romantic ideas about Scrum (at least the developers I know) – something along the lines of ‘throw away some rules, do not specify and produce new releases in short periods’. No thinking about what has to be introduced instead. Thus I thought about how to rescue the project but did not think about Scrum. In Thomas we had a new colleague in our management team, who had already introduced Scrum at another company and he proposed this method. Within seconds I knew that this was the solution. It was the right method for the project and since he had Scrum experience, he was credible should we insist on actions to make Scrum successful. I also had the necessary trust in Thomas, which could and would help with the introduction of the methodology. Nevertheless we held numerous helpful and necessary discussions about the methodology, which helped me to build up the required confidence about the decision. It was very challenging to convince people to use a methodology you do not know very well and that you had never used before. But I had to deal with some very good and challenging questions and thus learned a lot about my knowledge about Scrum. I had to think about some aspects that I hadn’t seen before. In doing so my conviction to use Scrum wasn’t reduced but instead enhanced. To me this was an important part along the road to Lean Management.
Subjective view Thomas
Going in at the deep end
I first learned of the new product line to be developed literally on the same day I joined the company. The venture sounded pretty daring to me under the given circumstances. At the same time I felt a lot of energy and determination within the management. I thought that this would be a strong driver for any project. Soon it was clear this project would require a major change in the way the company worked. Discussing the options at hand, I was convinced that a straightforward Scrum approach would be a good way to go. But would we be ready for this kind of change? My management peers were open to agile methods. But there was also considerable doubt. Agile was still perceived as immature and chaotic by some. Walter and I talked it over until the two of us were convinced it was the right way. We knew we would be in this together and be responsible for the outcome. There was little time to establish trust between us, and no time to negotiate exactly what our roles and responsibilities would be. So there was plenty of uncertainty when we moved on to propose the use of Scrum. But I had gained enough trust in our ability to work it out together that I was ready to take the plunge. Our fellow managers and the board of directors challenged us thoroughly. We had to provide solid reasons for why Scrum was a reliable way to work. I felt that being challenged was a very good thing. Firstly, it was a good Q&A by those who know the organisation and the market well. Secondly, I think it was the start of the organisational change: we all went out of the meeting and got behind the idea.
Forming the change team
The idea to found a change team came up in the discussion between Walter and Thomas in the course of the management decision process. Actually it was not called “change team” at that time. What we sought was a team of key players with which we could elaborate the details of the new way to work. Retrospectively it doesn’t seem very surprising that those were the very same people who would be spreading the new methodology later on. It was clear to us that the selection of the team members would be mission critical. So we spent quite some time on discussing how to find the right balance within the team, both socially and in terms of expertise.
Once founded, the team (five members plus Walter and Thomas) immediately started to work. At the kickoff the team was informed of the purpose and time frame of the initiative: we wanted to start our first Scrum sprint in seven weeks. We also made clear that we wanted to stay as close to the principles of Scrum as possible. Furthermore, we clarified the role of each of the members. Walter was the sponsor of the change and the responsible line manager. Thomas’ role was to moderate and facilitate the process. We then selected a way to work. “We” refers to the entire team, with the sponsor setting guidelines, providing input and resources when asked and sometimes stating preferences (even when not asked). But at all times the team was in the driving seat, deciding how to proceed.
After seven intense weeks with several workshops per week the preparation was concluded. We had clarified many organisational matters, had chosen a Scrum trainer and had undertaken Scrum training with him, selected the target architecture and design principles, had assigned all roles inside and outside of Scrum and all were considered to be sufficiently understood. We looked at our impediment backlog and the team felt that all necessary prerequisites were well enough addressed to start the first sprint.
Subjective view Walter
I did not want to scare the team with my decision to use Scrum for this project, because I feared that they would think more about the methodology than about our software. Therefore I made the decision to keep them uninformed as long as possible. They knew that we were working on some decisions on the future project, but they received no details. Maybe this was not fair to the team, but I did not want to lose the time with discussions on the development methodology within the development team. As mentioned, we had very intense discussions with the people around the team.
Subjective view Thomas
Retrospectively, I see two key decisions we made then. Firstly, the selection of the change team members. They needed to be curious and open to change. Furthermore, we needed all necessary skills and a good social mix. We wanted people who would push forward in there, we wanted enough room for internal criticism, and we wanted a constructive climate – a lot of criteria to look at, so we spent a lot of time on deciding who to select. When we started we were pretty convinced we had made a good choice. The second decision concerned how we would run the change. We decided to use the same principles for change management as in the method we wanted to introduce: an empowered, self-organised team that organised the change, with a sponsor acting much like a product owner, and a facilitator acting much like a Scrum master. In terms of values and principles, the team used the “agile way to work” before it had its first Scrum training. Once we started designing the new organisation together it was a great experience to see the change picking up momentum. Accompanying the team as facilitator, I met unwavering resolve as well as doubt. I tried to give adequate room for both.
Starting the first sprint
Finally we got to the point. No more discussions, we started to work according to Scrum. The first sprint was quite unspectacular. Our external Scrum trainer helped us during this first planning phase which proved very beneficial for the team. The commitments for the sprints were reached and the quality of the results was good. The commitment was rising from sprint to sprint. We additionally added some people to the team because the team requested this (testing skills) and because we got some new requirements and the necessary skills were lacking among the original team members.
Subjective view Walter
The team produced very good work. There was no need to adjust major points. Instead, we tried to influence the people within the team when we saw that there were points that could be improved (e.g.: increasing test automation).
Subjective view Thomas
The team made an excellent start. So from this point on I monitored what was going on quite intensively, but had little reason to interfere. I frequently checked how Walter, the product owner and the Scrum master felt with respect to how they perceived the project was going and whether they needed any additional support. In parallel I regularly checked the sprint burn down charts and asked the Scrum master what conclusions she drew from it. Occasionally I gave recommendations on what could be improved, but mostly I felt comfortable in trusting the team to find its way.
The first sprint that failed
Like in most Scrum teams, the team got careless. They overcommitted themselves. The whole team did not react to this fact until it was too late even though it could be seen very early.
Later the people within the team reacted very differently to this. Some tried to get as much done as possible, while others tried to find excuses before the end of the sprint (“We are doing our best, but it’s not possible to reach the commitment. That’s OK, isn’t it?”). We and the Scrum master made our expectations clear: It’s your commitment and we expect you to do all that’s possible to reach your commitment. Should we fail, the retrospective is the time for discussion.
Subjective view Walter
I think this was one of the most important moments of the introduction of Scrum. If you simply tell the team that it’s bad if they do not reach the commitment, they will always tend to under-commit. But on the other hand, I wanted to criticise them, since they did not react how I wanted them to react. Therefore I criticised them for the way they dealt with the sprint. I tried to be the mirror: I described to them what I had seen (e.g.: in the burn down you could see that they wouldn’t reach the sprint commitment) and what they had done with it (they reacted when it was too late). They made some of those mistakes and I explained all of them in the review. They used this information very well in the retrospective and improved a lot.
So the message was: It is okay that you did not reach the commitment. We expected that sooner or later. But it was not OK how you worked in this sprint. You can do much better. Two sprints later I showed the team using some statistics that with their new velocity they would have reached the commitment of this failed sprint.
Subjective view Thomas
I was not concerned about the team failing a sprint. In fact I considered it a natural dip in the learning curve. My concern was whether the team would be able to draw effective conclusions from it. Walter and I reflected on that and felt that the retrospectives were well established and productive. Yet there was still some sentiment of trying to push away the responsibility for failure instead of accepting it as natural and a chance to learn. This was probably due to the company culture and/or the personal attitude of some team members. It was a difficult question for us determining how to approach this as managers without violating the self-organisation of the team. Walter’s approach to mirror the team was new to me. Personally, I would have probably tended towards more direct interventions. Retrospectively I find that his approach was quite effective – the track record of the team improved. No further sprints were failed and the velocity steadily rose.
Meeting the milestone after four months
Finally the team reached the first milestone after four months of Scrum. The result was quite impressive:
We got very good feedback from our stakeholders and all of the other people who saw the newly developed software.
The quality was good in all aspects: number of bugs, functionality, user experience and usability, architectural quality, automation of nightly builds, reporting and automatic test execution and so on.
The number of features developed was very high.
The team was able to deal with very strong changes to the goals from sprint to sprint (e.g.: a complete switch of the device for which the software was developed and then back again in the subsequent sprint). The team was also happily working with Scrum; all initial reservation was gone.
The product has yet to be deployed in a productive environment. As a direct result, there is no definitive way of measuring the success of the approach taken to develop the new product. Therefore some pitfalls are still waiting.
Conclusions: what were the success factors?
- See that middle management is part of the solution, not part of the problem. Seek alignment within the involved management and resolve conflicts of views or interests within management. Make sure the decision to introduce Scrum and the approach concerning how it is introduced is mutually agreed upon. Otherwise the management disharmony will be inherited by the team and it will chronically disturb the team’s work. Make sure that you have no “losers” within the management team when you introduce Scrum. If your peers are not part of the change team, keep them well informed to create trust in you and your actions.
- Use resistance and uncertainty as a resource: take the time and the challenge to discuss your approach with those key players in your organisation who are hesitant to employ agile methods. You will find out a lot about leaks in your approach and whether you really know enough to make a well-founded decision.
- Trust the team: select the right team members, and then trust them to find their own way. If you don’t trust them to do so, don’t start Scrum with that team (yet).
- Help the team where possible: Scrum is a methodology which involves the team and its members having to define the details of their methodology themselves. But if you as a manager see from the outside that something needs to be improved, you should help the team while respecting its self-organisation. One way is to be a mirror for the team and reflect what it is doing and what it should think about. Support it along its path to finding its own methodology and if you want to correct something do this by asking the right questions and by pointing out the right observations.
Walter Bachl is Senior Vice President Products and Development at the Germany-based company MSG systems
Thomas Spielhofer is management consultant on agile methods