Choose: Sooner or Faster?
Life is tough in a software project environment. Everybody tries hard within the rigid triangular framework -- scope, time and cost. One deviation from the defined scope, takes the project away from its desired objective. One day delay in completion of a task may have cascading effects on other dependent tasks in the project and can have a negative impact on the commitments of the project team. One paisa more spent on the project may create a hole in the pockets of the stake-holders of the project, and may also put the project on a dead-end. Adding to this stiff situation, current software making demands quick adoption by project team to the rapidly changing user or process requirements.
Life is tough indeed. On the other hand, the professionals involved in the project are human. They need to keep their social commitments and maintain a healthy family life back home.
Today, stringent demand from the projects have forced the coders to extend their working hours well beyond nine to five schedule, and even to spend many sleepless nights before software releases. To add salt to the demeaning life, current sprout of agile methods and off-shoring practices require nightly releases.
Every time the project manager calls project review meeting and discusses the progress, many fail to show the compliance to the timeline. Now, timelines change like the changing user requirements! Coders always think that they have put effort sincerely through the whole period, and have also tried hard to finish the tasks as soon as possible. They think they are fast, and project managers are too demanding. On the other hand, project manager struggles to convince the client with the buggy source code piled during the day. Sometimes, the function that was working perfectly is now non-functional -- a loss that has become predominant when specs change often and releases happen daily. Of course, to contain the pit-falls, pair-programming is being encouraged. When the project manager and client want to see a workable system every time, one of the paired individuals constantly looks at improving, refactoring, and achieving the desired stability in the source code.
All said and done, every aspect is experimented to enable the software making fast and release-worthy at the end of the day. However, we always miss the subtle points of these methods - micro-granularity of change. The change needs to be broken into small tasks each of which can be achieved in one or two hours, and also, it should be a feature or functional change to the system that the end user can notice. This does two things:
- When expectation is known and well-defined, project manager gets time to discuss with client comfortably about the evolution of the system, and the client (sometimes, it is marketing manager) can give appraisal about the end-user feedback -- a professional triumph!
- Coder gets a fixed set of tasks to achieve during the day. He or she is able to finish their day's job in time with self-satisfaction, and can also take spouse to see a movie in multiplexes in the evening -- a personal triumph!
In my opinion, this is the right way to complete the project or task sooner, and not faster. Coders, now you have a choice!