In one of my recent posts, I tried to tell a story of a successful project following Agile methods. Now it's time to flip the coin: let me try to tell a story of a miserable project. This was not a failed project though. The project eventually completed, with near 100% schedule variance and comparable effort variance, but with acceptable quality and conformance to all norms of closure. To give credit to myself (or to Agile), I don't have any story of failed project to tell.
It was a Sunday afternoon, when I was trying my eyes to believe what are being painted in front of me. It was a cozy meeting room, a room where I prefer to talk while standing, a room cozy enough to prevent me pacing bi-ways out of nervousness. With me, there sitting my boss, and two other developers. My boss summoned me to be there, he got a salvo or two from a senior executive of the client. The developers were trying to put forward the project situation, as-is. The first version was a little less than hunky-dory, and I learned that the team conducts a Scrum daily. An attempt to align the client's frustration with the project situation created the second version of the project situation, which was not only far away from being hunky-dory, but a lot scary as well. A critical phase in the software development life cycle got skipped: Testing. The developers were unfazed. The project called for 2 developers, so 2 developers started working. Developers never realized that they need to handover the codes on time to the testers. No body followed up with them either. As a result, the project directly moved to UAT after construction, that too when the construction was not complete. On the day one of UAT, client realized there was nothing for him to see, verify, and accept. He got furious.
Despite of having daily interactions with the client and developers, the project still went into red. It went into red, because there was a lack of appreciation for the SDLC phases. People loved Agile, tried to do some Agile stuff, without realizing that the fundamentals didn't change. Agile methodology does not cover SDLC, in certain aspects, it negates it. That prompts the team practising Agile, and bend for programming to miss out the big picture: the need of testing before releasing the product.
The story did not end here. Follow on meetings with the developers revealed none of them know how much to code and implement. There was no requirements document either. So developers were doing coding based on their understanding of the functionality which were not only inadequate, but also carried the risk of being misinterpreted. As a result, on the day two of UAT, the problem in hand was not just incompleteness of codes, but a total unawareness of the size of the remaining work.
The rest of the story was a familiar tale, an approach that have been followed from the stone age of software engineering. Some of the reputed fire fighters were deployed on the scene. They started working 20 hours a day everyday: coding, understanding requirements, testing, communicating with the client like a PM, and generating intense push-pull force between the buyer and supplier. After 2 weeks of a grueling endeavour, the project started becoming back on track. Client started seeing the work products getting delivered, client started seeing less errors in the delivered work products. The fire fighters started disbanding in search of another fire.
In short, just Agile does not work always. It requires a good understanding of the SDLC. In fact, all successful Agile practitioners today have got their foundations built through the classical SDLC process. Inherently, they practice the good stuff out of classical SDLC. An attempt to bring methods in the madness has always turned out to be effective in Agile projects, provided the teams carry an openness to accept good things from outside.
