Agile practices for creating software within enterprises have been gaining ground in recent times. Even though shift is not tectonic but subtle, it is important nonetheless. One of main reasons for this has been that many big enterprises have realized that traditional methods have failed them at times. I have seen quite a few big enterprises spending millions of dollars on projects just to realize that projects very often overrun cost and don’t give them operational systems as they would have envisioned.
Do it Small and Detect early: Software projects fail for various reasons and going agile is not the panacea and it doesn't guarantee success either. But what Agile does is that, it reduces chances of a costly failure as progress of project is known to all stakeholders and an early decision about termination of project or change of course can be taken. A constant progress monitoring of project, continuous build and test, small iterations,sprints etc lead to early detection of problems if any. In this regard Agile is akin to RUP like iterative approach and breaking big into many smalls and doing continous health checks on them.
Focuss On People: But most importantly, What Agile also does is that it brings focus on people and project teams and put them in control. Process boundaries are lowered so there are no processes to cover for failures later. Fetish for processes is diluted so that team doesn’t drown beneath cumbersome and often stifling processes. People are the key ingredient for projects to either succeed or failure. Agile project teams are empowered to think and adapt as needed for success of project. Since teams are in control of project, they can not turn around and blame someone else or some process later for failure. Agile makes team members more visible and accountable. In principle, Agile just states a truth which many would want to ignore for sake of industrialization of software that People are most important element of code assembly line and heroes need not be discouraged.
One caution which enterprises adopting Agile has to follow is that they need to make sure that all pre-conditions for agile to work are met. Agile need some cultural changes and mindset adjustments. Agile teams are built around trust and openness to change. Most Agile teams are cross functional with Business and IT skills working in very close cooperation. Enterprises outsourcing their Software needs to vendors and using agile should keep in mind few things :
1.) Put key personnel in charge: Key Business and IT people should be put in charge of project (well, shouldn't that be true anyway ;)).
2.) Accountable Product Owners: Product owners should be people in your organization who can answer questions. Buck should stop with them. Very often cause of project failure is due to volatile requirements or difficulty in nailing them down properly and on time. Especially if organization is big and diverse, getting access to business people who can provide answers is difficult. This should be changed with empowered product owners being part of project team and not just as outsiders.
3.) Build Prescriptive Processes: Agile doesn’t mean no process. It doesn’t mean guerilla programming either. Agile means adapting quickly to changed scenario or context. Instead of a frozen, rigid, descriptive Process, a prescriptive process or Meta-process can be created so that agile teams are operating within a known process framework but with desired leeway to improvise and maneuver.
5.) Model for Offshore Agile: As is the norm these days, if agile team is distributed across locations, put some thought on how multi location latency can be managed. Decide if you would need proxy product owners in remote teams or how cross pollination would be done to maintain one team spirit of Agile. Remember that Agile can be adapted to your specific needs and constraints. Purists would say that distributed teams are not pure agile teams, but real spirit of Agile is adaptability and not maintaining purity.
6.) Agile doesn't mean cheap: Agile doesn’t mean less cost of doing software. In fact it can mean more build cost. Successful agile projects would create value in terms of reducing hidden costs which are usually accrued in traditional methods of tight control and change aversion.
7.) Fixed price versus TnM Get over fixed price mindset. Fixed cost projects don’t reduce your risks anyway. They only delay the costs by converting them into Hidden costs (Change requests, maintenance) .
8.) Not for all conditions: Agile might not be suited for all scenarios. In many cases, traditional methods of tighter control, elaborate requirements in beginning and managing change are required. There is never fit all solution.
Ultimately, Agile is just a collection of good development practices which puts value and emphasize on certain aspects of software engineering. Keep overzealous agile evangelists and those who think it is passing fad at equidistance.
1.) Put key personnel in charge: Key Business and IT people should be put in charge of project (well, shouldn't that be true anyway ;)).
2.) Accountable Product Owners: Product owners should be people in your organization who can answer questions. Buck should stop with them. Very often cause of project failure is due to volatile requirements or difficulty in nailing them down properly and on time. Especially if organization is big and diverse, getting access to business people who can provide answers is difficult. This should be changed with empowered product owners being part of project team and not just as outsiders.
3.) Build Prescriptive Processes: Agile doesn’t mean no process. It doesn’t mean guerilla programming either. Agile means adapting quickly to changed scenario or context. Instead of a frozen, rigid, descriptive Process, a prescriptive process or Meta-process can be created so that agile teams are operating within a known process framework but with desired leeway to improvise and maneuver.
5.) Model for Offshore Agile: As is the norm these days, if agile team is distributed across locations, put some thought on how multi location latency can be managed. Decide if you would need proxy product owners in remote teams or how cross pollination would be done to maintain one team spirit of Agile. Remember that Agile can be adapted to your specific needs and constraints. Purists would say that distributed teams are not pure agile teams, but real spirit of Agile is adaptability and not maintaining purity.
6.) Agile doesn't mean cheap: Agile doesn’t mean less cost of doing software. In fact it can mean more build cost. Successful agile projects would create value in terms of reducing hidden costs which are usually accrued in traditional methods of tight control and change aversion.
7.) Fixed price versus TnM Get over fixed price mindset. Fixed cost projects don’t reduce your risks anyway. They only delay the costs by converting them into Hidden costs (Change requests, maintenance) .
8.) Not for all conditions: Agile might not be suited for all scenarios. In many cases, traditional methods of tighter control, elaborate requirements in beginning and managing change are required. There is never fit all solution.
Ultimately, Agile is just a collection of good development practices which puts value and emphasize on certain aspects of software engineering. Keep overzealous agile evangelists and those who think it is passing fad at equidistance.
No comments:
Post a Comment