The "normal" Scrum project
When I look around in the Scrum community, I wonder whether Scrum is only suitable for modern software development. All these shiny, new ways of making really cute, web- based software, with modern source repositories, automated unit and regression testing tools, and other fancy stuff. If you look at typical job postings for Scrum specialists, you see the same situation: It's all about modern, web-based systems and applications.
How about legacy applications in an old-fashioned insurance company?
Because I was working in a "classical" software environment, I wondered why Scrum was not more frequently used in those environments.
Some excuses for not using Scrum include
- "We always do it like this; there is no need for change!"
- "I like the ideas, but I cannot imagine how we can deliver something in only three weeks time, even the regression test will take longer!
- Our processes prevent us from using the Scrum methods, we have to do X, Y and Z, otherwise we will not succeed."
I think there is a fundamental reason for the reluctance to adopt Scrum in those software environments, and it is exactly the reason why Scrum was invented.
A typical example in a "classical" environment
Before we go into details let me tell you a short story about test automation of letter production. In an insurance company, the focus on regression testing of the software system was very high, because all the standard letters, which were sent to the customers, had to be tested manually. They had to be inspected manually and have been visually compared to the former versions. It was obvious that the effort to automate this process would realize its ROI even in the first project when it was applied. Nevertheless the automation was never implemented. It had been scheduled into each project, but because of time constraints it was always de-scoped in favor of some more "real" functionality.
How could this happen? Because the team who was able to implement the automation (the developers) did not get any benefit from it, and the team who was asking for the automation (the testers), was not able to implement it. Therefore it was delayed for years.
So what and who caused the effort to fail?
This question is not easy to answer. In every project the Project Manager made the right decision in de-scoping the automation task. It was always the right decision because it stabilized or even rescued his project. So if it was not the Project Manager's fault, who was to blame? Upper management should not be made responsible for the Project Manager's decisions, which are real day-to-day work and should never be discussed at their level.
So, if nobody is guilty, then the process must be at fault. The established process leads to the situation where the automation task is always de-scoped. Also, it makes it less urgent than some other tasks in every project where it is included.. To summarize, there is no control in place that is able to monitor the effects of de-scoping the automation task in a global "cross project" view.
What rules must be changed to get the automation task done?
- Obviously the testers must have the authority to request the development from the developers.
- The Project Manager must not be able to de-scope the task in favor of new requirements.
- At a minimum, upper management must be aware of any decision to delay the task
If we think about the probability that we can to achieve the above changes, I'm not too optimistic. How should I empower the testers to prioritize the developers' work? How should I limit the project manager, so that he is not allowed to de-scope the task? How should I make these tiny project decisions visible to upper management? All these changes are prohibited by the process. The process' rules prevent them.
And in a more "agile" environment?
Now let's have a look at a Scrum set-up. How would this situation be handled in a Scrum organization?
In a Scrum organization, the team would be cross functional, where all relevant parties participate. In this example the testers and the developers would be in one team. The team could not be successful if all tasks were not "done" at the end. And after the team has accepted a task it is responsible and stays responsible to get it done.
In a Scrum organization the product owner cannot change the contents of a Sprint. He cannot de- scope a task in favor of another task during a Sprint.
In a Scrum organization, if a task is part of a Sprint and it cannot be delivered, the managers are made aware at the end of the Sprint...
In a Scrum environment the problems in our example are resolved.
If it is this easy, why don't all organizations just switch to Scrum?
It's all about agility
The problem is the transition to Scrum.
First, you need to have one team which is representing all aspects of product development and is capable to fulfill all the needed tasks.
To achieve this, the established walls between the different roles in the software creation process have to be torn down. And those walls have been so comfortable for all participants. (it is much easier to blame process as opposed to at a colleague). And if a development is not yet ready, a tester has no problem complaining about delays in his plan..
In my project experience I once tried to establish Scrum practices in a kind of a "silent roll-out". I wanted the team to work together across departments and roles, but I realized that this was not possible. You cannot build a "real" team without letting the team define its rules themselves. And you cannot change the rules that have been used by the established processes, without explicitly changing the processes.
Second, you need to establish the Scrum roles. You need a "real" product owner, who knows how to play his role. You need a ScrumMaster who fights for his team and protects it from outside influences.
Third, you need to transition to a time-boxed approach as soon as you start with Scrum. The time box is the most revolutionary change to the classical environment imaginable. Once, when I wanted to establish some Scrum-like practices in a project, I convinced the IT line manager and the project manager to have fixed development intervals of 3 weeks. We had a pipeline from development to testing and finally to user acceptance testing. But as soon as we got a delay in development, the project manager wanted to have the dates shifted to get more results as soon as possible. The benefit of having a time-boxed approach and agreed handover dates from team to team, was sacrificed for a potentially "more complete" next code drop.
You need all of this to start with Scrum. And don't be overly optimistic. It will require discussion, training and good leadership to transition.
What did we learn?
As I stated earlier, I think there is a fundamental reason for the reluctance to adopt Scrum in "classical" software environments, and it is exactly the reason why Scrum was invented.
In some organizations, the established processes are stabilizing themselves even if they are not helpful. There is no culture for changing the established processes.
In some cases, the established roles in a "classical" environment do not take responsibility for the whole. There are situations where team members make excuses because something isn't their responsibility. Also, individuals are not empowered to make decisions.
In "classical" environments, time and cost are less important than quality. Because of this approach, delays are widely accepted and at the end of the project de-scoping of less prioritized tasks is typical. This leads to projects whose status cannot be measured continuously.
In other words: with Scrum you constantly measure your performance, empower your team, and constantly improve your processes. These elements of Scrum are crucial for an organization to improve its processes and to accelerate the release cycles and the features delivered in each release. Unfortunately the inability of the processes in "classical" environments to support these improvements leads to the difficulty in implementing Scrum in those environments.
Implementing Scrum is hard work, but it's worth the effort.
