This chapter covers the following topics:

INTRODUCTION

The majority of business analysts will encounter agile methods while working on change projects, reading online articles or attending training courses and this is likely to utilise, or focus on, a specific method or process. Often, it can feel that there is only one way to ‘do agile’ and that the techniques, practices and ceremonies of that approach are all there is to know.

Conversely, as explained in Chapter 2, the Agile Manifesto originated as an amalgam of many methods and approaches, took the best parts of them, and derived a set of core values and principles. However, the Agile Manifesto does not specify how to apply the values or principles so, since its creation, there have been several attempts to create methods, processes and approaches that fill this gap. And although they vary in many ways, they can all claim to apply agile; it is just that they are agile in different ways.

These methods and approaches may differ in their depth, the scope of the projects they are aimed at and the team roles they describe. They also focus primarily on software development and encourage the elaboration of requirements through discussions between developers and end users. This can make it difficult for business analysts to know where they fit, as very few of the popular approaches specifically mention the need for a business analyst. Despite this, there remains a clear need for business analysis skills in projects today, as this book makes clear. This chapter will briefly describe some popular agile methods and approaches and help business analysts to understand the context within which they may need to work.

KEY ELEMENTS IN AGILE METHODS

There are a number of elements common to all agile approaches. They are described in this book without reference to specific methods. For example, Chapter 11 discusses several techniques that may be used to conduct requirements analysis, whatever the method adopted on a particular project. What makes them agile techniques is the way in which they embody the values in the Agile Manifesto or demonstrate the agile principles. Understanding the core aspects of agile helps when learning new methods and moving from one agile project to another. In practice, very few teams apply a given method in a prescriptive way. Instead, the approach evolves and is continually improved as the method is applied to the development work.

Some of the key elements that are common to agile methods and are of particular relevance to business analysis are described in Table 5.1 below.

 

Table 5.1 Key elements in agile methods

A list of work to be done		A list of work items must be created for a project and needs to be ordered or arranged in some way. The priorities of the list must be established and it must be kept current as the project progresses. There are several names for this list including backlog, inbox, feature list, requirements list and work items. The creation and management of this list, including the elicitation and analysis of the items, plus alignment with expected business benefits, requires good business analysis skills.
Iterative development		Agile methods typically emphasise the need for many regular periods where software is developed and delivered. These periods often follow a regular time frame (for example, every two weeks) and may be known as iterations, sprints or timeboxes. The work of each iteration may be cumulative, where each delivered increment builds on the previous one, adding new functionality or qualities. It is important that each iteration focuses on delivering a valuable outcome for the customer; this is an area that requires skilled business analysis.
High levels of customer involvement		In contrast to waterfall approaches, agile methods do not receive or produce comprehensive statements of requirements as a starting point. Instead, they expect the detailed requirements to evolve and change during the development process. To do this, the team needs to have constant and ongoing engagement with the customers. Sometimes, development teams can become resistant to change, particularly as the project nears completion. Business analysis is focused on the needs of the customer; it will ensure that the analysis is conducted so that changes are understood and identified quickly. There is a wide range of customers and stakeholders; these are discussed in Chapter 7. Balancing the needs of these disparate customers is a fundamental business analysis skill.
Transparency and sharing progress		Transparency is an important aspect of agile and many teams use physical boards or tables to record progress. The customer needs to be involved in planning and review meetings, and is expected to play a full part in the team. However, this is often difficult in practice, as customers may not be able to give sufficient time at the point it is required. In this situation, it is often the business analyst who can act as a proxy for the customer and provide the required business knowledge.
Regular reviews of progress		At the end of each iteration or phase, meetings are held where progress is reviewed and the team make any necessary changes or even stop working on the project. These meetings are often called retrospectives, but reviewing progress, and reacting to the review outcomes, can also be part of planning meetings. This dedication to continuous improvement should be familiar to business analysts, and many business analysis techniques can help these meetings run smoothly.
A whole team mindset		The team works together and collectively feels responsible for the work. Between them, they have all the skills required to perform the work. Often this means that each team member is expected to have cross-functional skills in addition to their particular specialism. The term ‘generalising specialist’ has been coined to describe a team member with cross-functional skills. In this context, it is possible that a business analyst may be involved in testing software. However, some activities will require specialist skills, such as those offered by business analysts.

POPULAR AGILE METHODS AND APPROACHES

There are several popular agile methods and frameworks and they are described in outline below; additional reading references are provided at the end of the chapter. Some of the approaches can correctly be described as methods, as they specify the details required to implement them. Others are defined in less detail, consisting of guidance and principles rather than complete methods.

Scrum

Scrum is by far the most widely used agile method and, for many people, it is synonymous with agile. It is documented on the www.scrum.org website which is updated frequently and is described in many books.

It was first presented by Jeff Sutherland and Ken Schwaber in 1995 and is based on empirical process control theory or empiricism. This asserts that since it is impossible to fully know everything at the start, the team should take an incremental approach, make decisions based on what is known at the time, and build knowledge and experience to make better decisions next time.

Scrum describes three pillars that uphold this approach: Transparency, Inspection and Adaptation. These are sometimes called the Three Pillars of Scrum, and sometimes the Three Pillars of Agile.

Scrum is a relatively simple method. It defines four key events, three roles and three artefacts. The activities directly support the pillars of Inspection and Adaptation, and the artefacts support Transparency. There is much that Scrum does not prescribe. For example, it does not dictate how teams should describe requirements or work items. Scrum is a framework or container – it mandates the elements considered to be critical and leaves the rest up to the teams. This is described in the Scrum Guide (Schwaber and Sutherland, 2014) as follows:

While many teams implement Scrum in a pure form, there are many variations of it in use. Teams have evolved, adapted and changed Scrum. Many of the other methods described below borrow some elements from Scrum. Some of the Scrum terminology (such as backlog, Scrum and retrospective) are now widely used in agile and usually have the same meaning. Despite being widely used, it is also widely abused and many teams struggle to apply the core principles; typically, the quality of their work suffers as a result.

The sprint

The sprint is at the heart of Scrum. It is a timebox of one month or less, during which the team develop a potentially releasable version of the solution called the increment. Sprints have some immutable rules:

Sprints can be considered as ‘mini-projects’, each with a discrete outcome to achieve (the sprint goal), a design and a flexible plan to achieve it. The goals do not have to be IT related, and Scrum can be successfully used for business change or process improvement projects.

Scrum events

The four key events in Scrum sprints are described in Table 5.2 below.

 

Table 5.2 Four key Scrum events

Sprint planning		Before the sprint begins, the whole team plan what work will be done in the sprint, agree the goal and decide how the work will be done. This activity must involve the whole team. Business analysis skills are crucial to ensure that the backlog items being considered are correctly understood by the team, and that non-functional requirements and non-IT aspects of the solution are considered.
Daily Scrum		Each day, the development team holds a short team meeting (less than 15 minutes) called a daily Scrum. This allows the team to inspect the work done since the last daily Scrum and forecast the work that could be done before the next one. This may mean the team adapts its approach in order to ensure that it will meet the agreed goal.
Sprint review		The sprint review takes place at the end of the sprint and is an opportunity to inspect the increment and adapt the product backlog if required. This includes taking account of changes such as to the business environment. This meeting is an informal meeting of the development team and stakeholders, and the result is a revised product backlog.
Sprint retrospective		In contrast to the sprint review, the retrospective is strictly limited to the development team and offers the opportunity to inspect the work completed by the team and plan what changes the team members wish to make for the next sprint. The areas to consider during the retrospective include people, relationships, processes and tools. This focus on people and other non-IT elements of the sprint will be familiar to business analysts and requires business analysis skills. The POPIT™ model and other holistic approaches to solution development may be useful techniques during this work.

It is important that the Scrum events take place and that they are facilitated well. Scrum provides some guidance on the duration of these events during a one-month iteration. Although these timings are a maximum, rather than a target, they provide an indication of the level of importance the authors of Scrum place on them:

These events together with the 15-minute daily scrums, amount to 20 hours of elapsed time. This is 12.5 per cent of a sprint that lasts four weeks, with 40 hours of elapsed time per week; a considerable proportion of time. Business analysis skills are extremely helpful in ensuring that teams use this time wisely, both in facilitating the meetings and in providing contributions from a different perspective to that of other team members.

Scrum roles

There are three roles defined within Scrum; they are described in Table 5.3.

 

Table 5.3 Three Scrum roles

The product owner		The product owner is (or represents) the person (or organisation) that will ultimately benefit from the solution. The holder of this role is solely responsible for decisions about the product backlog, including prioritising the items, ensuring the development team understands what they mean and deciding when they have been completed. The skills required for this role closely align with the skills of the business analyst. In some teams, business analysts will help the product owner with their responsibilities. It is possible that in some teams a business analyst will be asked to be the product owner but in doing so, they should assume the responsibilities outlined above. If the product owner does not have access to business analysts, then it is important that they, or some of the development team, have or acquire business analysis skills.
The development team		The development team consists of professionals who do the work required to deliver a potentially releasable solution at the end of each increment. They are structured and empowered to organise and manage their own work, which optimises their effectiveness. Development teams are cross-functional, and between them they contain all the skills necessary to deliver the work. This requires the team members to be highly competent with regard to some skills and, also, to hold other broader skills at a less specialist level. This aligns with the concept of a T-shaped professional, which is discussed in Chapter 7. While business analysis work is required in a Scrum development team, the business analysts (and anyone in any other role) will be called ‘developers’ and will be expected to do work outside their specialism if it is necessary to complete the increment. This can mean that business analysts joining a Scrum team will be expected to learn new skills.
The Scrum master		The Scrum master is responsible for ensuring that Scrum is understood and enacted by the team. This role is described as the ‘servant-leader’ for the team, who provides services to both the development team and the product owner. The Scrum master helps the product owner to find ways to manage the backlog, ensuring that the team understand what the product owner is requesting. The role is also concerned with facilitating Scrum events, providing coaching for the development team, helping the team to carry out the work and, most importantly, removing any impediments to the team’s progress.

Scrum artefacts

The three artefacts defined within Scrum are described in Table 5.4 below.

 

Table 5.4 Three Scrum artefacts

Product backlog		The product backlog provides an ordered list of everything that might be needed in the solution. It is the single source of requirements for the project, and the responsibility of the product owner. It exists at the product level, which means that several Scrum teams can operate from a single product backlog. The product backlog is never complete and continuously evolves through the lifetime of the project, requiring ongoing attention. It is a living artefact and, as for other requirements artefacts, requires business analysis skills to create it, maintain it and ensure its quality. Chapter 12 considers the backlog in the light of a similar business analysis artefact, the requirements catalogue.
Sprint backlog		A sprint begins with the identification of a subset of the product backlog items; these are the items that must be completed during that sprint in order to achieve the sprint goal. The sprint backlog provides a plan that describes how the goal will be met. During the sprint, the sprint backlog will constantly evolve, as more detail emerges about the work to be conducted by the team. As new work emerges, it is added to the backlog, so that it becomes a highly visible, real-time description of the work the team needs to complete.
Increment		This is the sum of all the sprint backlog items completed during the sprint, and the work completed during all of the previous sprints. The increment must be usable by the customer, and meet the criteria that the development team have agreed with the product owner to define that the increment is ‘done’.

XP

Many of the participants in the 2001 meeting where agile was conceived were from the XP community, including its founder, Kent Beck. Therefore, it is unsurprising that many core agile ideas derive from XP and are used within other agile approaches.

XP focuses on software development, and describes five basic activities (or ‘rules’) bound together by five values. These are all focused on building software that delivers customer satisfaction. XP does not specify any particular roles or job titles, instead using the term ‘developer’ to describe all roles. It requires teams to take collective ownership of the work, focus on the highest value goals first, and adapt how they work depending on the circumstances. As a result, this approach requires multi-disciplined team members.

Despite the need for team members to be multi-skilled and the dominance of software terminology in the method, XP’s focus on the customer and embracing of changing requirements requires XP teams to have strong business analysis skills.

The five rules are described in Table 5.5 below, and in further detail at www.extremeprogramming.org. Several of these concepts are covered in further detail in Chapter 15.

 

Table 5.5 Five rules of XP

Planning		The project is divided into iterations and bound together into a release plan and schedule. User stories describe the functionality to be built for the customer, and the team makes frequent small releases.
Managing		The team is given dedicated open workspace to ensure good communication. There is a focus on a sustainable pace and the team measures the speed of progress in order to be predictable. XP teams move people around to avoid bottlenecks and foster cross-functional training. The day starts with a stand-up meeting.
Designing		XP teams aim for simplicity and measure this using the four subjective qualities: Testable, Understandable, Browsable and Explainable (TUBE).
Coding		The customer must always be available during coding, and there is a strong focus on early and frequent integration. XP teams use techniques such as pair programming and TDD, and apply collective ownership.
Testing		All code must have unit tests and must pass them before it can be released. When bugs are found, new tests are written to catch them earlier next time. Acceptance tests are run often and the results published.

XP has a strong focus on improvement, and describes five essential values that are used to improve a software project: Communication, Simplicity, Feedback, Respect and Courage. XP challenges more traditional development approaches by advocating that teams ‘Manage Goals Instead of Activities’ and use user stories to describe goals that are ordered in terms of importance. The team focuses on delivering the most important goal (defined for a user story) first, completing all of the activities necessary to satisfy the customer’s acceptance criteria. This part of XP is clearly where a business analyst can add significant value, for example, in identifying user roles and constructing the goal-based user stories. The identification and decomposition of goals are described in Chapter 8.

XP works well where the team comprises between 2 and 12 team members. However, it is hard to scale for larger teams without compromising on the core elements of the approach.

DSDM

DSDM is a vendor independent framework for agile project management and delivery that emerged from the RAD community in order to build quality into the prevailing RAD practices. It is owned by the DSDM Consortium, a non-profit organisation.

The framework has evolved over the years, and the current version (launched in 2014) is called the DSDM Agile Project Framework. DSDM incorporates project-focused principles and offers a rich set of roles and responsibilities that make it well suited to agile in a corporate environment. DSDM defines a number of products or deliverables, and teams choose which they require based on the characteristics of each individual project. Tailoring the approach is an important aspect of DSDM, particularly if the project is to align with the agile philosophy to do Just Enough, Just in Time.

The DSDM Today (2016) philosophy is that:

This philosophy is further supported by a set of eight principles, which describe the mindset and behaviours necessary for a DSDM team to succeed. The DSDM principles are:

Unlike other methods (such as Scrum), DSDM describes the entire project life cycle from pre-project through to deployment and post-project. It advocates the use of several core practices, including facilitated workshops, modelling, iterative development, MoSCoW prioritisation and timeboxing. These techniques will be familiar to many business analysts as they are in widespread use, both within traditional and agile environments. Because DSDM is a framework and covers the whole project life cycle, it integrates well with other processes and frameworks such as PRINCE2® and the standards offered by the Project Management Institute (PMI). Teams can also use Scrum, Kanban (see below) or XP in the development phase.

The life cycle phases in DSDM are described in Table 5.6 below.

 

Table 5.6 DSDM life cycle phases

Pre-project		Ensures that there is a clear business goal for the project.
Feasibility		Establishes whether the proposed project is likely to be technically feasible, and cost effective. This should take just enough effort to decide whether to stop or continue.
Foundations		Establish a fundamental (but not detailed) understanding of the business rationale and potential solution, and how the solution will be developed, delivered and supported.
Evolutionary development		Using iterative development techniques and MoSCoW prioritisation within timeboxed iterations, the solution team create solution increments.
Deployment		A baseline of the evolving solution is moved into an operational environment. This can happen many times as new versions become available. This stage consists of three main activities, Assemble, Review and Deploy.
Post-project		The project is formally closed and the team conducts a retrospective on their performance. This phase also checks how well the intended business benefits have been delivered by the solution.

Unsurprisingly for an approach aimed at larger, more complex problems, DSDM describes a much larger set of roles than other agile processes. In total, DSDM describes 13 roles covering project level, solution development and supporting responsibilities; the core roles are described in Table 5.7.

 

Table 5.7 Roles defined within DSDM

Business sponsor		Responsible for ensuring the delivery of the business case and representing the interests of the business.
Project manager		Responsible for overall management of the project, providing resources, ensuring delivery of the project objectives, and communicating with senior business representatives and the solution development team.
Business visionary		Responsible for providing strategic direction to the project and ensuring that the vision of the business sponsor is interpreted and communicated accurately.
Business analyst		Responsible for supporting the business visionary in fulfilling the business needs determined for the project. Provides analysis and modelling expertise as required. Takes a proactive role in facilitating the communication within the solution development team. This definition is focused on solution development and does not include the pre-project activities described earlier in this chapter.
Technical coordinator		Responsible for ensuring the overall coherence of the technical design adopted on the project.
Business ambassador		Responsible for representing the needs of the business users and providing the communication channels between the project and the business. The business ambassador is a credible representative of the business staff and has knowledge and experience of the business area addressed by the solution.
Team leader		Responsible for facilitating, scheduling and monitoring the work of the solution development team at an iteration level.
Solution developer		Responsible for developing the solution to meet the functional and non-functional requirements.
Solution tester		Responsible for testing the developed solution, including technical and acceptance testing.
Technical advisor		Responsible for providing specialist or specific information about the technical aspects of the solution.
Business advisor		Responsible for providing specialist or specific information about the business needs and working practices.

The roles include a business analyst at both the project level, and in the solution development team. This is intentional, and allows the business analyst to work on behalf of the customer (for example, to develop the business case) or as part of the solution development team (for example, elaborating requirements, modelling or helping the developers understand the requirements).

Unified Process

Although not represented in the group that met in 2001 to conceive agile, the UP was already established at that time and embodies many of the same characteristics of incremental and iterative development. Like DSDM, the UP is aimed more at corporate enterprises, takes a whole life cycle view and describes a large number of roles and artefacts that should be tailored by the team to fit the problem. The most common version is the RUP, which was launched by Rational Software in the late 1990s and is now owned by IBM. Other versions include OpenUP and AgileUP.

The UP defines four phases required to develop the solution, describes workflows that are required throughout the project (including business modelling) and sets out principles that should be followed by the project team. As with DSDM, the UP can easily be misused by teams that forget the first (and only) mandatory step: Tailor the Process.

The four phases of the UP are described in Table 5.8 below; each phase consists of one or more iterations.

 

Table 5.8 Four phases of the UP

Inception		Establish the business case for the system and define the system scope. Identify at a high level how the system interacts with users and describe all the high-level use cases. Provide more detail for significant use cases. Gain agreement with stakeholders on project scope and cost/schedule estimates.
Elaboration		Establish a sound architectural foundation and eliminate the highest risks to the project. Gain a ‘mile-wide and inch-deep’ view of the system. This can include developing prototypes.
Construction		Develop all remaining features incrementally. Reach ‘Initial Operating Capability’ with a usable version of the solution produced in each iteration.
Transition		Deploy the solution to the user community.

The RUP is a specific, and popular, implementation of the UP. RUP advocates a set of overarching principles known as the six best practices:

The UP methods place high importance on requirements and on business modelling, and business analysis skills are essential for this work. Since the various artefacts are developed incrementally – or elaborated – throughout the project, business analysis work is required at all phases at the level of detail needed to address the risk of each phase.

Kanban

Kanban is not strictly an agile method, as it describes how to optimise the services delivering the knowledge work, rather than the delivery of the work itself. This distinction is an important one, and explains why Kanban is often used alongside other methods. It describes an approach to incremental and evolutionary process and systems change. It focuses on delivery flow, and on managing and optimising Work in Progress (WIP, also sometimes called Work in Process) to offer teams more flexible planning options, faster output and a means of continuously improving performance.

Kanban is derived from the Lean manufacturing approach and has been popularised for software and business change projects by David J. Anderson. Kanban is based on six core practices:

The first of these practices – visualise – is often done using a board or table. The steps required to implement a requirement are set out as columns as shown in Figure 5.1. Work to be done is written on a card (a Kanban) and begins on the left, in the ‘Inbox’. As requirements are worked on, the team moves the card to the appropriate column.

 

Figure 5.1 Example of a Kanban board

This is just one of six practices, but it is common for teams to carry out just this one practice and think that they are applying Kanban. However, to get value from this approach, each column must have a maximum WIP limit that dictates how many requirements can be in progress. The team then focuses on choosing work that enables flow, and creates space for more work to be pulled in.

Bottlenecks become obvious when using Kanban and the team is motivated to find ways to remove them. For example, if only one person is able to do the testing, they could quickly find that work cannot be moved into the ‘Test’ column because it is already full and this will prevent the commencement of other work in the pipeline. To unblock this, the other team members may need to learn how to do the testing work and provide additional staff resources for the test activity.

Business analysis is not specifically mentioned in Kanban but since the focus for the team is improving flow, all team members should be able to work across several columns. Some of the most important business analysis work involves ensuring that the work in the Inbox column is correctly described.

Kanban can be used with other agile approaches, such as Scrum or XP, and some of the Kanban principles (especially the use of an agile board) are part of other methods. In contrast with many other agile approaches, Kanban does not use timeboxing; instead, releases are made when there are sufficient Kanbans (or cards) in the ‘Done’ column.

Lean software development

Lean software development is a method that was derived from the manufacturing principles in the Toyota Production System. The approach focuses on the elimination of waste (muda in Japanese) and considers wasteful any effort that does not result directly in the provision of value for the end customer. The seminal reference text is Lean software development by Mary and Tom Poppendieck (2003). There are seven key Lean practices that are translated into software development principles. The Poppendiecks present an ‘agile toolkit’ of 22 tools that are mapped onto the principles shown in Table 5.9.

 

Table 5.9 Agile toolkit of Lean software development

Lean principle		Lean software tool
Eliminate waste		1. Seeing waste 2. Value stream mapping
Amplify learning		3. Feedback 4. Iterations 5. Synchronisation 6. Set-based development
Decide as late as possible		7. Options thinking 8. The last responsible moment 9. Making decisions
Deliver as fast as possible		10. Pull systems 11. Queuing theory 12. Cost of delay
Empower the team		13. Self-determination 14. Motivation 15. Leadership 16. Expertise
Build integrity in		17. Perceived integrity 18. Conceptual integrity 19. Refactoring 20. Testing
See the whole		21. Measurements 22. Contracts

The approach focuses more on improving the process than developing a solution. Many of the tools identified within the toolkit benefit from the application of good business analysis skills. Lean software development can also be combined with other agile approaches.

Lean Startup

Lean Startup provides an approach to creating and managing startup organisations using some of the Lean and agile principles. It is not intended to be used exclusively for new startup companies; it is also used for the development of new products (or new versions of products) within existing enterprises. As a result, business analysis skills to engage with customers are essential. Lean Startup also recommends the use of analysis techniques such as the ‘5-Ws’ (Why, What, Who, When and Where) and prototyping, which form part of the business analysis toolkit.

SCALED AGILE APPROACHES

When agile approaches began in the early 2000s, they were applied, in the main, to small, relatively simple problems that were resolved by small teams; within this context, they worked extremely well. As the agile movement has grown and become more prevalent, organisations are trying to achieve the benefits of agile for larger and more complex problems, with larger and more diverse teams.

As the history in Chapter 2 explains, this is not how agile began so it should be no surprise that some common approaches and methods do not work well when faced with large and complex problems. This has led to numerous attempts to find ways to scale agile approaches so that they can work across larger and more complex projects and programmes, whilst still retaining the benefits of small, autonomous teams with highly collaborative work practices.

Some of these attempts to scale agile have become popular, but there are still many bespoke, company specific methods that business analysts may come across. This is because many companies who were relatively early adopters of agile quickly came up against difficulties, as the problems they were trying to solve were not the kinds of problems that agile was initially intended for. So, they tried to solve problems themselves, perhaps with the aid of external agile coaches or experts, and developed proprietary solutions that suited their problem spaces. This has been happening for years and some of these bespoke variants have coalesced into generic approaches that are now gaining popularity.

Organisations deciding to adopt agile practices today are comparatively lucky. Not only are the classic agile methods well understood but there are also several new frameworks and methods to select that are designed for more complex or extensive problems.

Disciplined Agile 2.0

Scott Ambler has been helping companies apply agile principles to complex enterprise problems for many years, and in that time has published several books and methods. His latest framework is developed with Mark Lines and is called Disciplined Agile 2.0 (DA 2.0); it is an evolution of their disciplined agile delivery approach. It restates the Agile Manifesto from a strategic perspective, focusing more on solutions and stakeholders than software and customers; it also adds some principles around enterprise reuse and the importance of the enterprise ecosystem.

DA 2.0 is a process decision framework that is scalable both at a tactical (team) level and a strategic level. It is a people-first, learning-oriented hybrid agile approach with a risk-value life cycle and is highly goal driven. It extends Scrum with proven techniques from a wide range of other agile approaches and methods, including the UP and agile modelling. It thinks beyond construction and considers the end-to-end development life cycle, including roadmaps, enterprise architecture, IT governance and DevOps; all from a highly agile mindset. It encourages teams to understand their environment properly and use that knowledge to select the right elements for their approach. In this way it is highly flexible.

Although it does not specify a business analyst role, DA 2.0 relies heavily on sound business analysis skills in the team, particularly for the identification and specification of stories/work items, and in the agile modelling practices.

SAFe

Den Leffingwell’s Scaled Agile Framework (SAFe) is based on a number of Lean and agile principles and provides a way to apply them to enterprise software development where there may be many teams, perhaps geographically distributed, building highly complex, integrated systems.

SAFe applies a portfolio approach which ensures alignment with the enterprise strategy. The portfolio backlog is used to drive out programmes of work, each defined through a programme backlog. Each programme may then have several teams which operate as ‘normal’ Scrum teams with their own team backlog. Integration and delivery are managed through programme increments and iteration goals. One of the key concepts used in SAFe, is the agile release train, which is formed of all the development teams and is focused on a common mission to which all the teams contribute.

There is no business analyst role specified, but there are many elements of SAFe where business analysis skills are needed. For example, when identifying artefacts such as the epics described at the SAFe portfolio level or ensuring that goals are defined that align to business needs. Furthermore, SAFe recommends the Weighted Shortest Job First (WSJF) prioritisation approach (see Chapter 9), which requires the ability to understand and analyse business priorities.

Nexus and LeSS

The Nexus Framework is a means of scaling Scrum such that multiple Scrum teams are able to work together, using a central product backlog and working jointly on the increments for release.

Large Scale Scrum (LeSS) is a framework for scaling Scrum to large product developments. While there are several development teams, they focus on the whole product rather than just the work they produce individually. LeSS uses one instance of the product backlog and there is one product owner across all of the teams. The teams work together in one sprint to deliver a collectively developed product release.

CONCLUSION

Although there are many ways to develop solutions using agile methods, Scrum is the dominant approach, either as a method in its own right or as part of a larger, scaled framework. The software heritage of agile is very obvious within the most popular methods, and, in the main, this has resulted in the lack of recognition of business analysis. DSDM alone identifies the business analyst role as a means of providing a link between the project level and the solution development team. However, the agile values of high customer interaction, achieving business goals and delivering business benefit, are inherent in all of the agile methods and it is important to recognise that the achievement of these values requires business analysis skills.

Whichever agile method is to be adopted, business analysis will be required prior to the initiation of a software development project in order to ensure that the business needs are understood and met. If the project is concerned solely with the development of software, it is probable that business analysis skills will be needed to explore usage and work practice needs, including the often-complex business rules. However, it is likely that a software product alone will not deliver the changes needed by the business and a holistic solution will be required if the business needs are to be met. This will encompass elements such as processes, job roles, organisational structures and people competencies; these elements are natural territories for the business analyst. However, business analysis work in these areas would benefit from the adoption of the agile principles and some of the practices advocated by the methods and frameworks described in this chapter and in this book.

REFERENCES

Poppendieck, M. and Poppendieck, P. (2003) Lean software development: a toolkit. Boston, MA: Addison Wesley.

Schwaber, K. and Sutherland, J. (2014) The Scrum Guide™

The Definitive Guide to Scrum:

The Rules of the Game. Available at: www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf (18 January 2016).

FURTHER READING

Ambler, S., Lines, M. and Vizdos, M. J. (2012) Disciplined Agile delivery: a practitioner’s guide to Agile software in the enterprise. Upper Saddle River, NJ: IBM Press.

Ambler, S., Nalbone, J. and Vizdos, M. J. (2005) The enterprise Unified Process: extending the Rational Unified Process. Upper Saddle River, NJ: Pearson Education Inc.

Anderson, J. and Carmichael, A. (2016) Essential Kanban: the guide. Washington, DC: LeanKanban University Press.

Beck, K. (1999) Extreme programming explained: embrace change. Boston, MA: Addison Wesley.

Cadle, J. (ed.) (2014) Developing information systems. Swindon: BCS.

Cohn, M. (2009) Succeeding with Agile: software development using Scrum. Boston, MA: Addison Wesley.

DSDM Today. Available from: www.Agilebusiness.org/content/philosophy-and-fundamentals [7 December 2016].

DSDM Consortium (2008) DSDM Atern: the handbook. Available from: www.agilebusiness.org/resources/dsdm-handbooks/dsdm-atern-handbook-2008 (18 January 2017).

Kennaley, M. (2010) SDLC 3.0: beyond a tacit understanding of Agile: towards the next generation of software engineering. Fourth Medium Press.

Kruchten, P. (2003) The Rational Unified Process: an introduction, 3rd edition. Boston, MA: Addison Wesley.

Larman, C. and Vodde, B. (2016) Large-scale Scrum: more with less. Boston, MA: Addison Wesley.

Martin, J. (1991) Rapid application development introduction. USA: Macmillan.

Measey, P. (ed.) (2015) Agile foundations, principles, practices and frameworks. Swindon: BCS.

Monden, Y. (1998) Toyota Production System, an integrated approach to just-in-time, 4th edition. Boca Raton, FL: Productivity Press.

Poppendieck, M. and Poppendieck, P. (2009) Leading Lean software development: results are not the point. Boston, MA: Pearson Education Inc.

Schwaber, K. (2004) Agile project management with Scrum. Washington, DC: Microsoft Press.

Schwaber, K. (2007) The enterprise and Scrum. Washington, DC: Microsoft Press.

Sutherland, J. (2014) Scrum: the art of doing twice the work in half the time. New York: Random House Publishers.

USEFUL WEBSITES

www.ambysoft.com/unifiedprocess/agileUP.html

www.disciplinedagiledelivery.com

www.dsdm.org

www.dsdm.org/resources/dsdm-handbooks/the-dsdm-agile-project-framework-2014-onwards

http://epf.eclipse.org/wikis/openup/

www.extremeprogramming.org

www.ibm.com/developerworks/rational/library/content/­03July/1000/1251/1251_bestpractices_TP026B.pdf

www.leankanban.com

https://less.works

www.scaledagileframework.com

www.scrum.org/Resources/The-Nexus-Guide

www.scrumguides.org/scrum-guide.html