This chapter covers the following topics:

INTRODUCTION

The agile philosophy offers an astute way of thinking about business systems, so it makes sense for business analysts to understand what agile means and how it may be applied. The 12 agile principles (described in Chapter 2) reflect some core values that underpin agile software development.

This chapter discusses six core agile values to consider how they apply to business analysis and the development of holistic, business improvement solutions.

RELATING THE AGILE PRINCIPLES TO BUSINESS ANALYSIS

Although the agile principles were written with software development in mind, there is an underlying world view that has a broader application to business change projects. This is supported through the ‘Agile Manifesto for business analysts’ discussed in Chapter 3. Detailed consideration of the agile principles reveals that they are based upon values such as effective leadership, collaboration and Lean thinking, all of which are relevant to business analysis work.

The application of the agile principles to the business analysis landscape rather than just to software development may be a new concept to some business analysts. However, the adoption of agile thinking can offer significant advantages when used on business change projects, for example where the following situations are present:

The different levels of business analysis were described in Chapter 1 which explored how business analysts may work in a variety of business environments. For example, they may need to understand agile because they are working within a software development team, on a change project where improvements are to be delivered incrementally, or even in an organisation that has adopted agile across its operations. It is clear that the agile principles present several core values that are relevant to business analysis.

The core agile values for business analysts

There are six core values that may be derived from the 12 agile principles and are highly relevant to agile business analysis. These are shown in Figure 4.1 and discussed below.

 

Figure 4.1 Six core agile values for business analysts

COLLABORATIVE WORKING

Effective communication and collaboration are essential elements of both agile and business analysis. Collaborative working is the ability of two or more individuals, groups or organisations to work together towards a common goal. At the heart of collaboration is the need to engage with colleagues in order to build trust. Without trust, working relationships become difficult; with trust, an environment for success is fostered. The importance of developing trust is illustrated well by the two quotations below.

When we work with people, we have an opportunity to build rapport; when we collaborate we have the opportunity to build trust. Establishing trust results in less need for formality. For example, formal documentation doesn’t always need to be produced to ensure that work is completed where our experience of working with colleagues tells us that we can trust them to complete the agreed tasks.

Working in direct contact with another person is the primary way to gain trust. This is why collaboration is so important within an agile organisation and why it features so much within agile literature. As a general rule, people don’t tend to trust a person they have never met.

Elements of communication

When considering how feelings and attitudes are communicated, Albert Mehrabian (1971) identified three elements of communication and their importance in liking and trusting the person with whom we are communicating. These three elements, captured in Table 4.1 are:

 

Table 4.1 The three elements of communication

Words (verbal)		The actual words that are spoken. The literal meaning of the overall message.
Tone of voice (vocal)		How we say the words and the intonation placed on the words that are spoken.
Body language (visual)		This is non-verbal communication that can be facial expression or body and hand gestures.

Mehrabian’s studies concluded that these elements were represented by the following percentages, shown here in Figure 4.2.

 

Figure 4.2 Mehrabian’s elements of communication

This would suggest that the tone of voice and body language are the most powerful factors concerning feelings or attitudes during the communication process.

Mehrabian’s model tells us that as much as 93 per cent of the elements of communication may be lost if we are not engaged in face-to-face communication. In today’s business world, most communication is carried out through emails or various social media channels. Inevitably this sets up communication barriers, inhibits our ability to interpret messages and causes difficulties for the development of trust within organisations.

Understanding stakeholders

A key aspect of business analysis work involves engaging with the stakeholder community. If an organisation has adopted agile, this helps to ensure greater opportunities for collaboration and communication. Business analysts have a toolkit of techniques for analysing and conveying information, all of which support stakeholder engagement and the achievement of desired business outcomes.

Business analysts understand the importance of analysing stakeholder perspectives. Within the business analysis toolkit we can find techniques such as world view analysis and RACI (see Chapter 7), both of which help us to better understand how to work with stakeholders. Taking the time to understand stakeholders can offer many benefits, such as supporting collaborative working and analysing different perspectives.

Collaboration and organisational culture

A culture of collaboration is not always present within an organisation. It is sometimes the case that employees do not collaborate effectively or value collaboration because they do not see their seniors, or others within the organisation, acting in this way. Instead, they may see their colleagues competing with one another, particularly if there is a focus on recognising individual, rather than team, performance.

Informal collaboration can be encouraged through networking and social events, which can help formal collaboration to develop. The culture of collaboration might not always be seeded within an organisation and those companies with a more formal hierarchical approach may not adjust as well to some of the principles of agile. It is this underlying culture that can often preclude agile from being widely adopted within an organisation, particularly beyond the software development team.

Environmental issues for collaborative working

For many organisations, collaborative working has been critical to the success of agile development. As a result, some office environments have been redesigned to provide a layout more conducive to this style of working. This allows teams to be co-located, either physically or virtually, and often provides an informal workshop-like approach to developing solutions. If the environment is organised into numerous small office spaces rather than open-plan layouts it can result in email exchanges rather than face-to-face communication and can make collaboration more difficult.

Geography can result in teams being physically dispersed, with business analysts in different locations to the customers and the solution development team. This form of business model can be challenging when a collaborative approach is required but can be addressed using technology, for example, video conferencing. Using this technology, individuals can see each other and still obtain some of the verbal, vocal and visual forms of communication that Mehrabian refers to, albeit through a two-dimensional technology screen.

It is useful to consider whether business analysts should sit together or with the development team if they are working on an agile project. The following factors need to be taken into consideration.

There isn’t a definitive right or wrong approach when considering location; it has to be what is right for the business analyst’s customers and for the business as a whole. Having early conversations about the business analyst’s project responsibilities and accountabilities will help to identify a solution that works for everyone.

SELF-ORGANISING TEAMS

The concept of the self-organising team is a key element of agile software development. However, the relevance and potential value from self-organising teams can also be considered for any team or group that is working towards a common goal. Business analysts often perceive that they lack authority in situations where they could make a significant contribution to achieving the project goals. The switch from directive governance to team empowerment should enable practising business analysts to work with greater authority.

It is important to distinguish between a group and a team: a group comprises two or more individuals who interact with one another, bringing their unique perspectives and experience to achieve a goal or objective.

A team is also a group, but with the additional characteristics of a sense of belonging, understanding and awareness of each other’s needs and concerns. In The human touch, Thomas et al. (2012) describe the additional characteristics of a team as including:

Accepting these definitions, it is clear to see why agile refers to teams rather than groups. From a business analysis perspective, however, much of what is discussed in this section could also apply to groups of individuals who come together for a specific event; for example, an initial workshop to outline a problem or to identify problems with the current business situation.

Micromanagement

Micromanagement involves managing teams in a detailed manner, such that all decision-making is removed from team members. Business analysts may experience project managers instructing them on timing, standards and techniques to be used in order to complete a task. For example, ‘you have four weeks to complete the requirements definition for project X by running a workshop and using this template to document each of the requirements’.

This level of instruction can be frustrating for many reasons, but particularly because it implies a lack of faith in the analyst’s ability to determine how the work should be done and how long it will take. The immediate effect of such an approach is for the business analyst to feel undervalued and undermined. It may be that the approach and timescale will work, but it is also possible that the analyst could have suggested a more relevant approach and could complete the work quicker. Given that most business analysts are highly skilled, failing to consult them on aspects of business analysis work can only serve to build a sense of frustration. There is also the possibility in this instance that the work takes longer than the allotted timescale, which may add a sense of failure into the unhappy mix of emotions.

To be truly self-organising, the team needs to be empowered to make its own decisions. If the team members cannot make their own decisions, then they cannot be self-organising.

Dr Stephen Covey (2004) commented in the 7 habits of highly effective people:

Where a team is micromanaged, its members are not empowered and can feel disenfranchised. This leads to a sense of lack of trust and unhelpful behaviours, causing the team to seek guidance rather than work in a self-organising way. This causes significant difficulty if the team is required to adopt agile and apply the agile principles and techniques.

The best way to empower a team is to let members take responsibility and ownership for their own work, tasks and estimates. The Agile philosophy is that the team should take care of its tasks and the project manager or team manager should take care of the team. This is the essence of a ‘self-organising’ team. The team decides how long a task takes and how much work can be done to deliver a desired business outcome within the allotted time frame. In an agile environment, the team is trusted to deliver and therefore there is no need for micromanagement. If business analysts are to work successfully in Agile teams, they have to recognise the importance of working within a self-organising team.

In non-agile teams it is usually the project manager who decides how long a task takes.

In agile development, the team – which includes the business owner of the project – takes responsibility for identifying the tasks, and estimating how long they will take. The project manager leads the team by ensuring that no obstacles get in the way of delivering the tasks. In other words, the project manager trusts that the team members know what they are doing and does everything possible to help them achieve success.

Agile teams are also cross-functional, or multi-disciplinary, in so much as the team must contain all the skills necessary to move from a high-level business need through to delivering outcomes that demonstrate value to the business. This includes skills such as business analysis, design, testing and UX (User Experience) design.

The concept behind self-organising teams is empowerment and trust. Without empowerment there is a lack of trust, and without trust there cannot be an agile team. Team members also have to trust and respect each other, recognising the skills they all bring to the work in hand. Where business analysts work as part of an agile team they have to be cognisant of this principle as it applies to the working relationships they have with the other team members and their stakeholders.

Team development

It’s not realistic to expect a newly formed team to hit the ground running. It takes time for individuals to get to know each other and to trust one another. A newly formed team will need to move through a series of stages in order to develop the ability to work as an effective, performing team. Bruce Tuckman (1965) developed a four-stage model of group formation that is usually referred to as the ‘Tuckman’ model. The stages in this model are shown in Figure 4.3.

 

Figure 4.3 Tuckman’s stages of group development

The four stages of group development identified by Tuckman are as follows:

Forming		At this stage, the group has just come together and everyone is very tentative and uncertain about themselves and their relationship to the other group members. They tend to be careful about what they say as they try to get to know each other and establish basic ‘ground rules’ for their interactions.
Storming		During this stage people start to test the boundaries identified during the forming stage. People often have different working styles and personalities and this can be a source of frustration for other team members. Authority can also be challenged here as team members jockey for positions while their roles are clarified. This can be unsettling as the team have yet to form strong bonds and so individuals may feel isolated.
Norming		This stage occurs once people start to resolve their differences. Team members start to help each other, confide in each other and may even start to socialise outside work. Consensus (about purpose, at least) has been established and the group begins to function reasonably effectively.
Performing		Groups that reach this stage really start to perform effectively (think of the most successful sports teams here). Group members know and trust each other and can hand tasks back and forth with confidence. If someone ‘drops’ something, another team member will step in and pick it up. This is the stage that most teams aspire to and teams at this stage should be left to function.

In a later work, Tuckman and Mary Ann Jensen (1977) identified a fifth stage that groups can encounter:

Adjourning

The reasons why the group was formed are no longer valid and it starts to break up. This stage is characterised by disengagement, anxiety about what happens next, positive feelings of past achievement and sadness at parting.

It is important for anyone involved in managing teams to recognise these stages and help the team to develop by working through these stages as quickly as possible. This is why, for example, when faced with a new team and a tight timescale it may be beneficial to organise an off-site, team-development event as this would help the team to move through the first two stages in a neutral environment.

It is not possible to circumvent these stages, for example by mixing a performing team with a norming team in the hope that this will produce two performing teams. In practice, this will often have the opposite effect, as changes to the constitution of a team at any stage will result in them reverting back to the forming stage.

Team development can be complicated where organisations have ‘virtual’ teams. In this situation, team members reside in different locations or even different countries. This is typically the case with outsourced and off-shored development teams and makes it difficult for teams to move through the team formation process. Even if most intra-group communication is by email, telephone and video or audio conferencing, it is worthwhile having team events where people can get to know each other as this will help the virtual team to function more effectively.

CONTINUOUS IMPROVEMENT

Continuous improvement concerns the ongoing effort to improve products, services or processes, with a focus on delivering improvements for the customer. The approach emerged in the 1950s as Japan began its economic reconstruction following the Second World War.

Today, continuous improvement is a fundamental element of frameworks such as Lean manufacturing and Six Sigma. For many years, continuous improvement was seen as having relevance to just manufacturing organisations and their delivery products. However, it became apparent that any business or function that delivered a product or a service could also benefit from adopting a continuous improvement approach to enhance its overall efficiency and quality. This includes software development.

It is worth noting that there is a difference between developing software and manufacturing products:

Even though the manufactured product is improved, and processes updated, the product can continue to be produced. In some cases, the product may be built millions of times over many years (product examples include an Apple iPhone, a digital clock and a car).

Manufacturing organisations strive for uniformity in both the quality of the product and the processes applied to produce it. However, this is not the case with software as each project will be different from any other project. Although there are many similarities between developing software and manufacturing products, applying a strict ‘one-size-fits-all’ process to software development projects can be the source of many project failures. If we are to apply continuous improvement to software development processes, it is important to recognise the particular features of each project and consider the approach that would be the best fit. While there may be standard methods and techniques that can be used, it is typically the case that some adaptation will be required to ensure that they work within a specific context. Ensuring that there is a focus on adaptation and improvement is a core principle for agile business analysts. One of the ways in which this can be achieved is through using the ‘toolkit’ approach to the analysis work, whereby the technique or standard that is most relevant is selected.

Kaizen

The American engineer W. Edwards Deming wrote in his book Out of the crisis (2000, p. 23):

Deming made a significant contribution to Japan’s reputation for innovative, high-quality products and had a huge impact on Japan’s manufacturing from the 1950s onwards. The developments in Japan resulted in the emergence of Kaizen, which is the practice of continuous improvement where everyone, across the whole workforce from chief executive officer (CEO) to cleaner, is involved in making the improvements. Kaizen is Japanese for ‘improvement’ or ‘change for the best’ and was first implemented on the Toyota Production System. It influenced Lean and Kanban approaches.

Kaizen is based on the PDCA cycle, also known as the Deming cycle (2000) and shown in Figure 4.4, which stands for:

 

Figure 4.4 Kaizen PDCA cycle

The idea behind Kaizen is to include the entire workforce in a culture of continuous improvement. Each person in the company is expected to come up with three to five suggestions for improvement each month. The combined impact of this concept was that hundreds of small improvements could be made each month that would continuously drive the business forward.

Kaizen translates into agile software delivery as follows:

Plan		Within the software delivery process this is done at the start of the time frame, where we plan the goal we want to deliver. We then plan the work required to meet the desired business goal.
Do		Once the tasks have been identified and estimated the agile team start to do the necessary work to complete the iteration goal.
Check		During the iteration, the agile team constantly checks the work they are doing to see whether any adjustments are required. A daily stand-up meeting may be held to check progress and identify any potential problems that need to be resolved.
Act		At the end of the iteration the agile team gets together and discusses what went well and what didn’t go so well. Any suggestions are acted upon by making adjustments and changes to improve these aspects for the next iteration. These meetings are often called retrospectives or iteration review meetings and are explored further in Chapter 15.

Business improvement for business analysts

Continuous improvement has its roots in process improvement, which is often the focus of business analysis work. One of the more common frameworks used by business analysts for process improvement or change projects is DMAIC from the Six Sigma process improvement approach. DMAIC contains the following elements.

Define		Define the problem. Understand the problem we are working to resolve, who the customer and stakeholders are, and the benefits that could accrue. Clarify and define the scope.
Measure		Look at the processes to find the potential causes of the problem. Gather data about the problem.
Analyse		Analyse the processes to determine defects and root causes of problems. Gather and analyse additional data as required.
Improve		Improve the process by eliminating defects. Develop potential solutions and test the solutions against agreed criteria.
Control		Control future performance by developing clear standards and procedures for the process.

ITERATIVE DEVELOPMENT AND INCREMENTAL DELIVERY

Agile software development is based on an iterative development and incremental delivery life cycle approach (explained further in Chapter 5). Iterative development refers to how the software is built, whereas incremental delivery refers to the delivery of the software to the business in releases. This can also be used by business analysts and applied to change projects with a broader focus. A holistic view, coupled with systemic thinking, enables business analysts to identify elements of the business system where it is possible to make targeted, incremental changes that have the potential to deliver benefit at an early stage. This approach helps in the smooth introduction of changes and increases stakeholder confidence in the project.

Applying the iterative and incremental approach

Chapter 5 explains how iterative development and incremental delivery are applied during agile software development. Figure 4.5 shows how this iterative development process can be adapted for the business improvement method DMAIC, taken from Six Sigma.

 

Figure 4.5 Iterative development adapted for process improvement

It is possible to release the improvements developed within one iteration. It is also possible to deliver an increment or release that has been developed during multiple iterations. It is possible to have just one major product delivery (which has been developed during many iterations) followed by smaller changes, although this is less likely within an agile environment. In essence, the principles of iterative development and incremental delivery need to be applied in the way that works best for the organisation.

When developing a solution iteratively, the nature of the overall solution evolves as the work progresses. Both during and at the end of an iteration, all working solutions are tested against previously delivered solutions to ensure that they work together. When delivering changes incrementally, it is important to ensure that any additional changes work seamlessly with the earlier ‘releases’ of change and will deliver the desired outcomes to the business.

A process improvement project provides a good example of how a business analyst might apply iterative development and incremental delivery. In this context, ‘development’ refers to the design and development of improved processes plus their attendant artefacts.

This approach requires collaboration with the customer (another key agile value as discussed earlier), which offers the possibility of discussion and demonstration of ideas as the development work progresses. An incremental delivery approach is likely to minimise disruption during the implementation of process changes, reducing the risk to the continuing performance of the business area.

The first increment

The initial delivery of an IT system or process improvement requires significant analysis as this is going to be the first set of changes that the business customers will experience. When considering what should be delivered in the first increment, it is a good idea to think about the following in order to identify the focus for the project and establish the content of the first release:

The Minimal Viable Product (MVP) and the Minimal Marketable Product (MMP) are two concepts that are particularly relevant when considering the first increment to be deployed. Prioritisation plays a major part in the discussions about the MVP and MMP. This topic is discussed further in Chapter 9.

MVP:		The MVP is the minimum that needs to be done to test, prove or disprove an assumption or risk about the project. For business improvement projects, it may be used to ascertain whether a process improvement is worthwhile or before embarking upon a large improvement programme. The MVP may be an experiment and so may not actually be delivered, as it may not make sense to make the change as it stands. However, it may have been piloted within an area of the business in order to gain necessary information.
MMP:		In essence, the MMP is the minimal amount of change or improvement that can be delivered which will produce tangible outcomes that a customer is willing to accept or pay for. Dependencies will have been proven during the iterations and/or MVP, and risks will have been addressed. This work will have been used to ensure that there is value in making the process improvement.

Iterative development combined with incremental delivery is the approach that underpins agile today and it is as valid to business change and improvement projects as it is to the delivery of software.

PLANNING FOR AND BUILDING IN CHANGE

One thing that is almost always guaranteed on any project is that change is inevitable and can happen for many reasons. Some sources of change are illustrated in Figure 4.6.

 

Figure 4.6 External and internal sources of change

Some requirements are persistent and do not change a lot; data requirements often fit into this category. Other requirements are much more volatile – for example, the details of a user interface – so specifying these requirements in detail at an early stage will undoubtedly waste time and effort. To combat this, agile development attempts to avoid finalising requirements early. Instead, work is planned using high-level requirements and goals that are only protected from change during the iteration within which they are developed. Applying the business analysis technique of establishing a hierarchy of requirements (Chapter 13) and documenting requirements in line with the agile values of Just Enough, Just in Time, will reduce the time spent defining the requirements and avoid unnecessary rework. Ongoing customer collaboration and early delivery of increments helps to ensure that the project team are delivering what the customer requires in order to meet the business need.

DOING THE RIGHT THING AND THE THING RIGHT

As agile becomes more widespread within organisations, the void created by a lack of business analysis is becoming more obvious. Agile development teams run the risk of losing sight of the big picture – the holistic view – and failing to understanding the desired outcomes for their organisation. The business outcome or goal is rarely a new IT system; rather it is a beneficial business outcome such as improved efficiency or productivity. One of the key questions business analysts ask is, ‘Why?’ in order to challenge conventional wisdom and uncover root causes of problems. This is how the actual business needs are uncovered and is in line with Drucker’s (2003) principle of delivering ‘the right thing’ as well as ‘the thing right’. These terms are not evident within the 12 agile principles. However, they are important in the business context and for the agile delivery of holistic solutions.

Deliver the right thing

Introducing technology is not always the right solution to solving business problems and yet technology is chosen regularly over alternative options such as business process change or skills development. This is often in the hope that a big investment will bring about big results. While technology is a huge part of businesses today, so are the people working within organisations, the processes they use and the skills they possess.

Delivering the right thing involves making sure that the root cause to a problem is understood and that the solution involves all necessary elements of the POPIT™ model. Therefore, the ‘right thing’ is likely to be a mix of people, organisation, process, information and technology change. Failing to consider the holistic solution is likely to result in disappointed customers and unrealised benefits.

Deliver the thing right

Agile business analysts can add significant value to their organisations and projects by being aware of the need to tailor their approach as necessary. Although requirements typically evolve during the iterative development process, some requirements may need to be defined in detail at an earlier stage. If it would be beneficial to define a process or rule at an early stage then we should be prepared to do this. If a particular requirement is difficult to understand, perhaps because of the presence of tacit knowledge, then we should consider which techniques would be most relevant to gain the necessary understanding.

It is of paramount importance that the constraints and assets of the business are considered when deciding the development and delivery of the solution. It is possible that the iterative development of the solution may be assisted by adopting a modular business architecture, based on reusable organisational capabilities, components and artefacts.

While incremental delivery enables the early realisation of benefits and the reduction of risk, this may not always be possible within the business context. For example, where a legacy system or processes are to be replaced, it is possible that the solution has to be delivered in one release.

Ultimately, applying any approach – whether agile or not – as a ‘cookbook’ does not help to ensure the success of a change project. The essence of agility is adaptability and agile business analysts who do this are well placed to ensure that the ‘thing’ is delivered right.

CONCLUSION

The business analysis toolkit is constantly evolving and business analysts have to subscribe to ongoing personal development. The six core values (Figure 4.1) capture the essence of an agile mindset and should be applied by business analysts when working within an agile environment. Techniques and frameworks such as Kaizen and DMAIC are worthy additions to the business analysis toolkit and have the potential to offer benefits to agile business analysts.

REFERENCES

Covey, Dr S. (2004) 7 habits of highly effective people. London: Simon and Schuster Limited.

Deming, W.E. (2000) Out of the crisis. Cambridge, MA: MIT Press.

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

Mehrabian, A. (1971) Silent messages: 1st edition. Belmont, CA: Wadsworth.

Sinek, S. (n.d.) AZ quotes. Available from: www.azquotes.com/quote/714917 [7 December 2016].

Thomas, P., Paul, D. and Cadle, J. (2012) The human touch: personal skills for professional success. Swindon: BCS.

Tuckman, B.W. (1965) Developmental sequence in small groups. Psychological Bulletin, 63 (6): 384–99.

Tuckman, B.W. and Jensen, M.A. (1977) Stages in small group development revisited. Group and Organisation Studies, 2: 419–27.

FURTHER READING

Patton, J. (2014) User story mapping: 1st edition. Sebastopol, CA: O’Reilly.

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