Skip to main content

Tag: Waterfall

The Business Analysis of Agile Product Ownership

Written by Angela Wick on . Posted in Articles. 1 Comment on The Business Analysis of Agile Product Ownership

I’ve been giving an Agile Product Ownership talk at a few conferences lately and the response has been great. BAs and BA leaders are beginning to see their connection to product ownership functions, but they are also discovering that there is a huge gap in the industry about what product ownership means.

They want to understand the scope of the product owner role, how the role fits in various agile methodologies, and how the product owner and the BA work together. As teams learn more, it is evident that product ownership extends much further than most teams realize.

For example, most agile methodologies place the product owner focus on the backlog, but do not offer guidance on how to build, prioritize, and refine the backlog. Also, some agile methodologies recognize the need for a product vision, roadmap and release plan, but again, offer little guidance on collaborative techniques needed to build these effective tools. Yet this is a HUGE part of the role!

Related Article: Technical Product Ownership

What surprises me most when I work with teams, teach this topic, and present on it is the giant number of teams that do not have a product vision, or teams that create a product vision, but never use it. This bugs me! It ranks near the top of my “How to Work Hard, but Create Crap” list. Without a product vision that is aligned with the organization’s strategy and customer value, we are seriously compromising the money being spent. Is it really possible to have a prioritized backlog without a baseline vision and value proposition?

Product visions provide many benefits. You wouldn’t do a waterfall project without understanding the problem or opportunity or update systems in a large organization without a roadmap that aligns the technical and business strategies? Why would agile be any different?

When your team starts digging into the details of requirements and user stories, they need to see connections to the product vision. They need to understand how their work supports the purpose of the product, the goals of the organization and/or the needs of the end-user. This is true for projects, but it’s also true for enhancements and defect fixes too! Even a backlog of defects and enhancements to an existing internal system can benefit hugely from a product/solution vision.

Whether your team is building a new product or modifying and existing product, you need a product vision. If your team doesn’t have a product vision, here’s what happens:

  • The team projects their own ideas and values into the solution.
  • The team makes unconscious (sometimes conscious) assumptions and decisions about what the true business problem is.
  • The team assumes the user group or requestor has thought through the proposed solution and its impacts, while the user group assumes the team is thinking through it all.
  • Ultimately the team creates fixes, enhancements, and solutions that do not meet the needs of the customer and require rework.

You are probably reading this and thinking, “Yes Angela I agree, but my leadership team is not providing this vision information! They only want the solution done yesterday!”

Most leaders I talk to about this scenario tell me that they want their teams to question vision and value, and would rather postpone the date then spend money on something that does not align. Leaders are assuming that if teams don’t ask, then they already understand the vision and strategy. That’s why they get so disappointed when the solution does not deliver the intended value.

Here are some tips to help BAs and Product Owners advocate for the importance of the product vision:

  • Highlight lessons learned. If past solutions moved forward without aligning to strategic intent and value, remind your leaders about mistakes, reworks, and defects. Connect with their pain in this, and then explain how you and the team will fix it.
  • Create a draft. Create a product vision, write a problem statement, or use a tool like a vision board, product canvas, or business model canvas to confirm your understanding of the context of the product, solution or fix. Discuss how the proposed solution impacts the various areas of the organization.
  • Discuss the extremes. Generate dialog or create simple models that help the team think about what an over- or under-engineered solution would look like.
  • Prototype. Build a prototype of the design or in-progress solution to get feedback.

Vision discussions throughout the solution lifecycle lead to better requirements, less rework and defects, high-value solutions, and happy end users.

The shared vision/purpose promotes a high-quality decision-making process. We want to avoid making assumptions and decisions for the business owners, and put the right information in front of them to make or delay decisions. Collaborative discussions between the team and the stakeholders, eliminate the blame game. Leaders get what they need to evaluate time/value trade-offs.

How does your team keep requirements and solutions aligned with organization strategy and end user value? Please leave your comments below.

Intelligent Analysis from Intelligence Analysis: Using Psychology Tips in our BA Tool Kit

Written by Bronia Shaw on . Posted in Articles.

Have you ever wanted to be a spy? 

We may not be qualified to be the gun-wielding, smooth-talking James Bond, but maybe a savvy CIA analyst might be more up our street. There are, of course, parallels in many types of analysis work and while our projects may be a little less glamorous than counter-terrorism, there are things we can learn from the world of Intelligence Analysts.

Richard J Heuer Jr in his book “Psychology of Intelligence Analysis” discusses the topic of when to make decisions. He explores methods used by doctors making diagnoses and applies this to the world of the CIA. How to know when you have enough information about a government, regime or situation to spot risks and make informed decisions.

It also applies to our world.

We all conduct interviews and workshops, dig into documents and ask questions but we determine for ourselves when enough-is-enough. Or rather time usually dictates when enough is enough. Heuer proposes that instead you could rather consider a smarter approach.

Make Decisions Earlier

Heuer warns that more knowledge leads to more confidence in a decision but not necessarily more accuracy. Using the example of horse racing pundits he shows that pretty good estimates are made with reasonably scant information and that experts recognize the limitations of their guesswork at this stage. As they are given further information about form and conditions their confidence levels grow, but interestingly their accuracy does not grow proportionately or even by much in real terms.

In business this may mean that when we gather a small amount of information we may get a reasonably accurate picture. As long as we can deal with the uncertain feeling, we save a lot of time and resources gathering more when the only outcome is greater comfort. Understanding the confidence level of stakeholders when they provide information gives us a good indication of when enough is enough.

Analyze Root Causes

How else can gathering more information be counter-productive?

Heuer tells of how analysts propose a theory while gathering or reviewing intelligence but that sometimes this would lead an analyst to use new information to strengthen an incorrect theory. Each piece of additional intelligence was being wrongly valued according to whether it reinforced the existing understanding.

How can this affect us? When considering the possible options of a new business proposition we need to check if fresh information reinforces more than one choice, not just if it supports the current favorite. If we have determined a product to offer, simply getting a positive response from a focus group on that particular product doesn’t make it the best proposition. They may be reacting to a particular product feature that is a feature of more than one product.

Knowing what probing questions to ask to uncover the underlying facts is for careful consideration by analysts. It surely grows with experience but can be honed when explicitly considered.

This book is just one example of the many that discuss psychology or the techniques learned from psychology studies. We have a mine of information we can extract and apply as a modern Business Analyst.

Consider another couple of examples:

How not to raise a risk

“Does fear persuade or does it paralyze?” is the title of a chapter from one of my favorite business books “Yes! 50 secrets from the science of persuasion” by Goldstein, Martin and Cialdini. They refer to the study of a public health leaflet highlighting the dangers of tetanus infection. The study gave leaflets to students were either frightening or not and that either had a plan of action or not. Which would motivate the students to get a tetanus injection? The leaflets with a high-fear message only generated action if a plan was included. The authors then note: “it’s important to accompany high-fear messages with specific recommendations for actions that will reduce the danger.” Readers of the leaflet were less likely to resort to denial if they had a clear action plan.

We, as Business Analysts are key experts in reporting potential risks to project management but if we often find that our warnings fall on deaf ears then perhaps consider how we present the risk. If we don’t already recommend or suggest mitigating activities then doing so could improve our chances of the risk being reduced.

Warping views with information

Daniel Kahneman in his book “Thinking, Fast and Slow” shows us the effect of “availability” of information, that is how often we come into contact with information and how readily we recall it. Availability affects our perception of our world and, therefore, our judgment. He discusses a study where participants were asked to judge the likeliness of different causes of death. They were then compared against statistics of the time. He notes that “Strokes cause almost twice as many deaths as all accidents combined, but 80% of respondents judged accidental death to be more likely.” This is revealing. He argues that “estimates of causes of death are warped by media coverage.” If we see multiple reports of tornadoes or earthquakes, then we are more likely to deem them as a higher risk, even where true probability states otherwise.

So how can we apply this to our Business Analysis work?

  • If we discuss one type of business problem using multiple examples then we can only expect that the participants will, for at least a short time after, view that type of problem as larger than it really may be.
  • After experiencing the realization of a project risk we would expect stakeholders to view avoiding similar risk as disproportionately more important because the information is easily called to mind.
  • We must be careful then that we don’t set up a situation where we create an increase in the availability of information prior to discussing subjects that may need to be downplayed to meet our objectives.

Getting the most out of the people we encounter during our project life-cycle and the time that we spend with them is so important. There are many more exciting tips and techniques discussed in psychology best-sellers. In the future I hope we see some of these techniques becoming part of the formal toolkit of the successful Business Analyst and not just the CIA.

5 Lessons from Working with Agile and Waterfall Teams

Written by Angela Wick on . Posted in Articles.

Over the course of my career, I have always been intrigued by leaders who promote a specific methodology or tool or process as THE RIGHT WAY to deliver solutions. They dispense mandates and proclamations to promote their all-or-nothing, purist approach to methodology. Typically it is because it worked in the past for them, and once it fails to deliver results onto a new one.

I’ve seen so many CEOs, CIOs, CoE leaders, and technology directors come and go with their unique methodologies and approaches. Do you know what doesn’t change?—the way BAs do work to be successful; The BA mindset, the key tasks and core set of techniques, remain constant.

We may need to use a new tool, try a new technique, a different template or learn a new set of acronyms, but the mindset, tasks, toolbox still work regardless of methodology.

Success and failure do not discriminate by methodology either. I’ve worked with teams that consider themselves Waterfall, Agile, hybrid or generic. I’ve seen huge success and mind-numbing struggle in all types.

I find myself in the midst of the following questions and thoughts often: Does methodology really matter? Does the BA role change based on the project approach? Are Agile and Waterfall really opposites? Can we apply Agile principles to traditional environments? Is innovation really dependent on a particular methodology? How can we boost collaboration regardless of methodology?

Here is what I’ve learned about Agile and Waterfall approaches:

1. We need more collaboration in EVERY project.

What happens after your morning SCRUM or status meeting? Does everyone wander back to their cubes and belly up to their keyboards for the rest of the day, and meander into boring meetings?

Collaboration should be an all-day event! The occasional prairie-dog-pop-up to ask your neighbor a question is not enough. That’s not collaboration!

Lightening does not strike at your desk—you need to get up and get moving. Good collaboration is physically and mentally engaging. It’s not sitting at your desk or lounging around a conference room table. It’s a group of active people standing at a whiteboard with lots of dialog and movement. It’s a small group taking a walk and sharing ideas.

What about conference calls? Meaningful collaboration is harder over the phone, but it’s possible. Virtual collaboration does not involve one person reading a document and asking for feedback. It’s a group of people—not multitasking but—adding, moving, deleting from a virtual whiteboard. It’s a lively discussion where everyone contributes.

Even after years of Agile, many organizations still don’t collaborate enough. Too many teams still delegate work to individual desks and then throw it over the cube wall to their sequestered neighbors.

Teams should use collaboration techniques to see the big picture, to fully engage all stakeholders, and to generate more conversation and dialog.

2. Agile projects have BA tasks.

“Agile” roles, like Product Owner and SCRUM Master, are not all encompassing, neither are any of the Agile methodologies. They are not meant to accomplish everything needed to deliver a solution. Traditional BA tasks are still needed in Agile. You may or may not need the title of “BA” to do those tasks, but the tasks remain relevant.

Planning, monitoring, business need definition, communication, elicitation, requirements validation, traceability, etc. still happen in all projects. The factors that change might include timing, duration, emphasis and documentation. Rigor and adaptability might vary as well, but the basic BA tasks apply in all projects.

In an Agile project environment, you might replace the 400-page requirements document or the exhaustive, step-by-step process models with an evolving prototype or a sticky note-filled whiteboard with dry erase arrows. Either way, the fundamental tasks remain the same despite methodology. The BA uses many of the same techniques to get to the differing outputs. They may use the same technique more or less collaboratively. I hope it’s more collaboratively no matter what approach is being used.

3. Techniques don’t change.

Just like BA tasks, BA techniques don’t change based on the project methodology either. You may try new techniques in new ways at different times, but, all in all, good techniques can be used in Agile and waterfall environments.

Traditional methodologies require techniques for requirements elicitation, analysis, prioritization, change management, issue resolution and more. Projects using an agile approach require techniques for the same functions. It’s really just the external stuff that changes—the timing, structure, format and process. Certain Agile methodologies use a specific set of techniques (SCRUM  User Stories), but they are not all encompassing for requirements activities, they are a minimum to start with, a placeholder for conversation and more collaboration to follow.

We need to elicit requirements from stakeholders for every project. BAs on traditional projects might elicit all requirements at the beginning of the project. BAs on Agile projects might elicit requirements in one small chunk at a time, but the techniques are similar.

4. Stop Polarizing Agile and Waterfall

Agile and waterfall are not opposites—they are not mutually exclusive. Agile is not meant to be a polarizing force that pushes teams away from Waterfall.

Agile is a mindset born from the Agile Manifesto written by 17 men, probably on a napkin, at a Utah resort in 2001. Have you read it? It’s remarkably simple and packed with common sense:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over Processes and tools

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

The intention of the Manifesto was not to replace a particular methodology—instead, the authors wanted to bring visibility to what works to build better software by:

  • Balancing the scales and slide away from the slow, document-heavy, procedural methods of the time
  • Bringing flexibility and fluidity back into the world of software development
  • Creating an efficient and effective process that would bring meaning and purpose into every task

Take note: The manifesto offers values, not demands, process, or requirements. They are meant to guide or refine, not constrain. These values can be applied to all projects.

I don’t think the authors of the Agile Manifesto meant to create such polarization in the industry or organizations and their practices.

5. Don’t freak out your stakeholders.

So given the simple foundation of the Agile approach, the transition to Agile does not need to be an historic event full of pomp and circumstance. Yes, Agile looks and feels a bit different than waterfall, but that doesn’t mean you need warn your stakeholders about major changes. Many of the agile principles can be implemented well on Waterfall projects without alarm or need for major change management. It takes relationship skills, facilitation skills, and confidence.

It is important to help all stakeholders understand the agile mindset, but we don’t need to overemphasize differences. Think about it this way: Why and how will it look and feel different? Is Agile driving the differences or is it just a better way of working?

It really doesn’t matter what it’s called, you just need to help stakeholders understand the value and move them forward gently. Any methodology done well will provide stakeholder value. Keep them focused on the output and how the process gets them to the value. As long as you are efficient, organized, effective, you will keep stakeholders engaged.

It may be the comfort of governance and process they are missing the most when transitioning to Agile. Help them through this, but don’t let it get in the way of being more collaborative and value minded working through requirements.

So, now that I’ve had my say, do you agree? 

Don’t forget to leave your comments below.

Peace at Last: Agile and Waterfall Find Common Ground in Techniques

Written by Angela Wick on . Posted in Articles.

wick Dec3As the battle between waterfall and agile rages on, organizations continue modify their approach to software development. Very few move directly to a pure agile approach. Instead, they pilot agile processes, create project selection criteria for agile projects, they shorten release times, minimize project documentation, and many are creating hybrid approaches blending both Waterfall and Agile.

As software development methods evolve, the BA role and their requirement processes come into question. Organizations begin to ask, “How do BAs fit in?”

Some have BAs do the documentation and for Agile projects what gets documented is anything from photos of sticky note user stories, to formalized user stories with acceptance criteria, to the same requirements documentation as in waterfall but done at the end vs. beginning of the implementation.

Where I see the common thread in the BA role is in usage of key techniques needed to understand the business need and maximize the value the solution brings. Regardless of the methodology, roles, and deliverables, the goal of every project is to deliver value to the stakeholders and organization.

In order to deliver value, project teams need a shared understanding of context, processes, needs, wants, priorities, etc. The elicitation and analysis techniques used to build this shared understanding are the common ground between approaches like Waterfall and Agile.

We can share!

  • BAs can use agile techniques in non-Agile environments.
  • Agile teams can benefit from traditional BA techniques.

Here are a few examples….

Process Modeling

This may be a traditional technique, but process modeling can provide huge benefits to agile teams. A visual process model offers shared context across an organization and/or system that creates meaningful dialogue.

Process models help agile and non-agile teams understand:

  • the process being executed
  • the perspective of the user or the system
  • workflow sequence and timing
  • how users or systems collaborate
  • dependencies

Process models in an agile environment might look different—they might remain high-level and avoid detailed sub-flows. They might reflect only future state. They might focus on user perspective rather than system perspective. However, even a few high-level flows would help agile team members understand the big picture, which can sometimes get lost in short sprints and daily code releases.

Business Rules Analysis

Critical to any business process being implemented, agile teams need to define business rules just as much as non-agile teams.

The timing and depth of the analysis might be different across methodologies. Waterfall project teams might analyze business rules on the front end of the process, resulting in a large, project-wide business rules document.

Agile teams might consider business rules at the beginning of each sprint or face-to-face, with the process owner as they are coding. Agile teams need to have a plan for addressing business rules that cross sprints or a dependent on code that will be developed in other iterations. Many teams use User Stories and Acceptance Criteria where many of the business rules are documented as part of the Acceptance Criteria to the User Story.

User Stories and Acceptance Criteria

These techniques may be coined as “agile” today, but are great techniques for any type of project.

In an agile project, these techniques inspire a high level of collaboration and just-in-time requirements. They integrate requirements, use cases and test criteria in one simple template. The user stories and acceptance criteria templates are generated with an assumption that details will be gathered through direct, usually face-to-face, collaboration at the time of coding.

In traditional requirement processes, user stories and acceptance criteria might be adopted to shorten the requirement gathering process. In traditional projects, it’s often difficult to determine when requirements are “complete.” Using user stories and acceptance criteria in combination with collaboration at the time of coding, might take the pressure off BAs to nail down every detail before a project moves to development.

Collaboration Games

Collaboration games are often associated with agile development. Even the IIBA currently features collaboration games in the Agile Extension of the BABOK.

However, these techniques can and should be used for any project, regardless of methodology.

Traditional BAs can use collaboration games for requirement workshops, issue resolution, identifying needs and features, prioritization, etc. The games inspire creativity and innovation and help engage stakeholders.

Feature Prioritization

A key input to agile development is a prioritized feature list. In many cases, the feature list is fluid and changes as agile teams work through iterations.

Traditional BAs could share a variety of prioritization techniques with agile teams. BAs know how to gather input from multiple sources and make sure that ALL stakeholder opinions are included and aligned.

Agile teams might rely on a narrow group of stakeholders and might not see connections between organizations that would create dependencies between features.

Functional Decomposition

Traditional BAs use functional decomposition to break complex processes and functions into small, manageable pieces for the purpose of analysis. In most traditional environments, each area would be analyzed and all requirements would be grouped together in one project.

Agile methodology relies on breaking complex processes into small, manageable chunks of work. In this case, the functional decomposition would be the skill needed to identify the sequence and contents of each iteration and may be used to break down user stories. Functional Decomposition helps agile teams see where stories fit into a larger process architecture.

Peace at last…

So, now you see—waterfall and agile can live in peace. They can share techniques.

To deliver value to stakeholders, all teams need people with skills to create meaningful dialog, gather accurate information, inspire meaningful collaboration and align stakeholders.

How do you use your BA skills to add value to an agile team? Share your story below.

Don’t forget to leave your comments below.

Cycles of Change: Agile, Waterfall and Continuous Improvement

Written by Julian Sammy on . Posted in Articles. 1 Comment on Cycles of Change: Agile, Waterfall and Continuous Improvement

When version 2 of A Guide to the Business Analysis Body of Knowledge® was released about five years ago, the Business Analysis Planning and Monitoring Knowledge Area discussed a spectrum of project types that range from plan driven to change driven.

Agile methodologies were not yet established, and were described as change driven. This was in stark contrast to traditional Waterfall projects.

Volunteers working on version 3 of BABOK® Guide – now undergoing a practitioners’ review and expert review — are using the Business Analysis Core Concept Model as a foundation. They found that approaches to controlled transformations of organizational systems had the same fundamental purpose: to manage the risks associated with the complexity of a change.

  • For logistically complex changes, longer change cycles are established, with up-front planning to identify potential problems, establish risk management practices, and then to take considered action. This is particularly useful for big, well-defined needs, and high-risk situations. It is very hard to build a dam using Agile.
  • For logistically simpler changes, rapid cycle times are established, with continual reprioritization to target short-term value delivery. This is particularly useful in unstable, dynamic situations. It is very hard to maintain a bridge using Waterfall.

This analysis led the team to generalize and refactor the spectrum of “change driven to plan driven” in BABOK® Guide version 3 The new text discusses three concepts: cycles, complexity, and formality.

Cycle durations describe the typical time frame for delivery of a solution to a stakeholder. This directly constrains many options for the business analyst, including the timing of business analysis work, which techniques may be used to perform business analysis tasks, the degree of formality possible, and the levels of complexity that can be addressed. The team found most changes deliver value in one of three ranges.

  • Value Delivered in Days to Weeks: Continuous improvement and Agile are best known for operating with cycles of this duration, but many support or maintenance changes also have short cycles. While Agile is focused on delivering working code in very small increments, physical objects can also be built in this timeframe, particularly with the advent of 3D printers.
  • Value Delivered in Weeks to Months: Iterative changes are common, especially as “phases” of a project. Phased projects have many small waterfalls, rather than one big one, and can be thought of as a program of many small projects.
  • Value Delivered in Months to Years: Traditional waterfall is most appropriate for changes that are logistically complex. Some complexities result from having long timelines built into the change, as is found in highly regulated industries (such as financial services, power generation) or research (such as pharmaceuticals and aerospace engineering). In these cases, there may be no “minimum viable product” that can reasonably be treated as its own change.

The Complexity of a Situation can drive the cycle duration that is appropriate for a change. Factors that can increase the complexity of business analysis efforts include:

  • number of stakeholders affected by the solution,
  • number of stakeholders involved in making the change (change agents),
  • number of organizational areas affected,
  • number of systems affected,
  • number of technologies or tools affected,
  • amount and nature of risk, and
  • uniqueness and uncertainty of requirements.

Agile approaches are most effective when the complexity in any single cycle is quite limited; there simply isn’t the time to communicate with a large number of stakeholders, or manage a large logistical effort.  Agile tends to be more effective at making less complex changes, particularly when the situation is rapidly changing; course corrections are built into the short cycle time. Longer iterations increase the risk of irrelevance—but some changes take time to complete.

Agile approaches can be combined with longer cycles. For example, some aspects of a large, complex change may be developed using Agile approaches.

As the complexities increase there can be thresholds where the nature of the change transforms into something altogether different. This is a common experience in communications, where the nature of communication is fundamentally different at different scales; a message to hundreds of people cannot use the same tools as a message between two people.

The formality of business analysis work is also related to the duration and complexity of each change cycle. For a close-knit innovation team with six people doing everything in one room, requirements may be largely composed of diagrams on the walls, and pictures of those diagrams—but most situations demand more structure and consistency in the outputs from business analysis work. Templates, document repositories, and requirements management tools may all be used to increase the formality of the requirements. Approvals and commitments to act on requirements will be related to the formality of the requirements themselves.

In many cases, Agile development and Continuous Improvement work can be pursued with relatively informal requirements, and relatively informal approvals. Requirements still need to be complete—measurable, clear, traceable, and so on—and approvals must not be assumed.

Change Cycles and You

There are general principles for choosing the right cycle duration for a change:

  • Given the complexities of the situation, minimise cycle duration and formality of outputs.

In other words, shorter cycles are more likely to deliver more value more quickly, unless they deliver no value at all.

Don’t forget to leave your comments below.