Recently, I was able to witness a remarkable event in a company that is relatively new to Agile. They have several teams at about Sprint 12, with several new teams just starting up. Many of their processes are waterfall based.
A failed waterfall project was moved to an existing Agile Team.
In the second Sprint, the Team (feeling trust in the organization and the process), came to the Scrum Master and said, “We’d like you to talk to management. We are not sure this project should be using the platform we develop on. We think another team’s platform may be more appropriate”.
The company had spent time developing a “specification document” for this “project” before Agile was introduced. There were detailed specifications as to how the product was to be created and which platform to use. NONE of this was done with the benefit of asking those that would actually be doing the work.
The project was initiated before learning about applying Agile. One developer was tasked with following the specification. After 2-3 months of frustration, the developer left. This left the company in a bad position. Not only was the project incomplete, but there was also no knowledge transfer. The project was basically stopped.
As Agile was now the new target way of doing things, the project (and new developer hired through the previous process) were added to an existing SCRUM team. The team is using one week Sprints.
After only two Sprints (two weeks), the team had recognized the futility of the approach that was “specified” and took this to management.
Traditionally, large organizations staff for projects. In an environment such as this, how could team members be expected to be truthful and honest about the state of affairs? It would mean the end of their jobs or contracts.
The key here is to allow teams to stick together. Not only will you avoid losing all the efficiency the team has built up, but you will also allow them to be truthful about their situation.
If you are a manager reading this, ask yourself. “Do I want to know that things will go wrong at the beginning of the project or wait until 5 months have gone by to be told, ‘We knew it would never work”". Or even worse… “We knew the product owner was asking for ridiculous features that had no Return on Investment for the company, but hey, you hired us for this contract. We just follow instructions”.
As it turned out, the project did continue with the current team, but with some changes to the specification. The parts of the system that were going to be problems in 5 months were re-evaluated and were removed as they really did not have any real value to the company. It was then decided to stick with the same platform.
Discussions did occur regarding moving to the alternate platform, but were deemed unnecessary after open discussion between the teams and the managers involved. Realistic expectations were set based on value to the company.
Sometimes features are absolutely mandatory for the product. This cannot and should not be taken away from the process. What we gain here is that we are able to have a discussion about necessity. In the end, the business has to decide what is valuable, not the development team.
In a case like this, ask yourself, “If my team is very against this, maybe I should at least think about it”.
The company is working in a very short iterative environment, they quickly recognized a flaw in the system design and dealt with it after only 2 weeks into a several month project.
Working incrementally allows the company to “Inspect and Adapt” on a regular basis. This has to include the question, “Does this still make sense?”. If you need to go backwards, let it be to reverse one or two Sprints of work, not months, or even years.
Fortunately, for the company, the product will come out on time, with appropriate technology based on Return on Investment, and likely with significant cost savings over the initial design. This will also allow the team to get started on other high value projects. Talk about win-win.
This project could have gone to another team. It would not have been negative for the first team. The next project would have just come down the pipe for them.
The early signs helped adjust the “expectations” and everyone is moving forward with a clear understanding that they are on a more appropriate path going forward.
For those of you out there trying to convince companies (or yourselves) that Agile is an effective framework, don’t be afraid to talk about “RISK MITIGATION“.
Think about it this way; The company wants to know early on that there will be a problem, not near the end of the project. This is part of the purposeful transparency of any Agile framework.
Mike Caspar
Mike Caspar’s Blog
