Applying Agile techniques in a waterfall environment as a Business Analyst

explore-assurity 5 January 2015 Cheng-Wei Liu

Do you have to be in an Agile team to be able to apply Agile techniques? The answer is no. Cheng-Wei Liu describes how our BA team recently applied Visual Management in a client’s Business Analysis practice.

The context

Recently, I – along with another Senior Business Analyst (BA) from Assurity – have been working on a project where we’re responsible for the eliciting, gathering and creation of functional requirements in the form of use cases for a large state-owned corporation (SOE).

The project is currently in this organisation’s Development (or Delivery) phase of the Project Execution Framework.

Cheng Wei TP2 v2

What problems did we face?

The project entered the Delivery phase with around 150 high-level business requirements. As the vendors started the software development process, they had many questions around the detail of these requirements and, as a result, their developers were unsure of what they had to build.

You might be asking, ‘This sounds ridiculous. How could the developers not know what to build? Aren’t there 150 requirements sitting in front of them?’

If you take a step back and think carefully about what these requirements are, you will realise that the term ‘business’ requirements implies that these requirements describe the business’s needs or product desire. Furthermore, these requirements were gathered to help give a rough estimate on the feasibility of the project and to help Senior Management make an informed ‘go’ or ‘no-go’ decision at the project portfolio level.

In contrast, what the developers really needed were requirements specifying what the product must do – for example, the actions it must perform to satisfy the fundamental reason for its existence. These are called ‘Functional Requirements’ which did not exist in this project.

More BA effort was required to elicit and create these functional requirements, along with the Subject Matter Experts (SMEs) to help the vendors develop a solution design.

As a result, the BA team began creating business and product use cases scenarios to illustrate the functionality needed to fulfil the 150 business requirements.

Around 50 use case scenarios were defined and the team then quickly prototyped one use case for two specific reasons – first, to get a rough estimate of the total effort required to complete these tasks and give the Project Manager the necessary information to help re-base the budget and update the project plan. Secondly, to agree with the business stakeholders and vendors on the level of detail required in the use cases.

As we progressed through the creation of the remaining use cases, the project managers pushed to meet the delivery deadline. It wasn’t long before we realised we were beginning to multi-task across many different areas, while thinking we were getting through the work quicker or being more productive.

Fortunately, it didn’t take us too long to start questioning whether we were actually being more productive or not. Our answer was a simple ‘no’. What we were actually doing was task switching, resulting in a significant loss in productivity.

Work was also becoming much harder to manage and coordinate due to a lack of visibility on what each of us were working on and we were often carrying out project work that wasn’t budgeted for in the project plan. We called this ‘invisible unplanned work’ because we had no transparency or any feeling for the magnitude and number of the tasks we were doing.

Making the change

You might have heard the saying “You can’t manage what you don’t measure” – and, in our case, we felt we were lacking visibility of what everyone was doing. We decided that Visual Management would be a great place to start so we could visualise our work and workflow.

We started by creating a list of things we knew we had to do – relatively easy as we already had a list of previously unidentified use case scenarios. Typically, each of these use cases would take between one to three days to complete (but one to two weeks for a UC to be signed off). So we would break down the use case sticky note into tasks such as:

  • Brainstorm use case
  • Map use case processes
  • Create requirement document
  • Consult with SME
  • Consult with vendor
  • Walkthrough with internal BA team
  • Walkthrough with SME
  • Walkthrough with vendor
  • Corporate feedback

These tasks, within each work stream, would then travel through ‘To Do’, ‘In Progress’ and ‘Done’ to illustrate its status.

Any work not budgeted for in the original time estimate of time would be classed as ‘Unplanned’, using colour coding for unplanned stickers. And, every day, we would do a daily stand up to check progress. 

IMG 0020 v2

Impact on the business

Six weeks after implementing Visual Management on the project, the impact on the business and our productivity has been very positive. One key benefit has been that our progress is now visible to everyone, helping the team communicate progress to the Project Manager and business stakeholder and forcing us to each be accountable for our own area of work.

Now that we have visibility on what we were doing, we are able to change our working behaviour and are more organised in our analysis approach, promoting commitment and an understanding of where our bottlenecks are to re-focus our resource when needed.

We now focus on finishing rather than starting to reduce the amount of context switching and minimise loss of productivity. So when pushed by the business to start working on something new, the conversation could be: “Look at this board. If we can only ever work on five use cases at a time, which use case do you see as being less important for us to re-prioritise and ensure we are working on the right things at the right time?”

This exercise helps the Project Manager and business to understand and make informed decisions on which use cases have higher priority or value and which need to be completed first from a technical constraint perspective.

Making sure that ‘Done’ is really ‘Done’ was important for us because we often spent a lot of time answering the vendor’s questions about a previously completed use case. As we started to understand the amount of completed unplanned work, we decided not to flag the use case as ‘Done’ unless both the vendor and SME had been walked through the document and agreed to sign-off without any outstanding questions. This exercise helped us understand what tasks and processes we needed to do (to fulfil the Definition of Done) and follow and define what the acceptance criteria to complete each use case were.

Rather than handling all the use cases as one big batch, instead we were able to continuously deliver incremental value as soon as possible on finishing each individual use case and passing it off to the next phase of the waterfall (solution design).

The most interesting observation so far is that whenever someone walks pass our Visual Management board, they always take a quick look. This slowly generates people’s interest and eventually leads them to ask us what we are doing to break down silos in the organisation.

You may also want to read

explore-assurity

Assurity officially recognised as provider of Scrum.org training

As a member of the Scrum. org Professional Training Network (PTN), Assurity is officially recognised as a provider of Scrum.

More

explore-assurity

Explore the future of analysis at BA Development Day

BA Development Day will take place on 17 November at Shed 6 on Wellington’s Queens Wharf with the theme of...

More

explore-assurity

Turning a single JIRA status column into a Scrum board

On a recent assignment, I was responsible for testing changes in a System Integration Test (SIT) environment.

More