Agile Requirements Engineering – Success Factors for Implementing Agile Methods

Think requirements specifications and functional specifications are too cumbersome and boring? You’re in luck! Agility’s the latest buzzword. Projects need to be implemented quickly. As a result, agile methods are what everyone’s talking about, and are being used for all stages of a project, from eliciting requirements to implementation. We’ve identified six success factors for using agile methods in requirements engineering and project implementation.

Agile methods are enjoying greater and greater popularity these days. Innovative digitalization projects require flexibility, not only in implementation but also when it comes to requirements, and projects that need to meet the challenge of ensuring agility in requirements elicitation and clarification readily rely on agile requirements engineering techniques.

What’s Agile Requirements Engineering?

The preferred agile methods for gathering and managing requirements over the course of an agile requirements engineering process include:

Workshops
Specifying results by means of user stories, epics, technical stories, etc.
Backlogs and kanban boards for managing requirements over the course of implementation and are provided either physically (central boards) or electronically (in tools like Jira, etc.)

Success Factors for Agile Requirements Engineering

These methods are relevant and essential, and their use leads to outstanding results in many projects – although they’ve also resulted in major problems for many other projects. Viewpoints on this subject can be quite extreme – some organizations invoke agility as the magic word that will solve everything, while others have had a number of bad experiences and have virtually forbidden use of the word in connection with projects.

Agility isn’t just a technique, it’s also a management philosophy when it comes to projects and businesses. Our experience shows that success doesn’t come from just making use of processes and techniques – there are success factors which are much more fundamental.
Wolfgang Hiermann, CEO and agile coach

Based on our experience in project management and consulting, the following six items have emerged as success factors in this area:

Product leaders, not product owners
Actually carry out short feedback cycles
Developers enthusiastic about the product
Expedition-friendly organization
Openness and transparency
Keep development close to the chest

These factors are the pieces in the puzzle for ensuring the success of agile requirements engineering and agile projects, and when they work in combination, they result in a functional whole through which agile methods and techniques can be used meaningfully.

Success Factor 1: Product Leaders, not Product Owners

Agility means flexibility, and flexibility is sustained by the willingness and ability of stakeholders to question goals (in particular usage goals), adapt decisions and change priorities. However, what’s most important is that stakeholders are enthusiastic about the product, and actively seek to shape it.

As a result, successful agile projects have not so much a need for a product owner who’s strictly administrative, (which unfortunately is often the case), but rather a group of product leaders who work in close collaboration and, as stakeholders, drive the project forward with foresight and energy.

Success Factor 2: Actually Carry Out Short Feedback Cycles

Unfortunately, many agile projects fail exactly because interaction between stakeholders and the agile team is reduced to a minimum after the initial workshop. To implement agile projects successfully, it’s not enough just to describe requirements by means of user stories and to manage them in backlogs.

Short sprints actually need to be carried out, a tangible result must exist by the end of each sprint and most important, the most relevant requirement stakeholders need to actually see that result, work with it and if necessary revise requirements and goals.

Success Factor 3: Developers Enthusiastic about the Product

Unfortunately, developer participation is often neglected for fear of goldplating. Yet, the reality is quite the opposite – enthusiastic developers don’t want to program something that nobody’s going to use, they want to witness users who love using their product, and even hear a sincere “thank you” for their efforts every now and then.

This is because agile flexibility in development is difficult if developers can’t form a true attachment to the result. A highly successful implementation of requirements and technology will be achieved only if developers are convinced of the product’s benefits and have the opportunity to actively take part in shaping requirements.

Success Factor 4: Expedition-Friendly Organization

“Changes are stressful. Nothing ever improved through changes. We’ll first wait to see what we’re up against, then we’ll deal with it.” – If that’s the client organization’s philosophy toward life, then the team members of an agile project will feel like extraterrestrials just before landing, and the potential for frustration in the project will be great.

That’s because the saying “In for a penny, in for a pound” applies when it comes to agile requirements engineering. Stakeholders and organizations who aren’t completely enthusiastic about the agile approach would be better off not to bother at all and to make use of more conservative methods – also meaning they’ll need to make do without the advantages of flexible development.

Success Factor 5: Openness and Transparency

“It’s not clear why we’re doing this job like this. We’ve always done it that way, so we need to keep doing it that way in the future.” Of course, you’ve heard statements like that. Sometimes questioning a process is perceived as being presumptuous, or even insulting. Many questions should only be asked in the right context, or sometimes even not at all. And all too often recommendations first need to be reconciled and decisions prepared in a small group of people before they can be discussed openly with all stakeholders.

The famous statement by Peter Druckers applies here: “Culture eats strategy for breakfast.” And this is the point at which agility (and in turn project democracy) dies. Effective agility requires open cooperation and mutual respect.

Success Factor 6: Keep Development Close to the Chest

It’s true – you can outsource even agile development. However, the greater the distance, the higher the effort and expense will be for agile project management and communication. Although the continual improvement of resources for videoconferencing and the live processing of documents are making work greatly easier, they’re no replacement for paths of communication which are truly short.

As a result, agile projects greatly prefer the use of nearshoring over offshoring. Nevertheless, top efficiency and effectiveness in agile projects is achieved by keeping distances between stakeholders and the development team as small as possible. Onshoring agile projects, or sometimes even better onboarding the agile team for the duration of the project, are successful methods in this regard.

Bottom Line: Culture and Know-how

If you take a look at these six success factors, you’ll see they have a lot to do with corporate culture and building up internal know-how. Making use of agility in requirements engineering and in projects requires both time as well as knowledge of agile methods. Project members must have a thorough know-how of the product as well as solid basic technical understanding.

This means that building up these skills within a team is an essential step for any organization moving in an agile direction, and we at Spirit in Projects, through our training and consulting, can provide you the support you need to establish agility in your organization as well.