The transition from waterfall to Agile is a difficult undertaking that many companies attempt and ultimately fail. Even in these failed attempts their environments become Agile-like. What makes this transition so difficult and what causes it to fail?
Think of the waterfall model as a set of stairs. Each step is a smooth surface that when you reach the end drops off to the next step. The software, service, application, etc. that the company is trying to produce is like a bicycle. The company wants to ride this bicycle from the top, the concept, to the bottom, the market. The result is a bumpy ride. The bicycle makes it to the bottom, sometimes, but sometimes the wheels fall off, or the whole bicycle just falls apart.
Think of the Agile process as a smooth ramp from the top to the bottom, similar to the appearance of a burn down chart. Riding the bicycle down the ramp is not only smooth but quick. Once the bicycle reaches the bottom it is in pristine condition.
So, how do you change a stair case into a ramp? The answer: start shaving down the stairs to smooth out the transitions. We try to do this by introducing Agile methodologies here and there in the process. Typically, this process starts near the top of the staircase, development.
Part of the problem with this approach is that by only targeting development the entire software delivery process is not addressed. If groups like QA or systems support are left out of the Agile process, then the top of the stair case may be smooth but the steps at the bottom of the staircase still result in a bumpy ride.
Picture this process: development completes its final iteration and produces a release candidate. Then QA tests it and finds some show stopping bugs. First, this means that we as a team failed to fail early. Second, we are still completing all the code then throwing it over the wall to QA. (Sounds like a waterfall, to me.)
And what if we fail to integrate systems support early into the process? If the application the team just wrote needs 6 new servers in order to run in a production environment and we’ve waited until QA has finished, we could be set back several weeks while we wait for the systems to be ordered, delivered, and setup. Again, if the systems people were involved early in the process, these lead time items could have been ready and waiting.
In order to smooth out these stairs at the bottom we need to include these groups early into the process. Pair a QA person with a developer at the beginning of a new feature. This gives QA an early glimpse at the features that the will need to test. They can then provide testing at verification that would allow QA to verify each feature as a stakeholder.
Also, assign stories that pair team members with members of systems support to set up dev, qa, and production environments. That way if any hardware, rack space, networking, etc. needs to be allocated the systems people can get those early in the process.
By including QA and Systems administration into the Agile team space the staircase that represents waterfall methodologies can be smoothed into a graceful Agile ramp.
