Skip to main content

Tag: Agile

Goldilocks And The Three BAs

Once upon a time, there were three BAs, they all wanted their analysis to be “just right”, but what does that actually mean?

Balancing Act

‘Just-enough’ and’ just-in-time’ sound like straightforward concepts, but how much is enough? This very much depends on the context and the needs and preferences of your Goldilocks. We always want our business analysis outputs to be accurate, but we also need them to be proportionate and appropriate to the situation.

So ‘enough’ business analysis means: establishing clear expectations and exclusions, sufficient breadth and depth of investigation, engagement with representative stakeholders, utilization of suitable analysis techniques, and a focus on creating analysis outputs and assets that meet a specific purpose.

We can look at the characteristics of ‘over-analysis’ and ‘under-analysis’ to help test the balance, and ensure our analysis efforts and outputs are just right.

 

The First BA: Over-Analysis

This BA finds it difficult to know when their analysis is ‘finished’.

We can always speak to one more stakeholder or hold one more workshop! It is easier to frame analysis outputs as ‘sufficient to meet the purpose’ (which may be to inform further activities, share knowledge, facilitate agreement, enable decisions, etc.) rather than ‘finished’. We must also remind ourselves that new information will always emerge, this does not mean our analysis was wrong but reflected what was understood at that point in time. The purpose of the analysis is to increase knowledge and test assumptions. Some assumptions will be proven wrong, and new perspectives will emerge.

The characteristics of over-analysis:

  • Feeling overwhelmed and experiencing Analysis Paralysis
  • Too much detail, no summary or high-level routes into the detailed analysis
  • Endless meetings/discussions/workshops with no progress
  • Number of requirements out of control
  • Too much focus on edge cases
  • No prioritization of analysis effort
  • Repository of unread documents
  • Total reliance on BA to navigate the analysis, opaque to others
  • Regularly finding duplication of requirements or analysis assets
  • Audience for analysis outputs unclear
  • Being ‘90% done’ for weeks or months.

 

The Second BA: Under-Analysis

This BA does not challenge assumptions or apply analytical thinking.

Stakeholders may have low expectations of this BA, treating them like an order-taker or scribe. When we accept a very narrow role or are told we cannot deploy the full range of analytical techniques required for the situation, the quality and veracity of the resulting analysis will be compromised.

The characteristics of under-analysis:

  • Always engaging the same small group of stakeholders
  • No stakeholder analysis
  • Solution pre-defined
  • No clear problem definition
  • Applying a very limited range of analysis techniques
  • Only creating user stories
  • No consideration of edge cases
  • No templates or reuse, always starting from scratch
  • No peer-review by other BAs
  • Process-view only, no consideration of data
  • Technology view only, no consideration of business
  • Opinion over evidence, deference to HiPPOs (Highest Paid Person’s Opinions)
  • No challenge of ideas/assumptions/processes
  • Undocumented assumptions
  • Writing things down with no critical thinking or analysis.

 

The Third BA: Just Right

This BA understands the audience and purpose of the analysis and is confident in the business analysis skills and techniques which will achieve the required outcome.

A key aspect of creating analysis outputs that are accurate, appropriate, and proportionate is agreeing on who will use the analysis and for what purpose. It then entails considering possible routes to achieving that purpose, how the analysis will be carried out, and getting further agreement on that approach.

A ‘definition of done’ for the analysis deliverables is very valuable, and creates a shared understanding and agreed set of expectations from all stakeholders.

Questions for getting analysis just-right:

  • WHY am I doing this? What is the purpose of the analysis?
  • WHO am I engaging with? Who is missing? Are the stakeholders representative and proportionate? Are they appropriate for this stage? Who will use what I produce?
  • WHAT am I creating? What format, what length, what systems will I use?
  • HOW will I approach the analysis? What business analysis techniques will I apply? How will I select techniques that are appropriate to the audience, timescale, and other constraints? How will I ensure I am producing analysis and not simply documentation? How will I achieve validation and approval of the analysis deliverables?
  • WHEN is the analysis needed? What can be achieved in that timeframe, what cannot be achieved? What constraints does that place on the engagement and investigation? What dependencies exist?
  • WHERE will the analysis be shared and stored? How can I ensure transparency and increase engagement?

 

Conclusion

The first BA is drowning in the detail and doesn’t know where to stop. The second BA is doing what they are told, and not bringing analytical tools and thinking to the situation. The third BA is asking a lot of questions, and quite possibly annoying people who think they should ‘just get on with it’, but certainly has the most chance of producing analysis outputs that are useful and valued.

The recipe for getting business analysis just right is to be aware of the characteristics of over and under analysis, to apply a suitable range of analysis techniques which explore multiple perspectives and to understand the expectations of Goldilocks.

How can I make my work more visible as an Agile BA to my team and organization?

Photo by Lala Azizli on Unsplash

Something I often hear from other BAs working in multi-disciplinary Agile teams is that their work sometimes seems invisible. Or at least, less visible when compared to other professions. To put that in context, designers will likely be mocking up various designs that they develop and share iteratively. Devs regularly build and release new features. Content designers produce content to be published.

However, as BAs, especially in an Agile environment it can be difficult to see similar types of tangible output. Of course, you’ll have probably been involved in defining various backlog items and likely some modeling of the business or its processes, as well as facilitating numerous workshops to find out information. But these individually maybe aren’t as ‘visible’ or as tangible to many in the same way as when compared to some of the outputs from other professions.

Advertisement

This is where it can be useful to take a step back to think about our role. The primary responsibilities of Business Analysts aren’t to create designs, content, or code. Very briefly, we’re there to understand how things work, work out the gaps, break down complexity, align initiatives to wider org goals and help articulate a clear specification of what needs to be done. Ultimately this enables decisions to be made, challenges thinking, and helps solve problems. These collectively, enable value to be created, as well as being the basis for many other professions to create their stuff.

So, what can you do to make our work less invisible and more visible? Luckily quite a lot, here are some suggestions on how we can shine the spotlight more on what we do;

  1. Shout about your successes in retros — for example, talk about how your work enabled a particularly important decision to be made or how modeling a specific part of the business has identified something no one in the team was aware of before. Maybe add the impact of not finding this out.
  2. Show and tells, town halls, basically anywhere you’re showing the work you’ve done as a team in an open forum — if you’re currently in a Discovery or Alpha phase it could be sharing what you have discovered and what that has enabled, or if you’re in Beta, it could be mentioned that through undertaking something like root cause analysis has helped to find a solution to a specific problem.
  3. Introduce a BA Service Framework —that helps to articulate the value of business analysis as a set of services in the context of your organization. If you’re not familiar with the BA Service Framework, I’d strongly recommend checking out the BCS publication ‘Delivering Business Analysis: The BA Service Handbook’ by Debra Paul and Christina Lovelock. (I’ll be sharing more on this topic through my LinkedInprofile over the coming weeks).
  4. Work in the open (where possible)— if you’re in the office, this could be just placing analysis outputs on walls in your huddle spaces, or if you’re using collaboration tools such as Miro or Lucid — then make sure they’re open for all those in your team to see. Encourage comments and conversation about them, and don’t worry about them being perfect.
  5. Talk about tasks with a clear mention of why you’re doing it— whether you’re using post-its on a Kanban board, putting tickets on Trello, or just talking it through in a stand-up. Be clear on the task you’re doing and the purpose behind it. For example, ‘understanding X piece of legislation so that we design and deliver a compliant service’, is significantly clearer than just saying ‘doing research’.
  6. Write blogs and articles — if you can and time allows, get in the habit of sharing successes of how business analysis has helped to reach a consensus or challenged thinking on a particularly complex topic. Maybe it’s solved an important problem for your users. Whatever it is, look to use the appropriate medium to tell your story. This may mean publishing an article on an internal space such as an Intranet, or if the subject allows, publishing an external blog.

Thanks for reading, let me know your thoughts by getting in touch on LinkedIn. It would be great to hear if you use any of the approaches above and how you find them, whether you’ve been using them for a while or if it’s something new you’ve tried after reading this article. Similarly, please share if you have found another effective way to make your work ‘more visible’, that isn’t listed above.

Who is in, and Who is Out

Imagine attending a meeting, and all the participants but you, are contributing ideas to a discussion. You are clueless. Maybe you missed a conversation, or you did not read an email? There could be numerous reasons why you could not contribute during the meeting. One instance could be that you were not included in an email chain or not invited to a meeting.

Leaving recipients off unintentionally (or intentionally) from any form of communication can lead to confusion and misunderstanding between the team members. A little bit of proactive questioning can help avoid hits and misses. Ask these questions first:

  1. Who should and should not be on a meeting invitation?
  2. Who should and should not be on an email chain?

The obvious answer is: It depends

Next, ask these additional questions to finalize the list of recipients. Evaluate the responses before hitting the send button:

  1. What is the email or meeting topic?
  2. Would skipping a team member in an email or meeting lead to miscommunication?
  3. Will including all the team members make a few of them feel that the meeting was irrelevant to them?

Advertisement

You can answer the above questions by leveraging these options:

  • RACI (Responsible, Accountable, Consulted, and Informed) matrix: RACI matrix can be a great source of stakeholder information for global projects.

For example: List the Responsible parties under the To list or Required Attendees. List the Informed parties under the Cc list or Optional Attendees.

  • Working Agreement: No RACI matrix? An Agile team working agreement can come to the rescue. Define who are the core team members. Refer to this list when sending out any email communications or meeting invites.

Tip: Core team can be cross-functional with stakeholders across the organization.

  • Email distribution list: Say the team size is small (4 to 6 members) and there is no RACI matrix or working agreement, then create a distribution list that includes the email IDs of all the team members. It is less effort and error-proof when selecting a list instead of individual email IDs for sending any form of communication.
  • Instant messaging group chats: Most instant messaging tools allow the setup of groups. Create one for your team and post a message in the team chat. Plus, there are options for the recipients to acknowledge the chat message (emojis such as like, happy, celebrate, and such).

In conclusion, despite the ideas mentioned above, there are chances that someone is still left off an email chain or a meeting. Be a team player, reach out, and get them caught up. The crucial element is that the entire team is on the same page.

“We need to be on the same page and not play the blame game” – Nate Heying.

Turn your specifications into living, digital documentation

Digital transformation requires the use of new tools and new ways of working – also for business analysts. We often facilitate this for other groups of people, and we should be ready to look at our own habits and preconceived notions as well and embrace new mindsets and tools. This article offers a take on what ways of working could look like for the digital business analyst.

Collaboration is becoming increasingly digital, and this also gives business analysts many opportunities to work smarter and better. That is, if you are ready to let go of documents and spreadsheet, and instead embrace digital tools for wikis, notes and backlog management. With a wiki tool, you can easily build your requirements documentation using webpages in a tree structure. Your first pages describe your scope. Each of those pages can then be broken into details on several pages that branch out. If you are familiar with mind maps, you will see that this is basically the same structure. In fact, a mind map can be a great first sketch of how to structure the content of the wiki.

Advertisement

The wiki structure allows your documentation to grow dynamically without you losing the overview. This structure is very well suited for agile development. If you focus on establishing the scope first, you will soon have some documentation that is accurate, though it is high level. You can describe the scope of your initiative first, and sign that off with your stakeholders. Based on that, you can discuss deliverables with your developers, and establish your backlog with features or epics. The features or epics can then be prioritized with your stakeholders. You can then detail out the requirements on your wiki, and the team can break down the user stories based on the wiki. This means, that while your scope is fixed and signed off, your detailed requirements get fixed and signed off incrementally in the same pace as the team is developing. I have experienced this to be a good way to be able to handle scope creep (because I have the scope to keep the requirements in check) and to avoid analysis paralysis and requirements rot. Because it is digital, I can create links from my backlog items to the relevant parts of the specification.

The basic concept can be illustrated like this:

Why not just add my requirements to the backlog items, and avoid all the linking? Well, because I want my documentation to describe my product holistically, including its context. And I want my backlog to describe the increments that the product is built in. So I need both.  I can then communicate, what my product is and does without also having to communicate the increments it was built in, which is completely irrelevant to most of my stakeholders. I can easily share a wikipage with a link or present it in a meeting. This means fewer powerpoints to produce.

Once the product is built, I no longer need the backlog – my documentation is what describes the product. And with that documentation established at the very early stages of the product development phase, I can communicate what the product looks like through its whole life cycle, from the birth of the idea to the decommissioning of the product. Each page is automatically version controlled, which makes the change control much more granular, and changes easy to manage without keeping extensive change logs. In some digital tools, you can even set up approval workflows to make sure that the right people sign off on changes. I like to think of it as the DevOps mindset implemented in requirements analysis.

You can add any kind of content. A webpage has no limits when it comes to content – pictures, text, tables, links, and attachments. Your documentation can contain much more than a traditional requirements specification, such as personas, test data, samples of production data and other types of examples. Because of the tree structure, I always know which objective or process a detailed requirement supports. Obviously, various kinds of diagrams play an important role. Traditionally, you would argue that you must do your modelling using a modelling or BPMN tool. The reason for this is that your models can then be reused by others. In theory, this is true. However, I have never experienced this reuse in my 15 years as a business analyst.

Over the past couple of years, I have practiced using pen and paper for visualizations, and I have integrated this into my ways of working. It is a great way to work because it helps me focus and process information. It is also free of the constraints a computer program sets when you create digital visualizations. To my own surprise, this approach is very compatible with digital documentation. Simply take a photo or scan a drawing and add the image to the page. It can then be enriched with text for elaboration. This is particularly useful when describing scope, features or epics and application landscape. Digital and analogue are not contradictory, but complementary.

I have recently published two articles on BA Times related to using pen and paper, which provide some tips for getting started:

Start your visual facilitation journey with letters

The icon library: My favorite analogue tool

Top 10 Business Trends to Watch for in 2022

By Andrea Brockmeier, Jason Cassidy, Susan Heidorn, Jose Marcial Portilla, and Mike Stuedemann

While 2021 has been better in many ways than 2020, it doesn’t feel much more predictable. Yet, at Educate 360 we have identified some the biggest trends we are seeing and expect organizations to continue experiencing in Project Management, Business Analysis, Agile, Data Science, and Leadership in the year ahead.

Overall, the theme of working remotely comes through loud and clear and we expect it to impact almost every area that we covered.

Here are our Top 10 trends to watch for in 2022. We’d love to hear your thoughts about our observations and prognostications.


Advertisement

Project Management

Project Managers as Project Leaders

The recognition that project managers are both leaders and managers is not new, but the need for the leadership aspect of the role has intensified in the last couple of years and will continue to do so in 2022. In fact, we are hearing more organizations using the title project leader as opposed to project manager.

To be sure, the technical aspects of the job such as scheduling, budgeting, and tracking haven’t been eliminated, but the need for skills like influencing, facilitating, communicating and other “soft” skills associated with the PM as leader has become paramount. Project managers as leaders are going to continue to be challenged in 2022 with distributed teams and all the distractions of ever-changing global and work environments. Leading the team and engaging stakeholders to sustain buy-in is going to continue to be job one for effective PMs in 2022.

More Organizations Using Project Management Tools

In 2022, expect to see a continued increase in the use of project management tools beyond the standard Microsoft Office suite. We used to see only the occasional client using a PM application of any kind and it was almost always Microsoft Project. Whether because people are working remotely, tools have become more cost effective, or tools have become more accessible and easier to use, we see more organizations using PM-specific tools and we’re seeing a wider variety of tools, as well.

At first this may seem contradictory to the previous trend of project leadership getting emphasized over project management; tools are not generally used for the leadership aspects of the PM role. Perhaps these trends are mutually reinforcing in that tools like Asana, Wrike, Easy Project, Smartsheet and others help with project management which allows the PM to tend to the demands of project leadership. Whatever the reason, we look ahead to 2022 as a robust year for PM tool implementation.

Business Analysis

Strong Facilitation and Communication Skills for Remote Business Analysts

We have all have heard about the Great Resignation – employees leaving their jobs in record numbers in search of better pay and career opportunities, a healthier work-life balance, a less toxic working environment, and desire to continue to work remotely. As a result, many companies are reducing their carbon footprint as well as costs, so they either have smaller offices, holding a space for meetings or providing “hoteling” spaces when employees need or want to go into the office to work. Organizations are also realizing that they can hire talent around the globe.

So, what does this mean for business analysts? It means we must get better at communicating and facilitating in a virtual environment. We must learn how to build trust when we can’t directly “see” stakeholders daily. We must be able to facilitate virtually to ensure we elicit inclusive requirements and not just those from a few vocal stakeholders. We need to learn to creatively collaborate with our team members, colleagues, and key stakeholders to ensure we have their buy-in.

BAs need to think about communicating and facilitating with more intention. This calls for mindful facilitation as opposed to simply the ability to use Microsoft Teams, Slack, or other communication platforms. We are already starting to see – and we continue to see in 2022 – more BAs focus on learning how to create safe, trust-laden, and collaborative environments within which stakeholders readily share information in a world that has been changed forever.

Digital Transformation Strategy Supported by Business Analysis

Digital transformation has been a trend for some years, and it is still going full steam ahead. Yet, most of these efforts fail. There are many reasons cited for this failure; among the most common include:

  • NOT understanding the business problem, but instead just throwing solutions or technology at the wall to see what sticks.
  • NOT determining success criteria so organizations have no way of knowing if the initiative has been successful because there was not a shared understanding of what success looked like.
  • NOT realizing that digital transformation introduces cultural changes in the organization (which is also one of the reasons many organizations had difficulty adopting agile).

Because of these failures, organizations moving toward digital transformation will rely more on business analysis capabilities to effectively address root causes of the problems above. BAs will be used on digital transformation initiatives to ensure the business problem or opportunity has been fully analyzed and understood, to verify that the organization is ready to adopt the new culture, and to identify overall success measures as well as identifying smaller, incremental success measures that can be measured throughout the project.

These efforts will also require a business analyst’s in-depth knowledge of agile business analysis approaches, tools, and techniques that will be critical as organizations strive to become more agile in their ability to respond to customers and competitors. Look for lots of opportunities in 2022 for BAs to plug in as key strategic resources on digital transformations.

Agile

Teams Continue to be Distributed – By Choice, Not Necessity

It can be argued that the COVID 19 pandemic did more to transform the world of work than any document, framework, certification approach or technology. One of the lasting impacts of the pandemic is that distributed teams are here to stay. Product development team members and their leaders will need to permanently adjust to working in a distributed fashion.

While many still share the perception that all Agile frameworks require co-located teams (see principle 6 associated with the Agile Manifesto), technology has advanced to the point where a team adopting a framework doesn’t need to all be in the same location. Continued discipline, particularly in the area of communication and team working together agreements, will be required as teams shift from distributed work by necessity to distributed work by choice.

Scaling – Addition by Addition or Addition by Subtraction?

The marketplace continues to see the emergence and growth of a number of Agile scaling frameworks. The Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), Scrum at Scale (S@S) and Disciplined Agile Delivery (DAD) are just a few of the prominent entries in this space. Next year will see organizations continue to adopt these frameworks as they seek to realize the benefits of being more responsive to change at a global level.

Current thoughts are mixed regarding how to achieve this goal. While many of the current frameworks (e.g., SAFe) advocate adding structure and layers, some like LeSS believe that true organizational agility can only be achieved by removing items from the organization that don’t directly contribute to the delivery of customer value. This debate is even more nuanced when the idea that some additional structure might be necessary on a temporary basis while the organization is being transformed. In 2022, we expect to see continued debate as to what steps are actually necessary to achieve agility on a global scale.

Agile Outside of Software

The Agile movement was born in the software development space. After all, it is called the “Manifesto for Agile Software Development”. In recent years, other domains have adopted a number of the values and principles that define the Agile movement in attempt to accrue its benefits. For example, there is currently an Agile Marketing Manifesto as well as efforts to bring an Agile mindset and some of its practices into education.

This trend will accelerate in 2022 as events such as the pandemic, natural disaster, and political and economic shifts remind organizations that the only constant is change.

Data Science

Increasing Application of Artificial Intelligence and Reinforcement Learning

We often hear that Artificial Intelligence is one of the trends that will change the world. This past year certainly validates that sentiment, and 2022 will continue to see evidence of this powerful trend.

But what is actually meant by the term “Artificial Intelligence”? Technically speaking, AI systems typically incorporate a special type of machine learning known as “Reinforcement Learning.” These specialized programs allow a computer to learn the same way a human does, through experience with trial and error.

In 2016, DeepMind (an Alphabet company) made headlines when its computer program AlphaGo beat the world’s best Go player, a feat many previously thought was impossible. The AlphaGo program worked through Reinforcement Learning methods, where the computer played thousands of games against itself, learning the best tactics to win the game of Go.

Fortunately, Reinforcement Learning has applications beyond just board games. In 2021, DeepMind released AlphaFold 2, a computer AI program that can accurately predict protein folding structures, opening up new possibilities in drug discovery and medicine.

The application of AI and reinforcement learning will definitely be a trend to keep an eye on, as the progress has increased exponentially.

Huge Strides to Continue with Natural Language Processing

Natural Language Processing (NLP) is the use of machine learning models to interpret raw text data, such as Wikipedia articles or even code written by humans. Traditionally, NLP technology has been used for classifying text articles into categories or sentiment analysis of reviews. By simply training NLP models on existing text data sets, the models can learn the topic of a new article, or whether a movie review is positive or negative.

Huge strides have recently been made in the capabilities of upcoming NLP technology. In 2020, OpenAI released “Generative Pre-trained Transformed 3,” commonly known as GPT-3, which has the ability to generate text that is nearly indistinguishable from that written by a human. GPT-3 was trained on hundreds of billions of words that were scraped from the internet and is even capable of coding in CSS, JSX, Python, among others.

In 2021, OpenAI further expanded on the idea of an NLP model that can code, by releasing Codex and Github Copilot. These futuristic state-of-the-art models can not only automatically complete large portions of code, but they can also accept a description of what the code should do and produce the corresponding code. Check out this Codex demo launch video.

The future is already here! We are definitely looking for exciting new applications of NLP continue to make headlines in 2022.

Leadership

Attracting & Retaining Talent – But Different Than Before

Attracting and retaining talent is the most prominent topic of conversation we’ve observed in media related to leadership, specifically attracting and retaining talent in a COVID-changed environment. It’s not clear anyone has permanently figured out the solution as the situation is still in flux, so we have listed key points that we hear leaders weighing in with in their decisions related to remote work and its implications for finding quality team members.

Let’s start by making a broad assumption (that certainly can still be refuted) that some jobs cannot be done remotely (e.g., printing and shipping) and some jobs potentially can be done remotely. Below are the key topics of debate that will continue to shape this discussion in 2022:

  • Job Equity: Is it fair to the people whose roles cannot be done remotely and who have to come into the workplace that others can work at home? As this question is discussed topics related to safety, expenses, commute time, flexibility, teamwork, fairness all come into play.
  • Productivity: Even if jobs can be done remotely, what is the level of productivity of remote work versus work in the office? As this question is discussed one hears that people work longer hours at home because they are not commuting, that people are more productive at home because they can focus and not be disturbed. On the other hand, you hear others say that people are less productive at home because they are distracted by non-work items and that people are less productive at home because they are not being watched. You also hear discussion of managers’ ability to manage in-person versus remote team members.
  • Cultural Impact: Even if a job can be done at home, is it better for the organizational culture? As this question is discussed topics related to collaboration, mentoring, camaraderie, organic problem solving and innovation, and work-life balance come into play.

These debates and questions will dominate leadership conversations in the coming year as leaders continue the challenge of finding and hanging on to top talent.

Jason Cassidy, PMP, is CEO of Educate 360, the parent company of Project Management Academy, Watermark Learning, and Pierian Data. – training partners of choice helping organizations improve organizational efficiency and effectiveness, increase cross-functional alignment, and drive results to help meet and exceed business performance goals.

Andrea Brockmeier, PMP, is Director of Project Management at Watermark Learning, an Educate 360 partner company. Dr. Susan Heidorn, PMP, CBAP, BRMP is Director of Business Solutions at Watermark Learning. Jose Marcel Portilla is Head of Data Science at Pierian Data Inc., an Educate 360 partner. Mike Stuedemann, PMP, CST, is a Scrum-Focused, Agile Agnostic Coach and Trainer at AgilityIRL and partners with Watermark Learning for Scrum courses.

Join our webinar on December 10 to hear our contributors talk about these trends and answer questions.