Skip to main content

Tag: Agile

The Power Of Scenario Planning

Written by Christina Lovelock on . Posted in Articles. 1 Comment on The Power Of Scenario Planning

True busines agility is achieved by considering what might happen in the future, and developing an outline response.

No one could have PREDICTED the current global situation, but some organisations were better PREPARED for it.

Whether you are delivering projects, products or services, it’s all about the future.

  • Increasing profit/market share
  • Increasing customer loyalty
  • Improving customer experience
  • Improving quality
  • Developing and retaining staff
  • Diversifying the offering
  • Decreasing costs
  • Reducing complexity

Each of these aims can be followed by the phrase “in the future”, as that is where they all reside. Most organisations believe they are thinking about the future, but they are usually just extrapolating the present, and that’s not the same thing at all. 

What is Scenario Planning?

Scenario planning is a strategic analysis tool which recognises the future is uncertain and unpredictable, and encourages us to explore how we can prepare for it.

There are three broad steps to scenario planning:

  • Consider what is the current reality for the organisation and wider world, and how that might be different in future.
  • Consider what those differences would mean for the organisation.
  • Act on this new knowledge. (This might be: develop a plan, mitigate a risk, explore an opportunity…).

There are many models that facilitate the process of scenario planning, which is usually run as a series of workshops with relevant stakeholders.

Advertisement

Advantages of Scenario Planning

1. Framework

Scenario planning provides an opportunity and framework for people to contribute their fears and ideas in a legitimised and structured way. It’s proactive, and removes some of the worry of being perceived as ‘doom-monger’.

2. Awareness

It encourages us to think outside of our organisational boundaries, and lift our heads from the day-to-day rhythm and routine of work. It asks: what’s going on in our organisation? our sector? the wider economy? in society? for our customers? for our suppliers? and for our staff?

How might this impact our organisation in the future, and what can we do about it?

3. Calm

Scenario planning allows options to be really evaluated, and decisions to be taken before a situation actually occurs. In the face of a crisis, organisational and individual biases can cloud could good judgement, speed of response can overlook better options and fear and blame can impact relationships. It creates the time for a ‘plan for a plan’. Scenario planning offers no certainties, but gives the opportunity to identify indicators: “If we start to see X happening, then person Y will do Z”.

(Yes, some people supposedly thrive under pressure and enjoy adrenaline fuelled situations, but this is not business agility.)

4. Competitive advantage

If we are considering the future and preparing for it while others are not,  this gives us a clear advantage. We will be able to respond rather than react, move more quickly and demonstrate our organisational agility.

Common Traps of Scenario Planning

1. ‘Waste of time’

Because many, perhaps most, of the scenarios won’t actually happen, investing time in thinking about them may seem like a waste of time and effort. This may prevent a full range of scenarios from being effectively developed and discussed.

Most people have enough to worry about in their ‘day job’, and do not want to go exploring for further problems. This is narrow thinking and prevents business agility.

2. ‘Lack of imagination’

Some people cannot imagine a different world, and others can imagine it but are embarrassed to describe it. Many organisations do ‘financial planning’ by using a small number of variables (costs, predicated growth etc.) and model best, worst and most likely scenarios. This is safe thinking, and is unlikely to lead to any major breakthrough in organisation

3. ‘Overwhelmed’

It would be relatively easy for even a small group to come up with dozens of plausible scenarios, and generate hundreds of potential actions in just a few hours. Generating the scenarios, then narrowing them down to a manageable number is part of the processes. The discussion about the potential scenarios is often more valuable than identifying every possible future.

4. ‘File in the draw’

If no action is taken as a result of the scenario planning, then the value of the exercise will not be realised. ‘Action’ could range from agreeing options or decisions that will be made in certain situations to making significant changes in strategy or operations as a result of the information the exercise has revealed.

Conclusion

Organisations which can adapt will survive and thrive. The ability to adapt quickly is about giving people the time and space to consider how to respond to a range of scenarios, most of which will not come to pass. But for the ones that do – we ‘ll be ready. For the scenarios we didn’t see coming, our organisations will be more able to adapt because we recognise that the tomorrow cannot be extrapolated from today.

Reference:

Scenario Planning, Woody Wade, 2012

Getting Requirements Right with KickOffs and Desk Checks

Written by Maria Rios on . Posted in Articles.

Have you ever been at a restaurant and received something different than what you ordered? 

I’ve had unwanted sour cream on my nachos and swiss cheese in my omelet instead of provolone.  Even if it was close to what I requested, I often returned my food to the kitchen to get it fixed.  Waste of time for both me and the cook, not to mention I would be hungry by the time I got my food.

A similar experience has happened to me with software development.  As an Agile organization, we regularly hold lead reviews and story grooming sessions.  Despite numerous meetings, I sometimes found myself in a situation where what a developer coded is not exactly what I asked for.  How is that possible after hours of discussions?  The answer is simple.  Human nature.  What one hears may be interpreted differently by someone else. Memory isn’t always reliable for stories reviewed a few days or weeks before.  Also, until a person is the one working on a story, he/she may not be listening 100 percent during team activities. 

As any developer and QA engineer can tell you, building something that doesn’t match the requirements requires rework and retesting, which impacts a team’s ability to meet sprint commitment.  So how can we minimize wasted time? My department has adopted the following practices which have reduced the botched order syndrome significantly:

  • Story Kick-Off
  • Story Desk-Check

Story Kick-Off

A story kick-off is done prior to coding to ensure that the developer, QA and the BA/Product Owner are in alignment regarding expectations.  Asking the following questions helps to ensure a successful kick-off.

  • Are the requirements clear? 

As the BA, I review again all assumptions, the acceptance criteria and any supporting documents, such as UI and report mock-ups.  Everyone’s memory is refreshed, and the opportunity exists to answer questions and to ensure everyone is on the same page.  In addition, the wording within the story may be modified or additional notes added to provide clarity.

  • Do we have all the technical tools and information needed to finish this story? 

Our developers perform preliminary investigation prior to a kick-off to determine what is needed from a technical aspect.  When issues affecting completion of the story are identified, negotiations around requirements commence.  For example, we may find that a new function cannot leverage existing code as initially anticipated.  I often ask whether the extra effort can be absorbed in the current story without impacting timelines.  The outcome may involve conversion of an acceptance criteria into its own story or pulling the story from the sprint altogether for additional refinement.

Advertisement
  • Are there any blockers?

We normally identify story dependencies ahead of time and plan sprints accordingly.  Due to resource constraints, we sometimes find ourselves playing blocking or dependent tasks within the same sprint.  If called out during kick-off, it reminds us to coordinate activities across the team to help ensure timely completion.

  • Will assistance be needed from other departments in order to complete coding or testing?

If yes, we like to inform those groups at kick-off, so they have a few days to plan accordingly.   As an example, we may need DevOps to bring a connection down to test failure scenarios.

Story Desk-Check

A story desk-check is performed when coding is completed but not yet pushed to a test environment.  The participants include the same people involved with the initial kick-off.  Activities include the following:

  • The developer demos the functionality that he/she has built while cross-checking against the requirements of the story.

Have all the acceptance criteria been met?  Does the output, such as UI screens or reports, match the mock-ups?  Are any bugs encountered during the demo?  If identified at that time, the developer can more easily fix issues in their local environment before it even gets to QA.  Problems found sooner contributes to less bug finding during testing which equates to time saved.

  • Provides the opportunity to tweak a requirement. 

A demo sometimes identifies requirements which sound good in theory but does not work well in reality.  For example, we may find that an error message that I’ve requested is hard to see.  I could ask that the error be moved to a more prominent location or be highlighted in red.  If the impact to the sprint is small, the developer and QA can agree to the modification and the story is updated.  For larger efforts, I create a new story to be placed in the backlog and prioritized.

  • Helps QA prepare for test execution.

The developer provides input on how a story can be tested.  Are there tools available to help them verify the data?  What configuration or setup is needed prior to testing?  Impact to existing functionality is also called out so that they can be retested to ensure nothing is broken by the new code.

  • Other groups participating in the desk-check, such as DevOPs, become aware of when their assistance will be needed and can schedule their time with QA.

Two years after initial implementation, kick-offs and desk-checks continue to be an important part of our development process.  It is extremely satisfying to see how minutes invested up front saves us from hours of rework later.  There’s always room for improvement, but in the meantime, I am happy to say that what development now gives me is usually exactly what I ordered! 

The A to Z of Business Analysis

Written by Christina Lovelock on . Posted in Articles.

“What is business analysis?” There is no snappy ‘definition’ of business analysis, but we know it when we see it.

It is hard to answer this question directly, so let’s consider some of the key the elements and areas of concern that constitute business analysis.

A Analysis

Let’s start with the basics. Analysis means to investigate or examine something carefully in a methodical way. So to do analysis you need to pick an area of focus, study it, see where it leads, find the right people, ask good questions, consider all aspects, apply logic and reasoning and use the full range of tools and techniques at your disposal. When we create an over simplification of analysis such as “write user stories” or “draw swim lane diagrams” we loose the essence of the of analysis.

B Business

The ‘business’ part of business analysis means the whole organisation or enterprise. From top to bottom, inside and out. Everything; including the market and context it operates within, its employees, customers, systems, structures, strategy and processes. The not-for-profit and public sector sometimes struggle with the idea of their organisation as a business, but business analysis is equally relevant in every organisation and every sector.

C Communication

‘Good BA with poor communication skills’ is an oxymoron. It is not possible to be a truly effective business analyst without good written and verbal communication skills, which you can tailor to the situation and the audience. Business analysis cannot be conducted in isolation, it requires collaboration. Collaboration is underpinned by good communication

D Diagrams

Visual communication is critical for project success. BAs need to be able to distil an hours’ conversation or a 20 page document down to a number of boxes and lines, to build understanding, alignment and agreement. This often takes bravery, and willing to risk being wrong.

E Empathy

Empathy is a core component of Emotional Intelligence, which all BAs need to strive to develop. Empathy allows us to see different perspectives, mediate between groups and understand the full impact of the changes we seek to introduce in our organisations.

F Facilitation

We provide a set of skills, process and techniques which support and enhance group working. This includes clarifying objectives, encouraging participation, practicing active listening and building commitment and ownership. These skills are not limited to a role within workshops, but an ongoing contribution BAs make to the success of change initiatives.

G Global

The International Institute of Business Analysis (IIBA) [1] has more than 120 chapters all over the world. The profession is truly global, and exists in every industry and sector. Stand tall in the face of confusion and ignorance of our profession, you are part if something big.

H Holistic

We recognise that everything is interconnected and interrelated. We know process improvement will effect people, and system upgrades will impact data. BAs must always keep POPIT ™ [2] in mind!
By practicing an holistic approach to problem solving, we help our organisations address the real problems in the right ways.

I Information

Business analysis is obtaining, interpreting and presenting information. Business Analysts sometimes shy away from business information, and align themselves to process modelling rather than data modelling. Data and process are two sides of the same coin. Processes generate and consume data. Data must have a lifecycle and inform organisational processes such as decision making.

J Just enough and just in time

This has been a tricky transition for BAs. We like detail, rigour, even perfection. The acceptance that sometimes good enough is good enough is hard, and the concept of delivering a minimum viable product has taken some getting used to. We must continually challenge ourselves to avoid gold-plating and recognise the right thing is not always the best thing.

K Knowledge

BAs need to be able to build up knowledge of a new business area, domain or industry very quickly. BAs should be brining business analysis skills and knowledge to the table, but rely on others to be the authority on subject matter expertise.

L Learning

Continue professional development is critical for BAs. We are naturally curious and want to know more about our organisations, our professional discipline and how learning from other disciplines can help us improve the practice of business analysis. (So yes, we ask a lot of questions!).

M Mindset

BAs must cultivate curiosity and have a continual service improvement approach. Business analysis is a broad discipline, with so much to learn – we must encourage a growth mindset for ourselves and our organisations.

Advertisement

N Needs

We go to lengths to separate wants from needs, and problems from solutions. BAs must navigate the political minefield of prioritising business needs; know when to challenge and when to concede, and remain objective and neutral as far as humanly possible!

O Objectives

Finding purpose, asking why, recognising assumptions and understanding what we are trying to achieve. Setting goals and objectives is critical to business and IT enabled change, BAs have a big part to play identifying problems and opportunities and agreeing objectives.

P Process

Process modelling, analysis and management is a key aspect of business analysis, but it is not the sum total of business analysis. Process analysis is a means, not an end. BAs must understand the purpose of process analysis, the value it offers organisations in terms of consistency, improvement, efficiency, training, knowledge management and competitive advantage.

Q Quality

In the time-cost-quality triangle, BAs are typically more concerned with quality, and PMs and other roles are typically more concerned with time and cost. Ensuring quality means ensuring that what is delivered addresses valid business needs and is fit for purpose.

R Requirements

Requirements Engineering is a professional discipline. It covers elicitation, analysis, validation, documentation and management (no ‘gathering’ in sight). Yes, anyone can write requirements, just as anyone can paint a wall. When you want it done right, you call in a professional.

S Stakeholders

Structured and rigorous stakeholder analysis is often overlooked. BAs have techniques to identify and analyse stakeholders and involve the right people in the right way at the right time.

T Technology

Digital Transformation and IT enabled change form a key part of many change initiatives. BAs must have sufficient technology knowledge to understand the landscape, ask the right questions and identify options and issues. BAs must not be intimidated by the technology, just because they are not ‘technical’.

U Users

User Journey | User Story | UAT. BAs must really know the users, and champion user needs and views when they are not in the room. The BA must act as the conscience for the project on all decisions made.

V Value

By collaborating with stakeholders, BAs can co-create value in our organisations [3]. This involves identifying where value might be offered, developing a solution and ensuing the value is actually realised.

W Work Package

We can analyse anything, but without agreed scope, timeframe and deliverables, the outputs we produce are unlikely to meet the expectations of others. Creation of a simple work package enables discussion on the focus and purpose of the business analysis needed.

X eXperience

UX and CX. These specialisms don’t exist in every organisation, so BAs need to be prepared to support projects and products in this space. By ensuring that non-functional requirements are brough into the conversation, we can ensure that expectations are understood and experience is considered.

Y “Yes, and…”

Typical BA responses to any question are often: “It depends…”, “Yes, but…” and “No.”. This has given us a bit of reputation for being negative/blockers. By reframing our natural responses to build on the ideas of others, we can bring forward our concerns in a constructive way.

Z Zoom

(…and Skype, GoTo Meetings, MS Teams and more!). BAs have placed much faith in face-to-face, and now need the confidence to adapt our methods to be virtual-by-default.

Conclusion

Many professions operate without a ‘definition’. What’s the definition of a painter and decorator? Someone who does painting and decorating. Yes its self-referential, but we can all imagine what this involves. Let’s help our customers and stakeholders understand what business analysis involves, by demonstrating the breadth of what we have to offer.

Further Resources:

[1] IIBA Chapters: www.iiba.org/membership/chapters/
[2] POPIT™: www.assistkd.com/knowledge-hub/business-alchemists-blog/reimagining-popit-model
[3] Delivering Business Analysis, Paul and Lovelock, BCS 2019: www.amazon.com/Delivering-Business-Analysis-Service-handbook-ebook/dp/B07XTM9LT9

4 key activities for a Business Analyst in the Alpha phase

Written by Nick Stowers on . Posted in Articles.

On one of my earlier blogs, I described what I thought are the 3 key activities a BA should be doing when they were in a Discovery phase of a project.

The feedback I received was positive so I thought I’d give, what I consider to be are the 4 key activities are for a BA in an Alpha phase.

So what exactly is an ‘Alpha’?

In the UK, the Government Digital Service (GDS) defines the phases in an Agile delivery lifecycle as; Discovery, Alpha, Beta, Live and Retiring the service. GDS also cover in detail how the Alpha phase works, but what’s not covered in the article is what each role in a delivery team does within an Alpha, including Business Analysts.

If you’re not familiar with the names of these phases, they are the same for pretty much all Agile project delivery. The most common themes I’ve come across are;

  • Concept, inception, iteration, release, production, retirement

Moving Discovery outputs in to an Alpha

Key outputs from the Discovery the BA should have been heavily involved in include:

  • Stakeholder analysis
  • Understanding and defining the problem
  • Starting the product backlog

Each of these outputs now need to be taken through in to Alpha by the BA and here’s how.

Advertisement

Stakeholder analysis – Use your stakeholder knowledge

An Alpha to me is the exciting part of the Agile delivery lifecycle as this is where you actually start putting ideas and concepts in front of users and you learn ‘how’ they will really interact with your product and get valuable feedback. To ensure you get as honest and realistic feedback as possible, it’s important to try and create as real-life scenarios as possible to test the prototype with users. To do this, the BA should use their knowledge of working with stakeholders in Discovery and take this in to the development of the prototype with the designers on the team. After all, if you were the BA involved in Discovery, one of your key outputs is understanding the users and their needs, and that includes the needs of the business. Therefore, armed with this insightful knowledge, you should work closely with the design team to ensure they also understand the users. 

Understanding and defining the problem – Keeping the product vision in view

During Discovery, the team will have (or certainly should have) defined the problem that needs to be fixed and from that, a product vision should also have been defined. Roman Pichler has an excellent article on how to create a compelling product vision which I highly recommend you read as well as all the other articles he has on his website. 

For me, the product vision is one of, if not the key outputs from Discovery and is something that should be visible and referred all the way through the delivery lifecycle. All too often I’ve seen the product vision put up on the team wall (or worse, in a folder on the Product Owners laptop) but no one seems to take any notice of it and it becomes just a part of the wall space along with user research findings, sprint boards, etc. To make sure the product vision stays in view, and you have wall space, have it beside your user story map (coming up in the next section). Pretty much everything that’s in your user story map should stem from the product vision, so keep them close together.

Starting the product backlog – Make sure prototypes stem from user needs (building your user story map)

How prototypes are developed is different for all teams but in my view, the quicker you get to an interactive prototype, the better. I’m all for sketching out designs to protect costs and save time, but only once a prototype is in the hands of users and seeing their interactions with it, will you start to get valuable (and workable) insights to develop the prototype further. And remember, as the BA, you’re going to start building the product backlog based on the findings and create your user story map. If you’re even half serious about being a Business Analyst, I don’t need to tell you the powerful impact of user story mapping but if you need reminding, here’s Jeff Paton (the guy who came up with the idea of user story mapping) showing you how to create one. 

Help the team design iteratively

Having your user story map on the team wall (or online if you are a in several locations. I recommend www.storiesonboard.com as a user story mapping tool) is a great way to galvanise the team and ensure what you’re doing aligns with the product vision (hence having the vision next to the map). As we know, agile delivery focuses on building products in an iterative way and this principle should apply to designing prototypes in Alpha. I quite often see designers go off and start building complex, end to end user journey. For this very reason, having a user story map will encourage the design team to not think too far ahead. After all, your map will have an ‘MVP’ (or Release 1 if you’re not comfortable with the term MVP) swim-lane where you’ll define as a team what features will (or might) go in the MVP and this is what the design team should be focusing on prototyping.

And finally…

Don’t misunderstand me, and this is based on the feedback from my ‘BA in a Discover’ blog, these are not the only 3 activities a BA will carry out in an Alpha and you will no doubt carry out more than this (e.g. writing the user stories for Beta, working with technical architects/software developers to ensure what is being designed and tested with users can actually be built, continually developing the backlog, etc) however I’ve seen projects where the BAs have not been involved much in the design process and this which has led to problems further down the delivery process. Remember, you as the BA are the bridge between the design team and the developers/testers!!

An Alpha (or iteration) phase can last several weeks and if you as the BA follow these activities, you’ll ensure the product is designed with the users in mind, in an iterative way, and that when you get to the Beta phase (blog coming soon), your product will be delivering the value defined by the product vision.

Impostor Syndrome: Business Analysis Is NOT Just Common Sense

Written by Christina Lovelock on . Posted in Articles. 1 Comment on Impostor Syndrome: Business Analysis Is NOT Just Common Sense

Impostor Syndrome seems to be particularly prevalent within the Business Analysis community. It’s time to consider why that might be, and how we can overcome it together.

Impostor syndrome is characterised by:

  • feeling like a fraud (“When are they going to figure out I don’t know what I’m doing?”)
  • believing success is unearned or just ‘lucky’ (“I was just in the right place at the right time”)
  • being plagued with self-doubt (“Who am I to do this?”).

When BAs hear about Impostor Syndrome, we experience a lightbulb moment. (“I thought it was just me!”).

BAs often down play our skills and effectiveness, we say things like “I didn’t really DO anything, I just got the right people together and asked the right questions” as if this is not an incredibly valuable skill!

Do not mistake the logical and sensible outcomes we are able to reach, due to many years of experience and developing our skills, as ‘common sense’. We have trained ourselves to be objective and see different perspectives. We have learned a wide range of techniques for engaging people appropriately, obtaining information and conveying that information in the best way possible.  

Business Analysis is a professional discipline, is growing in size and expanding around the world, it is supported by recognised qualifications and professional bodies. If some friends and colleagues don’t know what Business Analysis is – that doesn’t mean it’s not real or not valuable.

Here are some of the factors contributing to widespread BA impostor syndrome:

It’s just common sense:

Application of logic and evidence driven decision making can look like common sense, especially if our approach and techniques are not made visible to stakeholders. We forget that the tools we are familiar with, and the logical process we apply are not personality traits – they are our professional skills, honed and improved over many years of practice, and not everyone has these skills.

Anyone can call themselves a BA:

Unfortunately, anyone can start calling themselves a BA, and anyone who has ever facilitated a workshop or written some requirements can believe they have the BA skill-set. As a profession we can make it easier for employers to differentiate between genuine BAs and BAs-in-name-only by having membership of BA professional bodies including IIBA and BCS, by undertaking professional qualifications, by engaging with the professional community online and at events and we can encourage the BAs-in-name-only to up their game as well!

Just fell into it:

Most of us did not set out to be BAs. In fact, when we were making critical life choices about what to study and where to live, we did not even know the role existed. The fact that we have become BAs by accident doesn’t mean that we have to apologise for it, or play down how much we enjoy it or excel at it.

Advertisement

Not a ‘real’ BA:

Some genuine BAs feel that they have come to the profession from circuitous route, or had a different path for them selves in mind. These BAs have often locked-in their professional identity to their industry, rather than their profession. For example, BAs in the financial sector who started their career in branch of a bank may believe it is their business knowledge, not their BA skill-set that allows them to do their job. If you have the skill-set and responsibilities of a BA, it may be time to allow yourself to see this as your professional identity.

What does a BA do?:

The BA role can look very different in different organisations and even within the same organisation. The BA role is no longer ‘new’, but there is still a great deal of role ambiguity [1]. Constantly having to explain the BA role can be tiresome, and make us question why it is not understood.  

Not technical:

Many BAs have a role in IT-enabled change, and can feel they have to apologise for not having a technical background. This can lead to a feeling of ‘anyone could do my job’ because we don’t have specific technical skills, like writing code. The skills we do have are just as valuable, and often more scarce within the tech industry!

There is no role for the BA in agile:

Some organisations and individuals, sadly, still hold this view, and BAs can find it crushing. BAs have consistently proved our contribution in all software development approaches, and the core of our professional discipline is strong enough that we should not feel pushed out by other specialist roles, such as UX, UR and PO.

The business have written their own requirements:

The implication here is that a group of business users can figure out what they need, document it and convey it to developers and or suppliers. We know that 9 times out of 10 this will not end well, but instead of feeling offended or excluded, we need to work with them to build the trust they need in our profession.

So what can we do about it?

  • Understand that impostor syndrome exists, and the majority of people experience it at some point in our lives [2].
  • Consider which of these BA impostor-factors are effecting how you see yourself and how you behave.
  • Talk about it! Find someone you trust, or engage a coach, and discuss your feelings in relation to your role and profession.

Conclusion

By allowing ourselves and our stakeholders to believe that ‘business analysis is just common sense’, we may become valued as individuals but we will never demonstrate the value of the professional discipline. This occurs frequently in organisations when certain individuals are constantly requested within a BA Service, as it is the individual BA who is valued and trusted, not the application of business analysis.

We must continue to stand-up for the activities we know need to happen that contribute to the successful delivery of software, projects and change initiatives. We must leave every stakeholder we encounter with a better understanding and appreciation for business analysis that when we met. And finally, we must value our skills, believe in our role and not see ourselves as impostors in our industry.

Further reading:

[1] Dr Debra Paul (2018) Defining the role of the business analyst.  http://centaur.reading.ac.uk/80476/1/86223494_Paul_Thesis.pdf

[2] Dr Pauline Rose Clance (1989). Take the Impostor Phenomenon test: www.paulineroseclance.com/pdf/IPTestandscoring.pdf