This chapter covers the following topics:

INTRODUCTION

All businesses have to be on constant alert for changes that may cause problems or offer opportunities for them. These changes may originate from industry factors such as competitor actions, or may involve broader developments such as demographic or technology changes. In addition to these external forces, there can also be internal drivers for change including new ideas raised by executive managers. While some drivers for change are highly visible, others can be very subtle and easy to overlook so identifying change drivers may not be straightforward. However, making the changes happen is often where the real challenge begins.

For several decades, change has been enabled by technological developments and has involved the introduction of new or enhanced software products. Initially, changes to software were seen as sufficient and the broader context into which the new software was to be released tended to be overlooked; the computer system was seen as offering sufficient new features to generate the efficiencies and improvements needed by the business. This approach began to change in the late 1980s when greater awareness of the need to ensure that new software was accompanied by the relevant changes to processes and jobs came to the fore.

Challenges have persisted, though, and the intervening decades have continued to be marked by highly publicised information systems (IS) project failures. As a result, there have been many initiatives to introduce methods and techniques that will improve the quality of the delivered change solution including structured analysis methods, the Unified Modelling Language (UML), systems thinking and business process re-engineering. There have also been attempts to move away from the more traditional, linear methods for systems development and business change projects. Instead, there has been an increasing adoption of iterative and incremental development approaches that offer a greater emphasis on ‘just in time’ delivery; these approaches align with, and have contributed to, the development of the agile philosophy.

The last few years have been marked by the widespread adoption of agile methods within the IS industry. This may be seen as a response to the traditional and structured software development methods, which have been challenged as not meeting the needs of today’s fast-moving business environments. While the original agile philosophy was focused upon the development of software, it has become apparent that software development projects need to ensure that they are ‘business relevant’ if they are to support the activities conducted to perform the business work. To do this, the application of agile principles needs to move beyond software to encompass the entire business system if benefits are to accrue for organisations.

Three particular issues have been identified:

Consequently, we feel that the valuable ideas that have been developed within the agile domain should be explored within the context of delivering business outcomes rather than software products. The role of the business analyst, with its focus on defining the problem to be solved and evaluating the options to do this, needs to be considered within this context. Accordingly, this book examines agile work practices through the business and business analysis lenses, discussing the use of agile methods and techniques within a business context and the role of the business analyst in conducting this work.

THE RATIONALE FOR BUSINESS ANALYSIS

It is instructive to consider why we need business analysis within IS projects. Business analysis originally developed as a discipline responsible for analysing requirements where the analysis activity was firmly located within the organisational context and analysts were familiar with the jargon, rules, standard practices and business processes of that context. Although systems analysis had been a key activity within the IT systems development process for many years, problems had arisen because of an identified lack of understanding on the part of the systems analysts about the broader context beyond the IT system. There were criticisms that systems analysts focused solely on specifying the system requirements and failed to consider what the organisation actually needed. For example, sometimes the organisation needed business system – rather than solely IT system – change, but this was not within the remit of the systems analyst. Accordingly, the broader role of the business analyst emerged, which had both a business and system focus, and approaches such as requirements engineering were developed to ensure that both business and solution requirements were identified, prioritised and delivered.

The maturation of business analysis

The increasing maturity of business analysis over the last two decades gave rise to the creation of the BA maturity model in Figure 1.1. This model captures the trajectory of the development of the business analyst role as the scope of the role expanded and business analysts gained in authority.

Figure 1.1 Business Analysis Maturity Model™

The three levels shown capture the different flavours of the business analyst role as follows:

Many change programmes and projects begin with an idea or initiative. This idea is formalised by the programme initiation, which includes a definition of the objectives, deliverables and timescale. However, sometimes, the idea is weak and may offer limited benefits, or may not improve the organisation at all. A typical example involves the purchase of a software package (or possibly an enterprise-wide suite of software packages) because it is felt that this will deliver benefit to the organisation. Without any analysis of the problem to be solved and the options available to the organisation, there is a high risk that the desired business outcomes will not be achieved and the project will fail. In the worst case, such an initiative could absorb a lot of (wasted) money and possibly cause damage to the organisation.

The maturation of business analysis has led to an increasing recognition that an initiating idea needs to be investigated to ensure that the genuine problem is addressed, and the available options are identified and evaluated before setting off down a path of no return. Business analysts have a toolkit of techniques and approaches that help them to analyse often vague and ambiguous business situations such as, ‘we need to be more efficient’, ‘the processes are a bit clunky’, ‘we have to improve our capability’. Therefore, they are well placed to take on the work of uncovering the root causes of problems and clarifying the issues to be resolved. One of the key aspects of business analysis involves recognising that there are different perspectives on any business situation and without the development of a shared understanding and consensus view, it is going to be difficult to find a solution that will be acceptable to the key stakeholders. Business analysis also takes a holistic view, ensuring that all aspects of the business situation are considered during investigation and solution definition. The IT system may be at the heart of the solution, enabling the business improvement, but without consideration of the people, their processes, work practices and information needs – and the organisational structure and culture – the solution will not deliver the promised benefits.

The business analysis landscape

In recent years, business analysis has become a broad discipline with professional business analysts working in advisory roles helping to ensure that IS investment funds are spent wisely. A good definition of the role of the business analyst has been defined by the UK Department for Work and Pensions:

The range of activities required to conduct business analysis is shown in Figure 1.2. These activities focus on ensuring that the problem situation is understood before moving towards the desired outcomes. They emphasise the need to analyse the business needs and to evaluate the range of potential options, before defining the detailed requirements for change. While the model shows the overall direction of the work, it does not dictate a strict linear sequence. In practice, there will be iterations between and within many of the activities.

Figure 1.2 Business analysis activities

Source: Paul et al. (2014)

Business analysts need an extensive toolkit of skills and techniques if they are to carry out these activities effectively. Adding the agile approaches and techniques to this toolkit will help business analysts to conduct these activities more effectively and support the delivery of timely, effective solutions. It is important to recognise that this is not only within an organisation that has adopted agile software development; some of the agile tools, for example, MoSCoW prioritisation (see Chapter 9) can be extremely useful in a range of situations.

BUSINESS AGILITY

The term ‘business agility’ is often used these days. All businesses recognise that they need business agility but there are two questions we need to consider; ‘What is business agility?’ and ‘How is it achieved?’

Let’s look at the first question: ‘What is business agility?’ It is the ability of an organisation to be responsive to forces within the business environment and to be adaptable when change is required. Agile organisations are able to act when the environment changes and are able to adopt new ideas. They have flat structures, with processes and systems that embrace change. Their cultures are open and adaptable, their people empowered and flexible.

Systems thinking incorporates the concept of self-regulating business systems that can monitor the business environment through feedback loops and adapt to the changes encountered. To do this, the business system – or department, division or even entire organisation – needs to understand the rationale for its existence. Why does it do what it does? What are its values? Simon Sinek (2011) expounded the importance of understanding why an organisation exists before exploring the what and the how of the organisation’s operations. This is at the core of the organisation with business agility. If the staff need to constantly ask how they should respond to situations or have to request approval for everyday decisions, the organisation is not displaying agility – it is as simple as that.

How then is business agility achieved? To return to Sinek, it has to start with a clear understanding of the underlying rationale and values of the organisation. This should drive how the organisation operates and should provide the employees with a basis for decision-making. Empowerment should be embedded within the organisational culture and should be observable at all levels. Processes should not involve tasks with a primary focus on ‘ticking the box’ – the work should have a real purpose and, fundamentally, that should be concerned with delivering the organisation’s products or services in line with meeting the needs of customers. The customers should be at the heart of the agile organisation. This is not always the case, however. For example, one of the most disliked innovations in recent years has been the introduction of the self-checkout in supermarkets. However, as most customers welcome anything that makes it quicker and easier to pay for goods, why is this the case? A brief foray into the ‘bagging area’ soon provides the answer. The systems are set up to meet the needs of the organisation rather than the customers. As a result, at any moment, the system could lock up and demand the attendance of a store employee, whether because the customer was too slow putting a scanned item into the aforementioned bagging area or, even worse, putting the item in a bag that is being carried rather than in the designated bagging area.

Some organisations focus on defined targets such as those encapsulated in their service level agreements (SLAs) and believe that ‘fulfilling the SLA’ is sufficient to ensure good customer service, even if this has just involved sending an email during the designated time period to confirm that the situation is still under investigation. Continually calling to say that no action has been taken is of no use to a customer, even if the internal communication target can be ticked as achieved!

How can the agile approach help with business agility? If we apply the agile philosophy as a basis and understand the nature of adaptable business systems and the realisation of value from service, we have a basis for developing business agility. Business analysts who understand Lean, systems and service (Chapter 3) and adopt the core agile values (Chapter 4) will be able to support their organisations better, as they can introduce relevant techniques and philosophies into their business change work.

THE AGILE BUSINESS ANALYST

There are two distinct aspects where the agile approach is relevant to business analysis:

Let’s look at these in more detail.

Business analysis enabling business agility

The underlying premise of several philosophies – agile, lean thinking, systems thinking, service thinking to name a few – is that any business system or process has an underlying rationale for its existence. In other words, we need to be able to state the reason why the system exists. Understanding the underlying rationale enables us to determine what needs to be in place to make the business work more effectively. These philosophies are covered in Chapter 3 of this book; understanding and applying them is key to being an agile business analyst.

It has been said (by one of the authors!) on numerous occasions that the role of the business analyst should be the most agile of the business improvement roles. This is because business analysis can apply the agile philosophy and techniques in a number of contexts or situations:

The adoption of an agile mindset, when undertaking business analysis, helps to generate business agility within an organisation. Agile business analysts should understand why the use of agile is of benefit, what agile work practices are available and how they should be used. They also need to extend their toolkit to encompass agile approaches and techniques.

Agile business analysts should support business agility both before the inception of a programme of change and during a change project, helping to ensure that change initiatives are focused on meeting the needs of the organisation and delivering the desired outcomes.

Business analysis on agile software projects

Several agile software development methods have emerged since the late 1980s, including Rapid Application Development, Dynamic Systems Development Method (DSDM), Extreme Programming, Scrum and Disciplined Agile 2.0. These methods and more are discussed in Chapter 5. However, one of the factors common to these methods is that they do not recognise the business analyst role. So, does this mean that the use of agile methods removes the need for business analysis? To answer that question, let’s revisit why business analysis was originally developed. It was to address an issue that had afflicted systems analysis – the communication gap that existed between technical and business staff. That’s not to say that all systems analysts had communication problems, but it was an issue that business staff often complained about. And so the concept of a more business-focused analyst role was created.

The agile principles, discussed in Chapter 2, include a principle that identifies the importance of a face-to-face conversation between a developer and a business user when uncovering requirements. Highlighting the importance of a conversation to clarify requirements means that business analysis is needed, even if the work is done by someone with a different job title.

Within agile teams, the concept of a generalising specialist (discussed in Chapter 7) is often used where an individual may possess cross-functional skills in addition to the area within which they specialise, and utilise these skills at the point that they are needed. This would seem to imply that the developer may take on the business analyst role – which is fine as long as they have the requisite business analysis skills, knowledge and attitude, and provided the conversation is at an individual project team level and not spanning multiple business areas.

Is this the best way to do this though? Business analysts have extensive toolkits of techniques and approaches that they have often developed over several years; this is also the case for other roles within software development such as developers, testers and so on. Therefore, in practice, the answer is ‘it depends’. Often, it is useful for a developer to analyse the information being provided by the business user as part of a conversation. However, where there are more extensive business analysis activities to be conducted – such as determining business requirements or developing business models – then greater skills may be needed and a specialist business analyst will probably provide a more efficient and accurate service.

THE AGILE BUSINESS ANALYSIS BOOK

This book was written with three aims in mind:

To achieve these aims, we decided that we needed to ensure that agile was presented clearly for a business analysis audience and that the links to business change projects were clarified. As a result, this book covers a wide range of topics that are included in order to support business analysts as they work on projects using agile and deliver skills that will enable their organisations to work with agility. The chapter breakdown is set out in Table 1.1 below.

Table 1.1 Structure of this book

The range of topics covered in this book is extensive and includes the agile philosophy, and the popular agile methods and techniques, viewed through a business analysis lens. These topics are intended to provide business analysts with a toolkit that will enable them to contribute effectively to agile projects and enhance the agility of their organisations.

REFERENCES

Paul, D., Cadle, J. and Yeates, D. (2014) Business analysis: 3rd edition. Swindon: BCS.

Sinek, S. (2011) Start with why: how great leaders inspire everyone to take action. London: Penguin.