Tag: Best Practices

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.

Priming: A Powerful Tool for Business Analysts

Written by Olam Osah on June 26, 2024. Posted in Articles.

“Big doors swing on little hinges.” – W. Clement Stone

Imagine walking into a store and hearing your favorite song playing in the background. Instinctively, you feel more at ease, more inclined to browse, and perhaps even to buy something. This subtle influence on your behavior is no accident—it is an example of priming at work. Now, picture leveraging this same psychological phenomenon to enhance the effectiveness of business analysis. Welcome to the world of priming, where a well-placed word or image can shape perceptions, drive engagement, and ultimately lead to more successful projects.

Historical Context of Priming

Priming, a concept rooted in psychology, began to gain traction in the 1970s. Researchers like David Meyer and Roger Schvaneveldt conducted seminal experiments demonstrating how exposure to certain stimuli could influence subsequent responses. For instance, people could respond faster to related words (like “doctor” and “nurse”) than to unrelated ones (like “doctor” and “bread”). This discovery highlighted the subconscious ways in which our minds process information, laying the groundwork for priming’s application across various fields, including business analysis. The foundational studies revealed that our brains are wired to create associative networks, meaning that exposure to a particular concept can automatically activate related concepts. This insight has been pivotal in understanding how to strategically use priming in business contexts to shape decision-making, improve stakeholder engagement, and enhance communication strategies.

Real-Life Examples of Priming

Priming has been effectively used in many real-world scenarios. For instance, in retail, stores often play specific types of music to influence customer behavior. A study by North, Hargreaves, and McKendrick (1999) found that playing French music in a wine store increased the sales of French wines, while playing German music boosted the sales of German wines. This subtle priming technique tapped into customers’ associations between the music and the product.

In another example, Priming is a powerful tool in political campaigns, frequently used to shape public opinion by consistently emphasizing particular themes or issues. Barack Obama’s “Yes We Can” and “Change We Can Believe In” slogans serve as prime examples of this strategy in action. These slogans were not just catchy phrases; they were meticulously crafted to prime voters to embrace a sense of collective empowerment and the possibility of positive change.

During Obama’s campaign, the repetitive use of these slogans created a cognitive framework that associated his candidacy with optimism, hope, and unity. Every time voters heard “Yes We Can,” they were subtly reminded of the potential for change and progress, fostering a sense of personal involvement and collective action. This emotional resonance was further reinforced through speeches, advertisements, and campaign events that consistently highlighted these themes.

The effectiveness of this priming was evident in the overwhelming support Obama received, particularly from younger voters and minority groups who felt directly addressed and included in his vision. The campaign’s ability to prime these voters to associate Obama’s candidacy with positive change and empowerment played a crucial role in his electoral success.

Personal Anecdote: Priming in Action

In my experience as a business analyst, I have found priming to be an invaluable tool in guiding stakeholders towards beneficial decisions. One notable instance was during a project aimed at selecting a software solution for case and document management.

Having previously worked with a highly effective software that streamlined operations and significantly reduced processing times, I was confident it would be the ideal choice for our current project. However, I knew that simply presenting this software as the best option might not be enough to gain stakeholder buy-in.

To prime the stakeholders, I began by sharing a series of success stories and case studies from other organizations that had successfully implemented this software. In pre-meeting materials, I included testimonials from satisfied users and highlighted measurable improvements in efficiency and accuracy. During our discussions, I subtly referenced these examples, framing our needs in a way that aligned with the strengths of the software.

As a result, when it came time to evaluate potential solutions, the stakeholders were already positively inclined towards the software I had in mind. The decision-making process was smoother, and the eventual adoption of the software led to significant improvements in our case and document management processes.

Applications of Priming in Business Analysis

Having seen how priming can effectively influence stakeholders in a real-world project, we can now explore how this technique can be systematically applied in the realm of business analysis.

The application of priming in business analysis provides a strategic advantage in enhancing stakeholder engagement, improving requirements elicitation, facilitating change management, and ensuring clear communication. By understanding how subtle cues can influence perceptions and decisions, business analysts can effectively guide project outcomes. However, the true power of priming lies in its implementation. To harness this potential, it is essential to employ specific techniques that ensure priming is both subtle and impactful, driving the desired results while maintaining ethical standards.

Implementing Priming Techniques

Now that we understand the applications of priming in business analysis, let us delve into practical strategies for effectively implementing these priming techniques in your projects. To effectively implement priming techniques, business analysts should consider the following steps:

Conclusion

Priming is a subtle yet powerful tool that business analysts can use to enhance their effectiveness in various aspects of their role. By understanding and strategically applying priming techniques, analysts can improve stakeholder engagement, facilitate better requirements elicitation, support change management, and enhance communication. As with any tool, the key to successful priming lies in its thoughtful and ethical application, ensuring that it serves the best interests of the project and its stakeholders. Drawing on historical insights, real-world examples, and personal experiences, business analysts can harness the power of priming to drive project success and foster positive outcomes, ultimately shaping the landscape of business analysis for the better.