The preamble would say that all elements of this story are fictitious and if they resemble to any real life element, that would just be a coincidence. Having said that, the story starts with a project conducive enough to practice Agile. For me, it was not the first Agile project, but my interest to run it like Agile was on the higher side. I did not do any assessment to figure out whether Agile would work here or not (like I mentioned in my previous post), but my guts were telling me that this is the project for Agile methods.
Here it starts. I visited my client (the product owner) with one of my team mates to understand what the client wants. The client told us a story. For sake of anonymity, I would keep that story out of my posts. The story triggered a brainstorming session only to result a data entry screen and two reports. After the 100 minutes of the meeting, I added two standard features into it: login, and administration. At the end of the meeting (in about 2 hours in total), we agreed on a tentative timeline (needs to be shown in 2 weeks), project commercials (some thousand dollars to be billed), and came out to write our meeting notes.
My team mate started development, mobilized servers for hosting, and at the end of the first week, we made our demo of the data entry screen. No reports were ready, but nobody complained either. The audience of the demo comprised of some of the users including my client (4 in total). Some good suggestions came in. We noted down all, on spot classified the items that would take longer time and effort to implement. In support of us, the client shoot those down immediately by flagging them as features for future. At the end of the week #2, we released the application for UAT.
The UAT was planned to be an innovative one. Instead of running a script for testing, 40 users were identified and were asked to use the system. We gave them a hour long training on the application, along with a form to log their feedback. The client has mobilized a manager to collect all feedback forms, collate those into one, analyze those to various categories and identified those with the priority to ship. This compilation indeed became a collectors' edition due to its richness of the user feedback. Some of those are truly awesome, would not be possible to anticipate or detect by any developer or tester. Many of those reveal the need of having a user's manual, it was unbelievable that we had delivered a product without user's manual just because we were following Agile.
After a week-long UAT, another week was spent on implementing the prioritized feedback. Like the first one, we did the upfront cost estimate for the changes or new features (a few thousands dollars again), and picked up all programming bugs without hesitation. We followed a principle of fixed fee charging, so all programming bugs were serviced free of cost. Subsequently, the application was laid open for all 300 users.
The story could have ended here. But the project continues. Once it goes live, the client brought out a few more things to add in the application. A few more data entry screens, a few more reports to go. Now the application is live and kicking, articulation of the new requirements were far more easy. No wonder, my next visit to the client to gather requirements ran for good three and half hours. The requirements list was long, naturally it would take longer to implement. The client was agreeable to that too. This was the time I contested his thoughts. My opinion was that the project delivered good results in 2 weeks of development (and unit testing), 1 week of UAT, and 1 week of bug fixing / changes. We should stick to this plan. The fact that the requirements has got longer this time would mean that we have to slice it into two. Or three. Or four. Whatever it takes to cut down to the 2 week schedule. We had one developer at the start, we will add another one this time. That will enable the team to take twice the amount of work. But the schedule should not change. It would not elongate, it would not be shortened either.
My client agreed. He didn't have to worry though since I was talking of frequent deliveries this time (most of the time we get our clients into the reverse kind of arguments). So we started the same schedule for quite a iterations subsequently. At this point, like a classroom teacher, I should start to map the Agile terms with the various acts in this project. But I am refraining from doing so. I assume the readers would be able to do it themselves. Those who are not sure, please read all my posts on Agile Intelligence from start.
