Adopting AGILE does not mean shortcuts in enterprise analysis work

 

requirements for agile

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®

Copyright Leverforce

Leverforce  Copyright 2016 Leverforce Inc All Rights Reserved. CBAP® is a registered certification mark owned by International Institute of Business Analysis. This certification mark is used with the express permission of International Institute of Business Analysis. IIBA®, the IIBA® logo, BABOK® and Business Analysis Body of Knowledge® are registered trademarks owned by International Institute of Business Analysis. These trademarks are used with the express permission of International Institute of Business Analysis. 

CLICK TO READ THE TERMS OF USE FOR THIS WEBSITE

SAAS Modules

  • Module: Concern +

    Use this module to manage a list of all business concerns associated to an analysis. A concern defines what the client, or the corporate sponsor, seeks to obtain for the business from the IT changes requested. Read More
  • Module: User Requirement +

    This module allows management of user requirements associated to one or many concerns. A user requirement describes a behavior or condition a user requires from an IT service in order to satisfy a concern. Read More
  • Module: Gap +

    Use this module to manage the traceability of all gaps related to one or many user requirements. A gap is the initial proposal from an IT provider. It explains what is going to be built or changed in an IT service to ensure that the behavior or condition requested is available to the user. Read More
  • 1
  • 2
  • Modelio UML Tool +

    With the Modelio extension Business Analysts can use the Modelio visual modelling tool to construct a model of all business processes that will support changes in the service and then sit back and see how the resulting XMI file automatically populates the Leverforce database Read More
  • JIRA Issues +

    Set up JIRA projects from Leverforce’s SLA or Product Increment Modules. Read More
  • 1