Tag: Best Practices

Navigating Multiple ‘Right’ Answers in Business Analysis

Written by Adrian Reed on August 28, 2024. Posted in Articles.

We’ve probably all experienced situations where there are multiple ‘right’ answers to a question. This is particularly true with questions that appear straightforward, but actually hide significant nuance. Let’s take a seemingly simple question;

“Who released the song ‘The Boys of Summer’?”

If you know the answer, you might instinctively reply “Don Henly”. However, if you said The Ataris, or DJ Sammy, you’d also be correct, all of these bands/artists have released the song. Depending on when you were born and the type of music you listen to, you might be familiar with one, many or none of those tracks. You might even know of other versions!

Equally, you might have interpreted the question ‘who released this song’ as relating to the record label or promoter. So you equally might have responded “Geffen” or “Universal Music Group”, and you’d have been correct…

If it’s hard to get a single ‘right’ answer to a seemingly simple question like the one mentioned above, what hope do we have when undertaking requirements elicitation? We might be seeking to understand how a particular process works today, how things could be improved, or perhaps we’re wanting to understand potential requirements for an IT system. People are naturally going to have different opinions and experiences.

Yet if different people have different ways of undertaking the work, or if there are different views on what ‘good’ would look like, what do we do? How do we avoid missing (or misunderstanding) crucial information?

Avoiding Elicitation Woes

There’s no silver bullet, but three key considerations are specificity, multi-sourcing and modeling.

Firstly, it’s worth thinking about the specificity of any elicitation activity. By this I mean what level of granularity are we seeking. If we are at the very beginning of an initiative, we might be seeking answers to very big, macro-level questions. These will help us determine what direction we should take and where we should follow up. By their nature, these questions are big and fluffy, and there can be a tolerance for error in the answers. “Do you think the claims process works well?” is a big, broad, question. If the answer is “no” then it gives us something to follow up on.

Equally, as we get closer to granular requirements, we ought to be seeking very specific information. It’s crucial to actively seek to understand key terminology and probe into specific areas. We might probe into particular areas where improvements are necessary, and this is likely to require uncovering more and more detail. Feeling empowered to ask “what do you mean by that?” is a must.

Specifying contextual information such as the timeframe or situation is key. “In 2003, which band released ‘The boys of summer’ from their album ‘So Long, Astoria’” is a more specific question than the one mentioned at the beginning of this article. Equally “once a potential insurance claim has been reported by a policyholder by phone, what determines what happens next? What rules or decision logic are applied, and how?” is a more specific question than simply asking “what happens with claims?”.

Embrace Multiple Sources

However much specificity we gain, rarely will one person (or team) have a full view of a situation or process. Seeking multiple sources of the ‘truth’ is important. How a procurement process works, and whether it is efficient or not, will depend on who you ask. A procurement team might think its processes are very efficient, but managers from other departments trying to procure services might disagree as they feel procuring a product or service takes too long. External service providers might have a different view, particularly if their invoices aren’t paid on time!

Understanding different stakeholders’ perspectives will help to gain a 360 degree view. This helps avoid situations where an improvement is implemented that works very well for one group, but makes life much harder for others.

Modeling for Validation

Elicitation and modeling are sometimes seen as separate activities, and I have never understood why. I’m sure I’m not the only person who has sat with a stakeholder and sketched out a process, then quickly shown my sketch and said “is that what you mean?”.

Creating informal models is a great way of ensuring that everyone is on the same page, and also a great way to spot gaps. It might identify that there are different teams undertaking a process in different ways—and one way of improving the situation might be to unify this.

Not only this, but having some kind of model to point at ensures that areas of agreement/disagreement can be clearly highlighted. Creating a shared model, whether that’s an ‘as is’ or a ‘to be’ model, ensures that people are on the same page. It helps avoid situations where everyone appears to agree, but different stakeholders have slightly different views on what should be done.

The Power of Perspectives

All of this highlights the power of perspectives. Typically different stakeholder groups each know a bit about a particular situation or process. The art is to get enough coverage, enough variety, sufficient perspectives, to see a feasible and desirable way forward.

Doing so will ensure that the end solution or product is one that the stakeholders actually want to use!

The Deadline Dilemma: Unpacking the Reality of Arbitrary Timelines

Written by Adrian Reed on August 15, 2024. Posted in Articles.

Perhaps I’ve been doing this job so long that I’ve become a little cynical, but I have a theory. I suspect that 80% (or more) of deadlines that are given are completely arbitrary. They are either based on ‘finger in the air’ guesstimates of when something is needed, or (in some cases) they are just plucked out of thin air. What is particularly difficult is when the person setting the deadline has no real idea of what the work is or how long the work will take.

An Example: The Deadline That Creeps Up

In a previous role, a long time ago, I was working on what I believed to be a very time critical deliverable. Once it was complete a senior executive would be using it, and I was told that the deadline was non-negotiable. The project manager was very clear: the work has to be completed, there can be no slippage. Initially, it looked just about achievable, so I set off doing my work.

As is so often the case, the work turned out to be more complex than anyone had realized. I escalated, and explained things were likely to take longer than anyone had assumed, and was told that there’s no chance of extending the deadline. Since I was enjoying the work and the deadline seemed so important I was happy to put in some late nights. Towards the end, I worked some weekends too, and just about got it over the line in time. I was tired, but it felt good as I uploaded the final version and emailed the senior stakeholder.

However, that feel-good factor soon faded when I immediately got a response: an automated ‘out of office’ explaining that the stakeholder was on vacation for a week. Investigating further, I find that yes, this person is on vacation, and this had been planned for a long time (they hadn’t taken emergency leave at short notice).

The deliverable wouldn’t be utilized for a week. There was actually a week of ‘slack’ built into the plan, but nobody told me. I could have slept more and I needn’t have worked the weekend…

My Bad: Not Asking “What Is The Implication Of This…”

It would be easy to blame the project manager or senior stakeholder in this story, but I don’t. In fact, it taught me something really important about deadlines. When a deadline is tight, it’s important to ask questions to understand how ‘hard’ and constrained it is. Ultimately here, we’re testing the constraints. Questions include:

There are many other questions too, and the intention here is to understand what is a real, immovable constraint and what isn’t.

Being Clear on Estimates

Equally, alongside asking questions, it is important to drive analysis deadlines on analysis estimates, rather than accepting arbitrary deadlines. There is often uncertainty, and if it is necessary to have a detailed plan up front, then the schedule ought to be based on a practitioner’s assessment of how long the work will take. If a deadline is found to be arbitrary or malleable, then planning forward and explaining what is possible in a particular timeframe can be a useful approach. Whatever approach is taken, getting regular feedback, updating estimates and pivoting accordingly is important, as is managing expectations.

In summary: understanding what is a real constraint and what isn’t is crucial. This can be achieved by asking provocative but important questions.

Decoding Stakeholder Signals: Beyond Formal Feedback in Business Analysis

Written by Adrian Reed on July 31, 2024. Posted in Articles.

If I asked you how often you get feedback from your stakeholders, what would your response be?

I suspect many people reading this will actively solicit feedback quarterly or annually for a formal appraisal process. That is very useful, but consciously created feedback of this type is only one source of valuable insight. Feedback is all around us, but it often requires us to look for it. However, it is well worth being vigilant, as when we spot feedback we can reflect on it and adapt.

Feedback as a Signal

Rather than thinking about feedback as something that has to be formally solicited, let’s imagine stakeholders let us know their thoughts, feelings and intentions through a series of signals, and those signals can be consciously or unconsciously given. Sometimes they’ll say something directly, other times we might need to read between the lines and observe their actions.

This is similar to driving a car. If you’re in the driving seat of a car, you’ll be scanning the road for turn signals (indicator lights). These tend to indicate another driver’s intention to turn or maneuver. However, we all know that not all drivers use these lights! We’ve probably all experienced situations where you notice a small change in another driver’s trajectory, so you hold back a bit… and instinct serves you well as they cut over multiple lanes of traffic. There are many subtle cues that indicate what a driver is about to do, although on the road rarely is it possible to validate our instinct. You can’t ask the driver what they are about to do: it’s necessary to wait and see.

A similar analogy can be drawn with organizational stakeholders, however we have the advantage that we can ask them what their intent is. Let’s examine an example:

Example: The Absent Stakeholder

Imagine you have a stakeholder who is crucial to the success of your project, and they are regularly ditching meetings or arriving very late. They always arrive unprepared, and rarely make decisions as they are too busy. You have sympathy for them, they seem to be spread so thinly.

Arguably there is a wider organizational issue here, as the stakeholder has too much work to do. However, assuming the person is effective at managing their workload, then there’s an unpalatable truth to swallow here. By saying “too busy” they are actually giving a subtle feedback signal which could be interpreted as “this is not a priority for me right now”.

This last sentence might be a difficult one to read, and they might say (and genuinely think) that the project is important. But if they are not prioritizing their time in a way that supports the project, they are unconsciously signaling that it isn’t significantly important for them to spend their limited time on.

This is no criticism, they may well be doing the best they can in difficult circumstances, and we should absolutely do what we can to make sure we support them and respect their schedules. Yet, left unchecked this might lead to a project that limps along, with other stakeholders getting increasingly resentful that progress isn’t being made.

Sadly, there’s no easy solution to this, however it’s important to address the issue head on. Ensuring the stakeholder knows why they are so important and valued, the benefit of the project to them and the implications of their non-participation is crucial. Offering to do what we can to lighten the load for them will often be appreciated, and it is worth asking if they have a delegate who can help. Ultimately, if they are truly crucial and can’t delegate, then perhaps delaying the project is a better option.

Indeed, openly saying “would it be better to delay this project to a time when our crucial stakeholders have enough bandwidth to support it?” could potentially prompt a useful (albeit often difficult and emotion-filled) discussion!

Interpretation Is Hard

Once you start looking for feedback signals, they are all around us. However, interpretation is hard. It’s important to speak to stakeholders to understand what is going on for them, rather than assuming. The key is to start looking, and make any adjustments early. That way we can make things better for our stakeholders and our project teams—and who wouldn’t want to do that?

Empowering Your Scrum Team: Why Developers Should Own the Sprint Backlog

Written by Aman Fogat on July 25, 2024. Posted in Articles.

In my seven years as a Business Analyst, I’ve worked with numerous Scrum teams across various projects. One issue that I’ve repeatedly encountered is the confusion over who owns the Product Backlog versus the Sprint Backlog. This misunderstanding often leads to inefficiencies and tension within the team. Through my experiences, I’ve come to realize the importance of clearly defining these roles to ensure smooth and successful project execution.

In the dynamic world of Agile development, Scrum stands out as a framework designed to promote collaboration, flexibility, and continuous improvement. However, even within this well-structured framework, misconceptions can arise, particularly regarding the ownership of the Product Backlog and the Sprint Backlog. Clarifying these roles is essential for any team aiming to harness the full potential of Scrum.

The Core Misconception

During Scrum training sessions, particularly with teams that have prior experience, one topic often sparks intense discussion: who truly owns the backlogs? The common but flawed practice is for the Product Owner to decide what work the team should pull into a sprint. While this may seem like an efficient approach, it fundamentally misinterprets the roles and responsibilities within Scrum.

Understanding the Roles

The Product Owner is tasked with maximizing the value of the product by managing the Product Backlog. This involves understanding stakeholder needs, prioritizing features, and ensuring the backlog is transparent and visible. However, the actual implementation of these backlog items is the responsibility of the Developers. They have the technical knowledge and expertise to assess which items are feasible, independent, and deliverable within the constraints of a sprint.

Why This Misconception Is Problematic

When the Product Owner oversteps and dictates the sprint tasks, it creates several issues:

Undermines Developer Accountability: Developers are accountable for the work completed during the sprint. If they are not involved in selecting the tasks, their ability to commit to and deliver on these tasks is compromised.
Ignores Technical Expertise: Developers are the ones with the hands-on experience and technical skills necessary to gauge the complexity and interdependencies of the tasks. By excluding them from the decision-making process, teams risk selecting inappropriate tasks that may not be deliverable within the sprint timeframe.
Erodes Trust: Effective Scrum relies on mutual trust. When Product Owners dictate sprint tasks, it signals a lack of trust in the Developers’ ability to manage their work, which can lead to demotivation and disengagement.

The Product Owner’s Role in Ordering the Backlog

A proficient Product Owner will order the Product Backlog to maximize value, but also actively seek input from the Developers. This collaborative approach ensures that the backlog not only aligns with business priorities but also accommodates technical realities. Enabling work, technical debt, and other critical tasks should be prioritized with input from those who understand the technical landscape best—the Developers.

The Developers’ Autonomy in Sprint Planning

Developers must have the autonomy to pull work “out of order” when it makes technical sense. This flexibility allows the team to adapt to emerging dependencies, unforeseen challenges, and optimization opportunities. When such deviations occur, they should prompt discussions that ensure the entire team understands the rationale behind the decision. These discussions should focus on technical and strategic reasons, avoiding subjective motivations like personal preferences.

Fostering Trust and Professionalism

Trust is the cornerstone of successful Scrum practice. The Product Owner must trust the Developers to manage the Sprint Backlog effectively, just as the Developers trust the Product Owner to prioritize the Product Backlog judiciously. This mutual trust encourages professionalism, accountability, and open communication.

When Developers are trusted to manage their work, they are more likely to take ownership of their tasks, leading to higher engagement and productivity. Conversely, when Product Owners trust Developers with this responsibility, it fosters a collaborative environment where both parties feel valued and empowered.

Addressing Trust Issues

If a Product Owner finds themselves deciding what work Developers should deliver in a sprint, it highlights a deeper trust issue that needs addressing. Building this trust involves:

Open Communication: Regularly discuss priorities, challenges, and feedback openly within the team.
Collaborative Planning: Involve Developers in the sprint planning process, allowing them to provide input and make decisions.
Reflective Practices: Use retrospectives to identify and address trust issues, facilitating an open dialogue about how to improve team dynamics.

Conclusion

Understanding and respecting the distinct roles within Scrum is essential for maximizing efficiency and delivering high-quality products. The Product Owner should focus on prioritizing and articulating value, while the Developers should have the autonomy to manage the Sprint Backlog. By fostering an environment of trust and open communication, teams can navigate the complexities of development more effectively and achieve their goals more consistently.

Empowering Developers to own the Sprint Backlog not only leverages their technical expertise but also builds a more cohesive, motivated, and high-performing team. Trust your team, respect their insights, and watch as they deliver exceptional results sprint after sprint.

Beware Indecision Inertia: The Importance Of The “Do Nothing” Option

Written by Adrian Reed on July 4, 2024. Posted in Articles.

Organizational change can be hard. People get into routines, and convincing people to adapt the way that they work can be difficult. This is a seemingly human trait: think about how hard it can be to adapt when an icon or menu option moves in a new version of Windows. We have probably all taken a while to adapt to things like this, occasionally wishing that we could reinstate the older version of the software that we are so used to. If even a simple change like this can cause initial confusion and frustration, no wonder a larger change such as an office move or process change can be challenging.

When a potential change is being discussed, there are usually supporters and detractors. It’s important to understand the different perspectives, and work together to understand the best way forward. Yet beneath the overt support and reluctance, there are other subtler things to look out for too. One is indecision inertia.

What is indecision inertia?

Although you might never have heard the term ‘indecision inertia’, you’ve almost certainly experienced it. Imagine a stakeholder needing to make a key decision, which is pivotal to a particular project progressing. It is a key dependency, and it is going to block progress if the decision is not made. They very reasonably ask for some data or a report in order to make the decision.

It takes some time to assimilate the information provided, but when it is played back to them (with a recommendation) rather than making a decision, they ask for more information. Or they raise a set of new questions, and more investigation is required. On the one hand, this is useful as they are helping to mitigate risks. On the other hand, it sometimes feels like the ‘can is being kicked down the road’.

Put simply: Sometimes the perception is that the least risky thing to do is nothing. In order to build a case for doing something a stakeholder might feel there needs to be watertight evidence and data. Yet, in reality, ‘watertight’ data rarely (if ever) exists. Can you say for certain the benefits that a project will bring? Or how long it’ll take? Or how much it’ll cost? Sure, these things can be estimated, based on a set of assumptions, but any certainty that is provided is entirely illusionary.

Indecision inertia occurs when the path of least resistance is doing nothing even though, when analyzed holistically, that might not be the most appropriate thing to do.

Incidentally, this pattern plays out in personal life too. People sometimes stay in jobs longer than they should (I know I did!) for fear of the ‘risk’ of applying elsewhere. People keep the same old car for too long, even when the maintenance is a nightmare, because it’s the car that they know and love…

The Role Of Holistic Analysis

This is an area where business analysis is crucial. In many cases ‘doing nothing’ isn’t a cost-free, or risk-free option. Imagine an organization running an older, legacy, packaged IT system that is going into extended support. Soon it’ll be out of support entirely. It’s been extended and customized over the years, and the development team affectionately define it as a ‘bag of spanners’. It works, it’s reasonably reliable (at the moment), and the prospect of spending money to replace it is a hard decision to make.

Yet doing nothing will lead to increasing maintenance costs, risks that it’ll become unmaintainable, and when support eventually expires there won’t be security patches and updates which leads to an even more worrying risk. Just like a beloved old car that is kept too long and breaks down at the worst of all times leaving its passengers stranded, this beloved old IT system might implode, get hacked, or develop other issues at the worst time. And if it’s a core system, every minute it is down is probably costing significant sums…

This is a hypothetical example, but it shows the importance of understanding that doing nothing is an option, and it has costs, benefits and risks associated with it. This is important as it is a way of reframing the decision. Often a decision is seen as:

Stay as we are (which is safe, and nobody gets sacked for doing nothing)
Do something risky / costly (and put the sponsor’s neck on the line if it goes wrong)

Whereas, the real decision is often

Stay as we are, and things will get progressively worse, riskier and more costly (and action will need to be taken at sometime)
Do something, understanding the risks and costs (but do so at a time of our choosing, rather than when some major risk event forces us to)

This is simplified, but it illustrates the point.

Conclusion

In summary, change is hard, and decision-making is hard. As analysts, we can help decision-makers to make informed decisions. Analyzing and presenting the ‘do nothing’ option can be part of this.