The agile change process

Over years of experience, we have honed a proven process which we use to organise any Agile project driving organisational change. This maps to the four phases of an Agile scrum. In this article, we will take you through those phases step by step, explaining what we do at each stage to make the project a success.

We’ll also share key challenges and tips to solve them, and illustrate the story with reference to a fictional company called FIXIT Damage Insurance.

Example process: FIXIT Damage Insurance

How the agile change process would work in a fictional company

The Agile Change Process starts by capturing the organisation’s strategic themes, and translating them into a roadmap. This sets out the epics needed to turn the ambition into reality.

Once the epics are defined, the process goes through four main phases at team level: preparation, pre-sprint, development sprints, and implementation.These map to the standard Agile scrum framework (see Figure 2), and specific business analysis models can provide further clarity at each stage as needed.

Each change process is unique. So, to illustrate, we’ll explain using a fictional company called FIXIT Damage Insurance.

Phase 1: preparation for change

FIXIT Damage Insurance has a strong ambition for change. A roadmap is drawn up showing how this will be achieved, defining many epics which need to be delivered. This is controlled by a portfolio board, and a business owner is appointed for each epic.

The business analyst works with each business owner, and develops an epic description on their behalf. The description is a kind of mini business case or justification for the change process, where the business owner describes their vision. You can see the main elements of this document in Figure 3.

The product owner updates the epic description every quarter, with help from the business analyst, along with their budget needs.

Challenge: Once the epic description is defined, it goes directly to the team tasked with designing and realising the solution. This creates a potential gap between strategy and execution; if you move to the solution too quickly, the scope, dependencies,and core of the change can easily be misunderstood.

Tip: Include an architect in Sprint 0, to help create a product, process and system architecture. This ensures a clear picture of dependencies with other products, processes, and systems (application components, system software, and devices) from the outset, and gives you a common view of the scope of the change.

Phase 2: pre-sprint

The goal of the pre-sprint phase is to define the minimum viable product (MVP). To achieve this, it’s essential to gain an insight into the primary process.

At FIXIT Damage Insurance, a workshop with business owners and subject matter experts provides the input needed to define the project’s first user stories and define the MVP.A more detailed exploration of the work process will still be necessary before we can understand the true nature of the change needed. This will follow during the development sprint phase.

Challenge: The product owner might need to understand the requirement in advance, so they can estimate realistic development costs and time. However, the preparation phase only provides an outline, with detail following later.

Tip: The business analyst can use architecture models to clarify which products, channels, chain parties, processes, and systems are in scope. This helps to focus discussions, and gives a good basis for determining broad resource impacts.Working with the architect from the preparation phase can add further value.

Bonus tip: Use these same architecture models when communicating with stakeholders. This helps to establish a clear, unambiguous language about the situation and the requirement.

Challenge: In the preparation phase, the original epic description described the reason for the change. However, the strategy is further refined during the pre-sprint phase, which also has an impact on the epic in turn. It’s important to stay flexible, and ensure the epics reflect any change in strategy.

Tip:The business analyst can use a motivation model to understand strategy and epics in detail.This model shows the goals and motivations of stakeholders, as well as which epics contribute to which goals, so the relationships are always clear. Figure 4 shows how the motivation model might be applied.

Phase 3: development sprints

The development sprints design and realise changes to information systems, processes, and organisational structures.The starting point is always the same: your product, service, and process designs, within the broader framework of your architecture.

We design and analyse processes two –sometimes three –sprints ahead of realisation. This gives enough time to make a well thought-out process design that really lets us understand the new way of working. Then, we can identify the functionality needed to make it happen.

As well as the process itself, the design includes linked user stories. We work with stakeholders to identify which stories are relevant for each process step –both for the MVP, and any potential further development.

We add a single user story for each action if needed. This ensures they all have a comparable depth or granularity, and improves our sprint and release planning.

The business analyst works with subject matter experts and developers to create an activity diagram, making the interaction between the user and the system visible. We can then identify any data that is requested, processed, or sent in those actions. You can see this in more detail in Figure 5.

Challenge: Capturing epics and user stories in a dedicated system makes it difficult to show the link to the process. Even detailed labeling and categorisation may not give the full context–and business owners are unlikely to consult the system on a regular basis. It’s therefore hard to ensure cohesion.

Tip: Our starting point for process and information analysis is always a process design, which includes a process model and explanation. Because the analysis links the user story to the relevant process step, the content and added value are easy to see.

The model and stories can stay in a Microsoft Word document until a 0.9 version, with a fixed format which makes it easier for stakeholders and subject matter experts to review. Only after this is complete do we transfer the user stories onto the system, where they’re divided into epics.

There are four similar kinds of damage processes that partially use the same basic functionalities. The number of user stories increases over time, to illustrate the specific and generic functionalities for each sister process. This could create an overwhelming number of user stories, so they’re aggregated, with only new stories shown.

In Figure 6 below, you’ll see how we use colour to ensure the MVP is always clearly indicated within this story map. This is used as a further communication tool with business owners and stakeholders.

Challenge: Over the course of the project, a delivery from another team might have a major impact on our schedule–in our example our initial MVP, the entire process for one product, is adapted to a single process step: acceptance of notification. Other teams’ changes can potentially become overwhelming.

Tip: Use architecture models to visualise when your project depends upon deliverables from other teams. Product owners can then choose relevant stories where teams can collaborate in a planned way.

It’s important to agree a shared priority, to prevent changes in the plan, and a short weekly meeting provides a forum for all product owners, architects, and business analysts to monitor dependencies and arrange their collaboration.

Challenge: During the process, business owners want a detailed view of what will be delivered. We have the story map, but it can still be a bit too general and rather static. We need a way to keep business owners informed about status and progress at the user story level.

Tip: As well as the generic story map, we create a story map on the wall, on brown paper. The format is the same as the story map, but more detailed, and it covers the whole process in scope,two sprints in advance.

The team uses this map as a reference point to allocate work. The product owner uses it as a communication tool for the stakeholders. It’s also the reference model for future deliverables.

Challenge: The product owner prioritises user stories from the backlog, which are refined prior to the sprint. However, these refinements often run out of time; it’s important to ensure there’s enough space for them in the schedule.

Tip: There are three steps which we’ve found can bring significant improvements:

1. After the process and information analysis, discuss all the user stories within the scope of a work process with the relevant product owner and subject matter experts. The business analyst should ensure all aspects are discussed, and explain how the stories relate to each other.
2. One sprint in advance, go through all the stories in line with the “three amigos” approach. Involve the developer, business analyst, and subject matter expert;an architect or information analyst can sometimes be useful, too,for technical details and connections. This way, team members are always well informed.
3. Reduce the size of the refinement team. Avoid turning the refinement process into a “polish day”; instead, limit the team to the developers who will actually build the software

Finally, remember the designs business analysts produce are not always well understood by all stakeholders. Sometimes, other visualisations (based on our models) can be useful to seek feedback or share information. A simplified representation of how a case goes through the process can be especially useful in an implementation sprint.

Phase 4: implementation sprints

During the implementation sprints, changes are implemented to the organisation’s work processes, and software is taken into production. The most important activities in this phase are training and communication about the change.

When the user stories for the minimum viable product are ready, they can be implemented as a whole. The biggest challenge here is ensuring a minimum viable process, so the organisational changes and the supporting software both need to be ready.

Often, one work process is too limited in scope to be implemented on its own. For example, the work process “pay claim” needs to be implemented simultaneously with, or connect to, the existing payment process. And it must be possible to add a new recipient when processing a payment claim.

In our fictional example, FIXIT Damage Insurance, the business analyst trains the users, and creates animations and mock-ups of the process. The analyst stays handy to answer questions, and is already making user stories ready for the next sprint while implementation is underway.

Challenge : One risk of performing analysis two or three sprints ahead of realisation is that too much work can be done up front. It’s difficult to maintain enough of an overview to prevent duplicating work with other, similar processes that have overlapping functionality.

Tip: The story map is a useful tool that can show you any stories that potentially use the same functionality. You can then delay detailed work on these particular stories until the sprint prior to realisation – working with the product owner and relevant stakeholders to deliver them just in time.

Conclusion and roundup of tips

Using the established Agile phasing is a good way to gain an overview of the business analyst’s role in the process, and the value they can add.

For us, the Novius Business Analysis Framework is an important tool. It includes different models which we can combine to suit the unique needs of each project, and ensures the service, the process, and the application functionality are all designed in a coherent way.

Referring to our fictional FIXIT Damage Insurance example, the value added by the business analyst is clear at all four phases of the Agile change process:

• Preparation: Supporting the architect and business owner by developing the architecture and mini business case, and drawing up formats for the progress reports.
  
  
• Pre-sprint: Supporting the business owner by populating the backlog, setting up the story map, and making progress reports.

• Development sprints: Designing processes, performing information analysis, and recording user stories. Also creating activity diagrams, working with stakeholders about the content of designs, and ensuring the designs were coherent. And providing explanations and advice during the refinement process.

• Implementation: Providing user training, engaging stakeholders by creating simplified representations of designs, and acting as a helpful information source after implementation.

Finally, for convenience, here’s a summary of the insights we’ve gleaned during this agile way of working:

• Include an architect in Sprint 0, to help create a product, process and system architecture. This ensures a clear picture of dependencies with other products, processes, and systems (application components, system software, and devices) from the outset, and gives you a common view of the scope of the change.
  
  
• The business analyst can use architecture models (if necessary with a business view) to clarify which products, channels, chain parties, processes, and systems are in scope. This helps to focus discussions, and gives a good basis for determining broad resource impacts. Working with the architect from the preparation phase can add further value.
  
  
• Use architecture models (if necessary with a business view) when communicating with stakeholders. This helps to establish a clear, unambiguous language about the situation and the requirement.
  
  
• The business analyst can use a motivation model to understand strategy and epics in detail. This model shows the goals and motivations of stakeholders, as well as which epics contribute to which goals, so the relationships are always clear.
  
  
• Our starting point for process and information analysis is always a process design, which includes a process model and explanation. Because the analysis links the user story to the relevant process step, the content and added value are easy to see.
  
  
• The model and stories can stay in a Microsoft Word document until a 0.9 version, with a fixed format which makes it easier for stakeholders and subject matter experts to review.
  
  
• Use architecture models to visualise when your project depends upon deliverables from other teams. Product owners can then choose relevant stories where teams can collaborate in a planned way.
  
  
• As well as the generic story map, create a story map on the wall, on brown paper, covering the whole process in scope, two sprints in advance. Use this to allocate work, and as a communication tool for stakeholders.

There are three steps which can significantly improve the refining process:

1. After the process and information analysis, discuss all the user stories within the scope of a work process with the relevant product owner and subject matter experts. The business analyst should ensure all aspects are discussed, and explain how the stories relate to each other.
   
   
2. One sprint in advance, go through all the stories in line with the “three amigos” approach. Involve the developer, business analyst, and subject matter expert; an architect or information analyst can sometimes also be useful for technical details and connections. This way, team members are always well informed.
   
   
3. Reduce the size of the refinement team. Avoid turning the refinement process into a “polish day”; instead, limit the team to the developers who will actually build the software.

 The story map is a useful tool that can show you any stories that potentially use the same functionality. You can then delay detailed work on these particular stories until the sprint prior to realisation – working with the product owner and relevant stakeholders to deliver them just in time.

It’s true that business analysis has no formal role in Scrum, SAFe, or other Agile Methodologies. However, considering the above, it seems clear that a business analyst has a lot of value to offer your Agile change process.

If you’d like to know more about our business analysis offer – or the kind of work you could be doing in a business analyst role – I’d love to hear from you.