Minimizing Risk in an Agile Approach

Leave a comment

by Phillip Smith

The discussion about which project management approach to use is irrelevant if the chosen approach is not implemented correctly. The IT industry, while relatively young, does have reasonably well thought out software development processes (SDP’s) that are mature and reliable. Taking shortcuts within an SDP is never a good idea.

Whether using agile or waterfall, always make sure your plan includes stable requirements, optimized design, and rigorous testing. You should never tailor out critical deliverables, breeze conditionally through tollgates, or attempt to support truly impossible timelines.  It is better to execute in a reliable and true fashion and finish the project the right way, with quality. Stated another way, project managers should never use a difficult timeline or a low budget to justify chaos.

For example: in an agile approach, if you start with a very large scope and parse it into smaller components, and then execute all of the SDP phases for a single component prior to going in to the requirements for any other part of the scope, you will be running a great risk.  The lack of definition of follow-on components, combined with the finality of having the first component implemented, will certainly lead to integration issues and rework.

It is much safer to sprint, in small sections, through all of your scope, and then sprint through all of your high level design.  Make sure that you have a full understanding of the complete project, the architecture, and the high level design before you sprint through any of the build.  You can use a proof of concept if it will help with requirements definition or with the design.

Once you’ve validated the complete set of requirements and high level design, it is appropriate to execute the delivery phases, specifically the low level design, then construct, test, and deploy component by component.  With this approach you will gain the benefits of forcing all of the difficult conversations about scope, requirements, and solution to the front of the project, where it is appropriate to obtain stakeholder consensus.  Then you are free to optimize the delivery path by carving it in to digestible bites.

There is still some risk, because there is construct activity for some components taking place prior to low-level design of other components.  But implementing the agile approach as I described it above retains most of the benefits of risk adversity that are available to waterfall projects.

Author: bridge360blog

Software Changes Everything.... Bridge360 improves and develops custom application software. We specialize in solving complex problems at every phase of the software development lifecycle, removing roadblocks to help our clients’ software and applications reach their full potential in any market. The Bridge360 customer base includes software companies and world technology leaders, leading system integrators, federal and state government agencies, and small to enterprise businesses across the globe. Clients spanning industries from legal to healthcare, automotive to energy, and high tech to high fashion count on us to clear a path for success. Bridge360 was founded in 2001 (as Austin Test) and is headquartered in Austin, Texas with offices in Beijing, China.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s