Smarter ideas worth writing about.

Making the Shift: How Agile Analysis Works

Recently, there have been some industry blogs considering the role of business analysis in Agile software development.   Is analysis still needed when a business shifts from a traditional Waterfall approach to an Agile environment?  

Well, of course some analysis is still needed.  “Ready, Fire, Aim” is not a good strategy, in Agile or any other business endeavor.  If a business entity blindly charges ahead with a new project without considering how it relates to existing products or to the rest of the business environment, the likelihood of making horrible mistakes will increase sharply – even if the core idea of the project is a good one.

What IS different between Waterfall and Agile methodologies is the timing of analysis.  In a Waterfall methodology, all the analysis proceeds before any software is developed, while in an Agile methodology, the effort is distributed over the development lifecycle.  

In Waterfall, when the initial product idea is considered, an analysis is made of several factors to determine whether or not to proceed with it:  What market needs would the product address?  Who would buy it?  At what price?  How much would it cost to make it (or buy it) and sell it?  Would it be competitive with other offerings in the market?  What would be the impact on other parts of the organization?  

Once the business decides to go ahead with the product, more extensive analysis defines more exactly the functionality desired and the constraints under which it must operate.  What will the product or feature do?  How many different things will it do?  For whom?  What happens if something goes wrong while it is doing that? When will it be used?  In what sort of environment?  Are there hardware limitations?  Network requirements?  Etc.  All of these questions are answered, in detail, for all scenarios before the product is developed.  Sometimes a Waterfall approach encourages ‘paralysis by analysis,' when the analyst and stakeholders spend much more time and effort than is needed in considering every possible aspect of the product. 

An Agile approach seeks to shrink the time needed to go from idea to completed software, enabling the business to respond nimbly to changes in business priorities and environment, to limit the functionality being developed to only what is most valuable to the organization, and to reduce some of the waste which can attend Waterfall projects.  

In an Agile methodology, most of the analysis is postponed until immediately before its results are needed for development. The initial cost-benefit, market, and business environment analyses still must be done upfront as the business evaluates whether or not to proceed with the product or feature.  This high-level analysis is very similar to that done for a Waterfall project.

The big difference occurs when the details of functionality are being defined.  Instead of analyzing all aspects of the functionality up-front, an analyst (who may be any of a number of different roles) under Agile methodology takes each piece of functionality, in priority order, and defines its details just before – and sometimes during – the time the development team takes on the task of building it.  As the Agile team picks up each bit of development, it conducts some more light-weight analysis (possibly verbally instead of in writing) to provide context for the development:  how does this story fit into the feature as a whole, what are the pros and cons of each of the possible technical solutions, who else will be impacted by what this team builds, etc.  

It is true that a more Agile approach does sometimes result in re-work as new information shows the previous solution to be sub-optimal.  But the cost of this re-work is usually more than off-set by other savings.  With an Agile approach, the business can release part of the functionality at any point at which it makes business sense to do so, and less-important functionality can follow at a later time.  This saves cost in three ways:  

  1. It shrinks the time period between the analysis and the development of the product, thereby reducing the corresponding risk that circumstances will materially change during that time period.  
  2. It allows the business to gain experience from releasing part of the functionality and to use that knowledge to help define the details of other functionality.  
  3. And, if some aspect of the product is of sufficiently low priority (or becomes outdated), the business may never need to define or build it.  

None of these cost-savings would be available under a Waterfall methodology.

Basically, the Agile business needs to “play heads-up ball.”  Heads-down, blind completion of the story is not the point of Agile methodologies, any more than it was the point of Waterfall ones.  We always want intelligent, context-aware software development.  Agile just focuses and ‘chunks’ that effort into discrete time-boxes spread over time, and loosens up the roles of who does what.  Instead of doing all the analysis up-front, and having only the business analysts and the architects do it, Agile allows some of it to be done by any member of the team just before or during development, as more becomes known about both the business and the technical aspects of the feature.  Or, to put it another way, the ‘what’ of analysis doesn’t change once the ‘how’ and ‘when’ shift to an Agile timetable.


About The Author

Business Analyst and Scrum Master
Nan is a Senior Consultant in Cardinal’s Cincinnati office, working as a business analyst and scrum master.  She has worked in an agile environment for the last 7 years and loves collaborating to provide top-quality products that meet the customer’s needs.