Requirements in Agile Environments

While much of the IT industry has adopted Lean and Agile methods, there is still strong resistance in some organizations.  Often, the first concerns you’ll hear regard the lack of requirements documentation.

How can a development team possibly do their work without detailed requirements?  Aren’t we wasting time by building the wrong thing?  Here’s my response.

Requirements are the new bottleneck

Coding used to be a slow and laborious task.   From punch cards and $1000 CPU cycles straight through to the early days of web development, coding time was the critical item for project managers to watch and tune.

Waterfall processes were built to accommodate this. The business did a lot of up front work in order to streamline things for IT, trying to ensure things were coded only once.  Luckily, the requirements work was relatively minimal back then.  It’s easy to spec out a UI that’s green and uses the F-keys.

Modern software development is different.  The tools available to developers are very advanced.  Free, high-quality frameworks solve all the common problems, like securing the system, accessing data and drawing the UI.  A skilled developer can assemble the necessary underlying tools in just a few days, and be ready and waiting for business requirements.

And that’s the rub.  Today, developers spend a lot of time waiting for business requirements.  The hardest part of modern software development is not technical.  It’s making the business decisions that drive the projects.  It’s choosing between the myriad ways of doing something, on the look-and-feel and the “experience” you want the user to have.  These subjective decisions are very difficult to make.  

For projects to be successful, we must tune our process for this new problem.  It is time to make IT do extra work in order to streamline things for the business.

What is Agile?

Agile defines a project’s scope as a sequence of small, discreet features.  This is a running list – a wish list.  It can change at any time.  It is prioritized, but not very detailed, and the team works on the items in order.  With Scrum, this is typically done in two-week time blocks.  

Prior to beginning an item on the wish list, the team discusses it with the business to understand their requirements.  Those requirements are often high-level, and to implement them, developers will have to ask questions of the business along the way and probably make some decisions on their own. 

When a developer completes a feature, it is tested within the IT team for simple defects, demoed to the business and put into their hands for testing.  The business can then think about whether the solution will meet their needs.  Any desired changes are put onto the wish list, and prioritized against the other features the business wants.

This flexible requirements management process is combined with a very disciplined set of software development processes, keeping the IT group running like a well-oiled machine, ready to handle whatever comes next. 

How does this solve the requirements problem?

Working in short intervals minimizes the decisions to be made at any given time.  It starts the process rolling, and allows it to gain steam.  The business sees the system taking shape in front of them, can react to it, and build their future decisions on top of it. 

Often more important, though, is the way agile process frees the business from analysis-paralysis.  Knowing it’s okay to make a mistake – that it can be corrected – allows them to start making decisions and moving forward.

What stops them from making changes forever?

In Agile, the business is responsible for the timeline.  They are the ones who want the system in production, and at each step, they are deciding if it truly needs another change to get there.  As soon as it is better than what they have today, they will want it released, regardless of whether every feature on the wish list is in.

Why does this cause more work for IT?

With Agile processes, IT makes a conscious decision to move forward with development while some requirements are missing and others are not fully fleshed out.  This means developers have to do extra work to devise a solution.  It also means the solution may not be exactly right.  When the business sees it, they may poke holes in it, and it may require rework.  Remember, though - it is infinitely easier for the business to identify a solution by poking holes in one that exists than by devising it from scratch.  We accept the resulting rework as a necessary evil to making our projects successful. 

And on the bright side, rework is not always required.  Sometimes IT hits the nail on the head.  You’ll find that as a project progresses, the team gels, the pace picks up and this happens more and more often.  

Is there still a role for Business Analysts?

If we’re trying to solve a requirements problem, getting rid of the business analysts doesn’t make much sense – but changing their role does. 

In the old world, the business analyst’s customer was IT.  Architects and developers were the target audience of their documents.  They shielded IT from the business in order to save developers the time of going to meetings.

In Agile, the BA must change to work for the business, helping facilitate their decision-making process.  The mythical Product Owner who single-handedly directs all aspects of an enterprise application does not exist.  The BA must assist this person, performing market research, creating mockups, analyzing data, coordinating external requests, testing the system, tracking demo feedback, etc.  The business analyst is part of the team – like the Product Owner – but has a different set of skills than the developers (see our Agile BA page for more information).  These skills are necessary on large projects.

Conclusion, or TL;DR

Agile methods align software development to the business, creating the simplest way to imagine, define and convey requirements for today’s innovative and complex applications.

Related Links: 
http://www.nvisia.com/insights/topic/requirements-management 
http://www.nvisia.com/landing/agile-business-analyst