Pages

Friday, August 31, 2012

Agile in the Corporate Waterfall


In an earlier post, I explained the basics of “AgileSoftware Development Methodology”, where software products can be built as “successive improving iterations”.

Agile methods seem to have proven/acceptable project success rates. 
But the reality is that the “corporate structure” requires “Waterfall” like thinking; as funding, cost commitment, scope commitment, schedule commitment, labor forecasting, resource allocation, client promises, legal requirements, risk mitigation etc. requires prior planning. Due to these realities and other reasons, many organizations that claim agile are still running hybrid of combined agile and waterfall.

[Waterfall is named.. as the model follows a sequential set of steps to develop software; with steps like Initiation, Analysis, design, Build, Test, Move to Production, Maintain etc.]


Below are some tips on integrating agile into the corporate waterfall culture.
  • Accept that the enterprise is thinking in a waterfall manner; for very good reasons. [Executives not only want you to deliver, they also expect you to plan and commit prior to building.]
  • Accept that Agile-or-Not, some level of planning is still needed for upfront commitments. [Well... some agile practitioners and corporations may have committed to pure-agile; good for them.]



Model for Agile in a Waterfall corporate

Above diagram separates high level planning processes, from low level agile processes.
Think of current project as implementing a subset of possible product features.
[While waterfall is Project-Centric, agile is more Product-Centric. Scope current project as part of an ongoing product; this project can only tackle what budget allows.]

  • Based on requirements, create a list of possible features as “Product Backlog” [What should be in the product someday].
  • Prioritize some (must-have and other) features from "Product-Backlog" into current project as budget permits; and call that "Project Backlog".
    [Project’s unfinished items may move back to product-backlog.] 
  • Estimate features selected to the project (project-backlog) at a higher level [just like estimating in waterfall].
  • Let “Executive View” of the project be around the “project backlog”, “project completed items”, “estimates to project completion” etc.
    [So that... this project is planned and committed to the project-backlog not product-backlog.] 
  • Work item flow is to move items from product-backlog to project-backlog to release-backlog to sprint etc.
    [As prioritized items move through release, sprints etc. estimates can be improved… and “Executive Views” can be updated.] 
  • Backlog re-prioritization will occur as changes are identified to the current work item collection; then again changes are a part of waterfall too.
    Execute all changes using standard change-process; and update all views as necessary.


Hope this contributes to.... executing your agile project, while painting a planned view to the enterprise.


The line… “Plan with Waterfall, Execute with Agile” is getting traction.



To be practical:
Leave a comment :-)