Of the four value statements presented in the AGILE Manifesto, the fourth one (We value responding to change over following a plan) causes frequent misinterpretation among technologists.
New AGILE practitioners need to keep in mind that adaptive methodologies were meant to address the lack of flexibility and fluidity during the construction of a solution design. In that sense, the arrival of AGILE 15 years ago exposed the value of delivering software in an adaptive way, emphasizing customer collaboration over agreement on a comprehensive statement of work, or a big plan to deliver it.
This has been certainly the greatest contribution of the AGILE movement: The realization that software that works could be delivered collaboratively by the team with just the right amount of specification up front.
Nevertheless, AGILE enthusiasts are sometimes so excited about avoiding big design and big planning that they tend to carry their skepticism on “big” efforts beyond the solution domain, all the way back into the problem domain. Thus, some AGILE teams would fall into the trap of also avoiding what they would perceive as “big analysis”, and would dismiss even the need for any preliminary structured requirements documentation.
This slant against starting a project with comprehensive requirements analysis is sometimes worn like a batch of AGILE purity by new converts. Its discourse, thrown around during project meetings, distracts the team from being effective at aligning solution design with strategic intent.
Strictly speaking there is no better defining moment for the success of an AGILE Project than prioritizing and grooming the product backlog to address high risks and high value opportunities during the earlier sprints. It follows that only comprehensive business analysis with a resulting requirements baseline can prepare the project team for this prioritization.
Project managers who are seasoned in AGILE would see no contradiction between employing adaptive methodologies in solution design while relying on a thorough analysis of the problem domain as a starting point, as long as requirements are identified and defined only at a low level of fidelity.
We are not stating anything outside the AGILE credo. Each iteration in AGILE is expected to start with the big Word: “Strategy” which means that AGILE expects a review of the problem domain, and an analysis of the requirements at the beginning of the sprint; however, in the real world, only in very limited contexts the team has the luxury of continuous access to a product owner who could articulate strategic intent.
For complex projects (think of an enterprise software implementation in a global context) it is harder to envision an AGILE team during their daily stand up or scrum, prioritizing among designs that address risks and opportunities, without a baseline of requirements validated by project stakeholders.
Arriving to such a baseline involves engaging in a comprehensive analysis of all processes to be impacted by the IT initiative. There is no cutting corners with enterprise analysis work here.
To follow the AGILE approach and define requirements “Just in Time” at the beginning of a sprint certainly adds flexibility and fluidity to product development; however, we have to be careful not to confuse “defining” requirements just in time with “discovering” requirements just in time. The latter is unpreparedness that increases project risk. It might not translate into reworks and value loss in very small projects (maybe not in the development of a webapp by a tech start-up, where strategic intent is questioned, shared, and understood by the team daily) But for more complex IT initiatives, with multiple stakeholders in matrix based contexts, the lack of a requirements baseline would make it harder for the AGILE team to determine which product increment would return the highest value in the project.
December 28th, 2012 ByLarry Velarde, CBAP®
