If an organisation wants to manage change effectively, Debra Paul and Lynda Girvan explain, it must invest in and support the business analysis function.

Agile and Business Analysis Book CoverThe increasing popularity of agile methods has had a profound impact on the information systems (IS) industry. Whether you embrace agile or are keen to point out the flaws, there is no denying the impact it has had on software development. And this impact is all too relevant in today’s fast-moving business environments and increasingly competitive markets.

However, the agile focus on software development raises the risk of misalignment between the delivered software and the desired business outcomes, taking the industry back to a time when the focus was on the technology rather than the business operations it was required to support. In addition, opportunities to apply agile thinking within the wider enterprise context may be overlooked resulting in a failure to exploit the value agile principles can offer. This is where business analysis can be extremely helpful.

Analysis involves thinking. It sounds pretty straightforward but in practice this is rarely the case. Analysts have to dig for information and facts, they have to uncover links and trends, they have to evaluate data. Consequently, analysts are able to solve problems and support decision making.

In the business world, ambiguity is ever-present and few problems are straight forward; as a result, analysis is not just required, it is essential. It is not as simple as asking your business representative what they want and then providing it. Sometimes there are other alternatives and sometimes what is requested will not help resolve the problem. Analysis is needed to make sure misjudged decisions are not made.

The potent combination of business analysis and agile offers a means of addressing the gap between agile software development and the agile enterprise. This article discusses three areas where this gap may be addressed.

Gap 1: analysis in agile development

Given that agile development has a software development focus, many of the agile methods and approaches, such as Scrum, fail to identify a business analyst role. This is not to say that analysis is not required, rather that the agile team should possess all the skills necessary to deliver the required software - and this includes analytical skills.

Unfortunately, there is a risk here in that agile teams may not appreciate the need for analysis, or may not have the required analytical skills, and this can result in a gap between the requirements and the system. Even worse, the delivered software may not help achieve the beneficial business outcomes, for example, because incorrect assumptions have been made, relevant information has been missed or business rules have not been understood.

This could be attributed to a lack of understanding, or even lack of experience, regarding the need for business analysis skills. For many agile teams the Product Owner (PO) is the go-to person who can answer any business-related questions but knowledge of the business is not the same as the ability to analyse the business.

In many situations, the PO may not have the skills (or possibly the time) to conduct analysis activities and ensure that the proposed solution is in line with the required business outcomes. Specialist business analysis skills may be needed within some project teams - particularly where the requirements are complex. In such cases, it is vital that the team engages someone with those skills.

Gap 2: analysing for outcomes

Every IS project you encounter will be a ‘change’ project. This means that the project should deliver changes that deliver beneficial outcomes for the business. Although the agile manifesto focuses on software, an agile approach should encompass broader aspects such as processes, policies or skills in addition to automation. In some situations, enhancing existing software or developing new IT applications within short timescales may be sufficient to respond to an environmental change or resolve an urgent problem.

In other situations, a changed process or additional workaround can suffice. Sometimes, a whole raft of changes are needed. The key thing is to understand the required outcomes and be sufficiently adaptable to identify the options available. You are then in a position to help the business decide on the best way forward given the specific circumstances. This is the essence of agility.

An outcome-focused approach needs business analysis in order to determine the changes required to achieve the business benefits. Taking an analytical, holistic view is invaluable as to think through all of the relevant aspects, identify the various areas for change and the timing for their deployment.

Gap 3: analysing the enterprise

A fundamental principle of business analysis is to help ensure organisations understand the nature of the business problems to be resolved, evaluate options and invest funds appropriately. The focus on beneficial business outcomes should move beyond software into the sphere of the enterprise.

Organisational agility is all about responsiveness. If business advantage is to be gained, organisations need to be adaptable and able to respond to environmental pressures within challenging time frames. Achieving this can be very difficult as it requires the organisation to be open to change, accepting that a timely interim solution may leverage the benefits that await.

This may mean that there isn’t time to develop a fully-functioning software solution or define an all-encompassing work system that covers all of the POPIT™ elements. The agile enterprise is predisposed to aligning strategic goals with executable tactics and operational work practices. An agile analytical approach helps ensure that enterprise analysis means that necessary change is delivered exactly when it is required. Anything more is superfluous and wastes time.

Summary: the agile analyst

Recognition of the importance of business analysis has been growing over the last 25 years. The scope and focus of the role has been debated at length. Does it overlap with systems analysis? Are business process analysts specialist business analysts or do they fulfil a separate role? How does business analysis relate to strategic analysis?

Ultimately, business analysis is all about helping businesses to invest in changes that will be beneficial, whether these are intended to improve efficiency, ensure compliance, grasp business opportunities or offer new services to keep up with the competition. The advent of agile adds a new dimension and momentum to business analysis. It highlights the need to prioritise, to focus on goals, and to avoid waste. The agile analyst knows the difference between work that adds value and wasted effort - at all levels of the enterprise.

The BCS International Diploma in Business Analysis established the fundamental toolkit that any business analyst should possess. This toolkit has been adopted by numerous organisations since its launch in 1999. Extending this toolkit to become an agile analyst requires you to understand and apply the agile philosophy, principles and values in the Agile Manifesto. And there is always more to learn!

The agile analyst also needs to have business acumen and should understand the environment that surrounds and influences the enterprise. As mentioned earlier, analysis is about thinking so you need to use your thinking prowess if you are to contribute effectively to the situations described earlier. This is another string to the bow of the agile analyst - the ability to apply business thinking approaches such as systems thinking, service thinking and lean thinking.

In our ever-changing uncertain world, thinking before acting is becoming increasingly important. Spending investment funds wisely should be a given. Agile business analysis can offer essential services to meet these needs but this requires recognition and action by change sponsors and managers, and skills and application by business analysts. Take a look at your organisation, is it realising the potential of agile by addressing the analysis gap?