This chapter covers the following topics:

INTRODUCTION

Agile is usually mentioned and applied within the context of software development but the underlying philosophy and principles can – and should – be applied much more widely. However, to do this requires the adoption of a mindset that aligns with the agile philosophy and then for this to be applied to business needs; for some this will require fundamental change in the way they think and behave. Where an agile mindset is applied within an organisation, it will enable greater adaptability and the delivery of business changes that have the potential to bring early benefit to the organisation.

A good example concerns the development of a new product: this may be a new service to be offered, such as a training course, a software application or possibly a physical item such as a piece of furniture. When developing different types of product, many ideas and requirements may be put forward but some of them may not enhance the product at all or may not be worth the expense or delay required to incorporate them. In some situations, there may be requirements that can be deferred. For example, a company may offer an item of furniture in a limited range of fabrics initially, with the intention of extending the range of options at a later point. Similarly, there may be a possibility of providing additional features, such as extra reading materials to extend the learning from a training course, additional software functionality or even extending the geographical area in which a product or service may be offered. Enabling early delivery of an initial version of the product requires the project team to adopt an agile way of thinking, ensuring that the required features are prioritised and recognising that some requirements do not need to be fulfilled at the outset – or even at all.

Some organisations associate agile working practices with the use of a particular method, such as Scrum, or certain techniques, such as user stories, without fully adopting an agile mindset. This can limit the potential of agile and diminish opportunities for achieving business benefits because the use of agile is focused on software development rather than business improvement. While this is the case for many organisations, others are beginning to recognise that it may be applied more broadly and can offer benefits to business change initiatives. This broader, more holistic view, with a focus on business rather than software, opens up the agile landscape and provides an opportunity for further business value to be realised.

This is where business analysts should have a central role, changing the focus from the IT system to more holistic business improvement initiatives that may or may not involve the use of technology. It is important to recognise that we don’t need to use a specific agile method or technique in order to adopt an agile mindset, and that user stories and sprints are not compulsory. It is more important to think and behave in line with the agile philosophy and principles, prioritising ideas and requirements, focusing on the most beneficial aspects and understanding when a particular feature should be delivered.

This chapter explores the evolving role of business analysis in an agile landscape and sets out an Agile Manifesto for business analysts that introduces a new way of thinking.

THE BUSINESS ANALYSIS PERSPECTIVE

The formal responsibilities of the business analyst role are well defined where a linear approach is adopted on a software development project. There are likely to be clear stages covering the pre-project or feasibility study, detailed requirements engineering, business acceptance testing, change implementation and benefits realisation. Each of these stages will require the involvement of business analysts as the project moves through a waterfall or V model life cycle. When a business analyst is working within an agile environment, it is still important to carry out this work but the likelihood is that it will be conducted differently. Essentially, there are three business analysis perspectives that are relevant to an agile change project:

These three roles and perspectives are reflected in Figure 3.1.

The Enterprise BA: pre-project business analysis

New initiatives tend to arise frequently within organisations. This may be because of factors within the external business environment or as a result of new ideas generated by internal stakeholders. Whichever is the case, it is important to assess the feasibility of a proposed project or initiative because it helps to determine three things:

 

Figure 3.1 Three BA perspectives

This work is sometimes called pre-project analysis and requires business analysis involvement to consider the areas shown in Figure 3.2 below.

Too often change projects are initiated that are not well founded. Typical examples are:

 

Figure 3.2 Pre-project analysis work

Early business analysis work is essential if an organisation is to be assured that a proposed investment is well founded and the project is relevant. And, this is the case whether we adopt a linear or agile approach to the work. In a similar vein, Scott Ambler, in his Disciplined Agile Framework, highlights the importance of an Inception phase to determine the basis for a development project, including the need to discuss the vision for the work with stakeholders and assess the feasibility of the proposed project. Ambler and Lines comment

The goals of this stage include clarifying the business problem to be addressed and identifying the approach required to complete the work; the achievement of these goals requires the application of business analysis to the particular situation.

Business analysis skills are essential for the successful conduct of this work. An analytical approach is at the heart of working with stakeholders to define a consensual vision; a feasibility assessment is only possible if a holistic view of the situation is taken and options are analysed.

The recommended solution is likely to require changes to several of the elements shown in the POPIT™ model in Figure 3.3.

The POPIT™ elements are:

 

Figure 3.3 POPIT™ model

Process		The definitions of the processes, how they are communicated to the business staff, the level of IT support, the documentation used when carrying out the processes.
People		The skills of the people, their motivation levels, their awareness of the business objectives they are required to support.
Organisational context		The management structure and governance approach, the definition of job roles and responsibilities, the lines of communication and authority, the working relationships across functional boundaries.
Information and Technology		The information needs for the business, the technology support that delivers the information and supports the processes.

Changes to any combination of the POPIT™ elements will result in a programme of business changes. The holistic view provided by business analysis is necessary to define which changes need to be made. The software development project is typically just one element of a change programme and, as indicated by the interfaces of the POPIT™ model, needs to be aligned with the other areas such as revised processes, working practices and roles. Figure 3.4 reflects the pre-project work that a business analyst working at the enterprise level performs, helping to ensure that the right problem is addressed, the rationale for change is understood, relevant options are evaluated and the solution addresses all of the required POPIT™ elements within the business system.

 

Figure 3.4 Pre-project business analysis

The programme BA: business analysis and the change programme

A change programme is likely to encompass many interrelated and dependent change projects. While the programme manager will be responsible for coordinating the projects, it is the business analyst that ensures that the solution development work continues to focus on the business outcomes. For example, there will be a need for business analysis to ensure the changes are understood and that there is alignment between the different elements. Early delivery of working software alone is unlikely to offer the value anticipated by the organisation; it needs to be accompanied by the other changes that will make the solution holistic and viable.

However, where an agile approach is to be applied to a change project, any business analysts working on the broader business changes can apply the agile philosophy and principles (set out in Chapter 2) to all aspects of the programme. For example, by:

When working at the programme level, the business analyst is required to support key stakeholders in making informed business decisions. This is achieved through the business analyst choosing and applying a wide range of practised analytical techniques that the key stakeholders are often not aware of, or practised in.

The project BA: business analysis within the development team

The work of the software development team requires business analysis work to be conducted if a business-relevant solution is to be delivered. This work is likely to include activities such as stakeholder engagement, process modelling and requirements analysis, all of which may be necessary to ensure that the development work is aligned with the needs of the business. Investigating the rationale for requests made by the business users is one of the key responsibilities of a business analyst and helps to ensure that effort is not wasted developing features that are unlikely to offer benefit to the organisation. While one of the agile principles states that a face-to-face conversation is the most effective means of conveying information within the development team, it does not necessarily follow that this will result in the most useful information being communicated. Sometimes, a conversation with business users that explores the rationale for a suggested requirement is necessary in order to ensure that there is a genuine business need to be addressed. Similarly, many business analysts have encountered the situation where a proposed ‘requirement’ is actually a perceived solution, which requires further investigation in order to explore the possibilities that improved processes or technology might be able to offer if the underlying requirement is clearly understood and expressed.

While it is the case that business analysis work will be required within the development team, does this mean that a designated business analyst is needed? It is possible that other members of the development team may take on some of the business analysis work and act as proxy business analysts. However, care needs to be taken to ensure that business analysis skills are available within the team in order to avoid problems. For example, without skilled business analysis, there can be a tendency for all customer suggestions to be accepted at face value and assumed to be necessary, regardless of whether they align with the needs of the business. The history of information systems projects demonstrates that incorporating stated requirements without considering the underlying rationale can be a recipe for a lot of unnecessary work. The application of business analysis skills helps to ensure that solutions align with business needs, uncovers tacit knowledge and confirms that investment funds are spent wisely. Achieving this requires a range of business analysis skills and experience in applying business analysis techniques. Assuming that these are readily provided by professionals from other disciplines is at best naïve and, at worst, highly risky.

Business analysts bring a unique skill set to agile development teams. They are able to look beyond stated requirements to challenge assertions, consider wider impacts and evaluate proposed solutions. They have the skills to engage with a range of stakeholders and have knowledge of the business domain, and this helps to facilitate collaboration with both customers and developer colleagues.

AGILE MANIFESTO FOR BUSINESS ANALYSTS

While the original Agile Manifesto stated which aspects of software development work were of a higher priority, the statements need to be updated if there is to be a manifesto for adopting agile within a business analysis context. While working software is important in the business analysis domain, it is rarely the entire solution and sometimes software is not required at all. Additionally, while working software is of value, it is the outcome or improved experience produced by the working software that is the domain of business analysts.

The original focus on software is relevant for IT projects but needs to be extended if it is to reflect the holistic nature of business change programmes. There needs to be greater emphasis on improving the entire business system and recognition that the realisation of business benefits results from business changes, not software delivery. Whereas the original Agile Manifesto focused on software development, this is too limited for business analysts who need a modified manifesto that offers a broader view and has the potential to inspire agile business change.

A modified version of the Agile Manifesto, which is intended to work as an extension to the original manifesto, is shown in Figure 3.5 and reflects a business analysis perspective. This version embraces the Agile Manifesto and philosophy, but also encapsulates a world view that is relevant to business analysis and the broader business change context.

 

Figure 3.5 An Agile Manifesto for business improvement

The modifications shown in Figure 3.5 reflect the way in which the agile philosophy is now applied within business contexts. It emphasises that an IT system is not as important as ensuring that there is a holistic solution. It also reflects the widely held view that adherence to a method or approach is less relevant in today’s business world than adapting the tools to the situation.

However, this requires broader thinking and a focus on business needs and improvement. It also requires a good understanding of prioritisation approaches (see Chapter 9) to ensure that the features that will contribute to the delivery of early benefits are identified. In short, it needs the involvement of specialists who can marry the business requirements with the solution development work – the business analysts.

AGILE BUSINESS THINKING

There are several schools of thought that are beneficial to anyone working to improve how organisations operate. Different ways of thinking are required if we are to focus on delivering outcomes with the potential to offer value to the customer. Three philosophical schools of thought are helpful when conducting business analysis within an agile environment:

These approaches offer relevant insights that have the potential to enhance the business analysis work and thereby enrich the business outcomes.

Systems thinking

Systems thinking offers an approach to viewing an organisation and its component areas as a hierarchy of business systems. A great deal of research has been conducted into the different aspects and applications of systems thinking. One particularly relevant development is the Soft Systems Methodology (SSM), which was defined by Checkland in 1981. Although much of this research was conducted several decades ago, systems thinking and the SSM are extremely useful in today’s business (and business analysis) world. They ensure that the underlying rationale for a business system is always kept in mind, thus reducing the potential for unnecessary work and keeping a focus on changes that would be beneficial. They also offer a means of viewing business situations holistically and considering the interdependencies between systems and sub-systems. The nature of systems thinking was summarised by Peter Senge in The fifth discipline (2006).

There are three key elements considered within systems thinking:

These elements are summarised in Figure 3.6 below.

 

Figure 3.6 Aspects of systems thinking

These three areas are extremely important to understand when analysing business systems. Let’s look at them individually.

First, they tell us that we need to be cognisant of the underlying rationale – the ‘why’ of a system. This principle is well established in numerous frameworks, including the SSM, Zachman’s Framework and the OMG Business Motivation Model, and helps analysts to understand where the primary focus of the work should be placed. Without understanding the rationale for a system, the analysis work can often be too concerned with the detail of how things are done rather than trying to understand the relevance of the system to the organisation. Exploring the rationale for a system also helps analysts to understand the problem they are attempting to address in order to ensure that the system objectives are achieved. Recognising the rationale for a system is invaluable when adopting agile thinking. If we understand the problem to solve and know why the solution is relevant, we are much more likely to produce something with the potential to offer value to the organisation.

Second, the activities and supporting tools, rules and information. Any system is made up of parts – the elements that make it work – so this is a principle that is very familiar to most analysts. Historically, we have had a separation between the IS practitioners and the rest of the organisation, which has caused the term ‘system’ to become synonymous with ‘IT system’. Systems thinking broadens that understanding and causes analysts to think holistically about business systems and identify how the elements of a system need to work together to deliver the outcomes that align with the system rationale. The application of systems thinking helps analysts to enable organisational agility by ensuring that change releases provide holistic solutions, rather than focusing solely on software.

Third, additional properties emerge from the synthesis of the elements of a system. The car is often used as an example. It is made up of many parts, but only as a whole can it actually move and transport passengers from one location to another. So, the ability to transport those sitting in the car is the emergent property and all of the elements of the car have to be working together in order for this property to be provided. It is also the case that the emergent property may be negative. In the car example, a car’s radiator can overheat if another working part is not functioning correctly. It is vital that business analysts understand that systems have emergent properties and these need to be harnessed if solutions are to be valuable to customers.

It is the responsibility of the business analyst to look beyond stated problems to find the underlying root causes and to define a holistic solution. Systems thinking and the techniques within SSM are invaluable when doing this. They also align with agile thinking, as the focus is on understanding which areas within the business system are of the highest priority and, therefore, where there is the potential for the delivery of benefit at an early stage.

The POPIT™ model, shown above in Figure 3.3, was developed in order to provide a framework for thinking holistically about solutions so is also useful when used with the systems thinking approach. Business analysts can apply the agile philosophy and principles in all of the four dimensions. So, if considering the processes, the business analyst might think about what a process is trying to achieve and the options for improving it. The analyst might identify that a comprehensive solution formed of many changes is possible, but that this would require an extended time frame. If adopting an agile approach, the analyst will work with the business staff to prioritise the potential changes and define a minimal set that will deliver benefit to the organisation without undue delay.

Failing to consider the whole business system when making changes can result in unexpected emergent properties. For example, automating processes in one area of the business could cause problems for processes in another area. Without looking at the business system holistically, and understanding how the individual parts interrelate, it would be impossible to identify the consequences of a change. Unexpected negative impacts will have the potential to undermine the value that the service could offer to the customer.

Lean thinking

The ‘Lean’ approach originated from the Toyota Production System. Its focus is on maximising customer value, while minimising waste in order to create better outcomes for the customer with fewer resources. Lean was essentially a process view of the organisation that involved thinking about the business from a cross-functional point of view. This is sometimes called a ‘horizontal’ view because it represents the set of processes (from different parts of the organisation) that together deliver products or services to customers. This view of the processes is sometimes called a ‘value chain’. Such a view contrasts with the ‘vertical’ view of the organisation, which shows each of the functional areas, such as the customer service department or production facility, operating separately.

The fundamental concept underpinning the Lean approach is that all functions within the business system, or organisation, need to work together to deliver the desired outcome for customers. This desired outcome is usually stated as a value proposition offered by the organisation. Lean thinking focuses on optimising the workflows through the horizontal value stream that exists to deliver the organisation’s value proposition. This horizontal view encompasses people, technologies, assets and departments that collectively enable the business to deliver its products (or services) with the greatest level of efficiency. Improving efficiency should enable organisations to reduce expenditure and increase profit margins.

Womack and Jones (2006) defined five key principles that described the Lean concept. These are shown in Figure 3.7 below.

 

Figure 3.7 Principles of Lean thinking

Ohno (1988) identified seven categories of waste that diminish efficiency in organisations. The seven categories were later extended to include an additional category, the underutilisation of skills, by James Womack and Daniel Jones. These eight categories of waste, are often known as the ‘8 wastes’ and are specific areas where wasted resource and effort may be found in organisations. Therefore, eliminating or reducing the wastes presents opportunities for improving efficiency. The areas of potential waste are summarised in Figure 3.8. They provide an effective and useful checklist of aspects business analysts should consider when working on business improvement projects.

 

Figure 3.8 The ‘8 wastes’

Transport		The unnecessary movement of people, materials or information.
Inventory		The storage of parts, materials and finished products which are not required to meet the current customer requirements.
Motion		The unnecessary additional movements that are taken by staff in order to accommodate problems with the layout of the organisation, defects in the products, overproduction or excess inventory.
Waiting		The time spent waiting unnecessarily for parts, information, instructions or equipment.
Overproduction		Making more of an item than is required or making items too far in advance of when they are needed.
Overprocessing		The additional work performed in order to deal with over-production, defects or excess inventory.
Defects		Items needing rework or replacement, as they do not meet the product specification or are not satisfactory to customers.
Underutilisation of skills		The underutilisation of the people and their skills, ideas and creativity.

Although originally implemented and used within the manufacturing industry, Lean thinking can apply to other types of organisation where the value streams are concerned with service delivery rather than product manufacturing. Lean is not a technique, tactic or method; it is a way of thinking that is applied when aiming to improve how an organisation operates. Lean thinking aligns with both the philosophy outlined in the Agile Manifesto and with systems thinking, whereby the overall aim is understood and the elements work together to achieve this in the most effective way. While the focus is on streamlining the horizontal, value stream view, any changes to processes will inevitably impact upon other areas as shown in the POPIT™ model. As a result, the adoption of Lean thinking also requires systemic, holistic thinking to ensure that changes to all of the elements that form the business system are considered.

Lean thinking is highly relevant for business analysts. We may be working on process improvement projects with a view to streamlining the work and removing inefficiency, or on projects to develop new or enhanced software that result in corresponding process changes. Either way, our analysis will benefit from understanding the ‘8 wastes’ and how they may be used to improve process efficiency. The adoption of Lean thinking ensures that business analysts focus on establishing the most efficient value stream in order that the organisation’s value proposition may be delivered to customers.

Service thinking

Too often we see the phrase ‘we deliver value’ or ‘and this is how value is delivered to customers’. This may be a promotion from an organisation, as in statements such as ‘we always deliver value to our customers’ or it may be a definition such as ‘business analysts understand business needs in order to deliver value to their customers’. However, a service thinking approach causes us to question such statements because ‘value’ is not for the service delivery organisation to decide, rather it is the recipient who determines whether or not value has been created. In other words, value is in the eye of the beholder.

This distinction is at the heart of service thinking, which is based upon the concepts developed in Service Science. Everything delivered by organisations is a ‘service’, whether tangible goods or intangible services are offered. However, the delivery of service does not mean that value will ensue; sometimes the service delivered does not create or enable value for the intended customer. A good example of this is when devices such as mobile phones provide apps or functionality that are neither desired nor required by the majority of customers.

Service thinking is concerned with the creation and realisation of value and is based upon the fundamental principle that value has to be co-created with customers. So, despite frequent statements about delivering value, organisations cannot deliver value as this requires involvement, support and action on the part of the customers. Instead an organisation can propose to offer value by defining a value proposition and ensuring that the capabilities of the organisation are present to deliver what is proposed. Beyond this, collaboration with customers is needed to co-create a valuable service.

Figure 3.9 below summarises the possible outcomes from the delivery of a service. If customers have collaborated and the value proposition meets the expectations, value is likely to result. However, if the customers have not been involved in co-creating value, then the proposition and the expectations may be in conflict and value is unlikely to result. A version of this may also occur when what is proposed is of no interest to the customers and a service is delivered that is ignored as an irrelevance.

 

Figure 3.9 Organisation versus customer value perception

Organisations can offer a value proposition (based on the organisation’s capability to create and deliver specific goods or services), but customers have to be involved and have to contribute if there is to be co-creation of value. Traditionally, organisations have held the view of ‘value-in-exchange’, where an assumption is made that value is delivered in exchange for payment for the service. However, Service Science provides a more contemporary understanding whereby value comes from the use of the service. This concept of ‘value-in-use’ clarifies that value can only be realised if use is made of a delivered service.

For example, an organisation may believe it has a great product to sell but if it doesn’t quite meet the customers’ needs or they think it is too expensive, they will not buy the product and no value will be created. Similarly, a customer may purchase a service – such as a training course – but if they do not engage with the service – in this case by ensuring that they learn and apply new skills – then no value will accrue.

So, as stated earlier, from a service thinking perspective, an organisation cannot say that value has been delivered; it is the customer who determines this. The organisation can ‘propose’ that value will be delivered but if the value proposition and the delivered service do not meet the customers’ expectation of value, then value is not realised in the eyes of the customer. To achieve the realisation of value, customers have to provide information and other resources that help to co-create a potentially valuable service and they have to make use of the delivered service in order to ensure that the intended value is realised.

Why is service thinking useful to business analysts, particularly within an agile context? Well, agile thinking focuses on the delivery of solutions that will be valuable for the recipients, but it is not possible to do this if we don’t understand where value originates and how it is created.

Service thinking states that value needs to be co-created through collaboration between the service delivery team and the customers. This co-creation of value takes place in two ways:

Therefore, it follows that business analysts need to understand how their work can support the co-creation of value within their organisations. The application of the agile philosophy, principles and techniques will contribute to ensuring that analysts understand customer needs and focus on collaborating with them to co-create value. This is particularly relevant given the range of activities conducted by business analysts and the increasing levels of responsibility and authority that business analysts have attained.

CONCLUSION

Business analysts have to be cognisant of the context within which they are working and the goals to be achieved. They have to ensure that the approach taken to the work is relevant and useful; following a standard method blindly will not suffice in many situations. Business analysts should be ensuring that their customer organisations ‘do the right things’ as well as ‘doing the things right’ (after Drucker 2003).

Business analysis is concerned with addressing business problems and identifying organisational improvements. These improvements may include changes to various aspects of the business system: the people, processes, organisational governance, information and technology. Agile practices have been used primarily for software development but, if applied in a more holistic way, offer the potential for increasing organisational agility. System, Lean and service thinking can help business analysts to approach their work in a more agile manner, focusing on the delivery of solutions from which business value is realised as early as possible. These approaches provide frameworks, principles and techniques that will help business analysts to apply an agile mindset within an organisational context while pursuing valuable business outcomes.

REFERENCES

Ambler, S.W. and Lines, M. (2012) Disciplined Agile delivery – a practitioner’s guide to Agile software delivery in the enterprise. New Jersey: IBM Press.

Checkland, P. (1981) Systems thinking, systems practice. Chichester: John Wiley & Sons.

Drucker, P.F. (2003) The essential Drucker. New York: HarperPB.

Ohno, T. (1988) The Toyota Production System: beyond large-scale production. Portland, OR: Productivity Press.

Senge, P. (2006) The fifth discipline: the art and practice of the learning organization: 2nd edition. London: Random House Business.

Womack, J.P. and Jones, D.T. (2006) Lean thinking: banish waste and create wealth in your corporation 2nd edition. London: Simon & Schuster.

FURTHER READING

Hastings, H. and Saperstein, J. (2014) Service thinking: the seven principles to discover innovative opportunities. New York: Business Expert Press.

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

Spohrer, J.C. and Maglio, P.P. (2010) Toward a science of service systems: value and symbols. In Maglio, P.P., Kieliszewski, C.A. and Spohrer, J.C. (eds). Handbook of Service Science: research and innovations in the service economy. New York: Springer, 157–94.