BY| May 30, 2011
There is an enormous amount of discussion and literature (in the Software/ Application Development circles?) about different processes (or methodologies), their pros and cons, their challenges, etc. While these articles are right in their own way, in most cases, they preach adoption and acceptance of one process. However, the fact is that rarely does a “one size fits all” approach work for anything – why would software be any different?
Interestingly, most software/ IT organizations are also trying to adopt one methodology across the organization. They bring “gurus” who espouse that process, run training programs and campaigns and try to mould the entire organization in one direction. They try to bring in common practices (positioned as best practices), common metrics (to compare the performance of team or individuals) and common reports (while almost all status reports contain the same kind of information, have you see any 2 organization status reports look the same?). Over time, the organizations gets so consumed by this style of thinking that the people forget – who is it for? Will this help the project that I am executing?
Since I have been working in the domain of software development for the last 20+ years, I have come to realize that the focus of any organization needs to change to what is appropriate for the project. As a Project Manager, I should be able to:
1. Select the base methodology that fits my need as closely as possible: How can I select the right methodology for my project based on the nature and circumstances around my project? What are those attributes of a project that can help me decide the right development model for their project? Can a measurement criteria or guideline be defined for this?
2. If need be, identify key principles of various other methodologies that I would like to adopt: Are their principles of one methodology that I can “blend” with another methodology because they make sense for my project? So, for example, can I use a Kanban board for a Waterfall project? While the two may look to be at the opposite ends of the spectrum, my question is: why not?
3. Identify principles of my base methodology that I definitely don’t need: Are their principles of any methodology that I most definitely do not want to follow? For example, if my requirements are unclear and I am not convinced about a big bang estimate, can I start the project without a detailed estimation cycle?
In other words, I should be able to build a process that is right for the project, right for the people in the project, right for the stakeholders for the project. If you are in a services business and need to give a fixed price bid to a prospect/ customer, you cannot say then that I cannot do it because my process does not believe in big bang estimation. If you are working in distributed teams or with outsourced teams, you cannot say that I will not write detailed requirements because my process does not want me to do that.
Agility is all about being flexible, being able to adapt, fast! Translated to software development, it means:
1. Understanding different methodologies, their strength and weaknesses.
2. Having a tool to help implement different methodologies with relative ease.
3. A minimal layer of commonality across methodologies that can serve organizational needs for reporting/ aggregation without being a liability on the project. As idealistic we may want to be, it is important to recognize that organizations will want some mechanism to get a feel of project progress. That cannot be completely different across projects/processes.
4. Leaving the final decision to the Project Manager as to which methodology they want to use for their project.
5. Assist the Project Manager in adapting to his/her “desired” methodology, quickly.
I would like to know how you go about deciding on the ‘development process’ for your project. Let me know if you agree or if you feel otherwise.
Sr. Vice President – Engineering & Professional Services