Before going on much longer in this blog, it is important to address “Agile”.  Proponents of Agile often advocate an Agile approach instead of using more traditional waterfall approaches.  A key part of the rationale in adopting Agile includes:

— avoiding the development of a “big, bad requirement document” at the beginning of the project
— customers often don’t know what they need until they see it
— it is impossible to define a complete set of requirements at the beginning
— requirements always change

Proponents of Agile do have a valid argument that says for some projects, the traditional “waterfall – deliver it all” methodologies do not always work and often fail.  However,  many of the problems with waterfall approaches Agile proponents seem to be addressing are really the failure of the team to follow the best practices to which Systems Engineering (INCOSE) and Project Management (PMI), Business Analysts (IIBA), and CMMI processes advocate.

False Agile Perception – Requirements are not needed

A key issue that  many Agile proponents advocate is that documented requirements are not needed for their project to be successful.

Proponents of Agile feel that stakeholder expectations can be clearly documented via Use Cases and similar methods without the need of specific requirements (shall statements) on the system.  Because documented requirements may or may not exist, verification (as defined in a previous blog) is not performed.   Success occurs when the delivered parts and eventually the whole system has been delivered and validated to meet the stakeholder expectations in the intended environment.

The problem with this line of reasoning is that the customer expectations don’t always address all the drivers and constraints that the development team has to adhere to (interfaces, regulations, standards, quality, security, safety, business requirements, etc.)  Thus the development team may deliver a “working product” that meets the customer “stated” expectations, but does not meet essential requirements that were not stated explicitly by the customer (but known by other stakeholders involved in the project).

False Agile Perception – Agile can be used of all types of projects

Another issue is that  many Agile proponents advocate Agile approaches can and should be applied for all product development projects.

Agile has been proven to work for certain types of projects, however one size does not fit all.    Agile has its place for a clearly defined subset of projects:

1. Small projects where the project deliverable can be broken into workable pieces and the pieces can be integrated into the whole when completed and still perform something useful.
2. Projects where the developers and stakeholders are co-located so that the stakeholders can be closely integrated into both the formulation as well as the implementation phases of the project – this assumes the stakeholders are willing to commit their time in making this work. [We have had clients tell me they were very sorry they hired a company to develop software using Agile methods when that company was located 50 miles away and wanted and expected the customer to travel to their facility weekly.]

Most of the projects that fit an agile approach tend to be software – developed in-house where item 2 applies.  It also applies mostly to what is called incremental development (for when the requirements are understood but the product can be delivered incrementally) or spiral development (for when the requirements are not understood initially and multiple prototype cycles are needed to clearly understand what is needed.)

Requirements and the Agile Manifesto

Agile methodologies are driven by the Agile Manifesto (www.agilemanifesto.org).  Below is Requirement Experts’ (RE) interpretation of the basic tenants of the manifesto in terms of how requirements should be part of the methodology.

1. We value individuals and interactions over processes and tools.  [RE – involvement of the stakeholders in all the product lifecycle phases is key to project success.   Processes and tools are no substitute for good systems engineering and project management practices that involve good communications with all stakeholders, not just the customer or user. ]
2. Our highest priority is to satisfy our customer through early and continuous delivery of valuable software. [RE – stakeholder expectations need to be clearly understood from the beginning and drive all project activities.  Requirements are how we communicate stakeholder expectations to the designers/developers.  “Valuable software” means  software that fulfills the stakeholder expectations as documented in the Need, goals,  objectives (NGOs), and scenarios for a given problem or opportunity within the context of the stated drivers and constraints.]
3. Working software is the primary measure of progress.  [RE – “working software” means software that has been verified (meets requirements) and validated (meets its intended purpose (NGOs) in its operational environment.  For those that don’t understand these concepts or fail to do verification and validation, how do they intend to measure project success?]

“Agile systems engineering and project management is about ensuring the right information is available to the development team in the right level of detail at the right time so they can build the right product.”  It is knowledge based and is fundamental to the best practices advocated by ArgonDigital and what we teach in our classes – define scope and stakeholder expectations and define all drivers and constraints and interfaces up front.  Communicate this information to the developers via  explicitly stated requirements to capture both explicitly and implicitly stated expectations from not just the customer and users but all stakeholders involved in the product development.

In conclusion, successful application of Agile approaches depend on those that advocate an Agile approach understand:

1. The type of projects agile works and doesn’t work – one size doesn’t fit all
2. The importance of requirements to a project’s success.
3. The importance of following best practices.  INCOSE, PMI, IIBA, and CMMI all acknowledge the applicability of  Agile methods to certain types of projects  within the context of their defined best practices and resulting processes.

Since writing this blog, I have written other blogs concerning agile as a method for developing products:

1. Agile and Requirement–Driven Product Development
2. Managing Interfaces in an Agile Development Environment
3. The Lean, Agile Project Manager

I also wrote a blog on the concept of “Agile Systems” you may find interesting.