Skip to main content

Tag: Methodologies

Growing up Agile vs. Growing up Waterfall…. Let’s Get Real About What Matters Most!

In my classes I have been increasingly confronted with students who are trying to transition from waterfall to agile,

and more and more students who ask, “What’s waterfall?” Those who have never experienced waterfall think some of the waterfall practices they hear about are completely ridiculous, and I have to agree. Likewise, those who are new to agile and have lived a waterfall life for many years, struggle to see how agile will relieve the pain points of yesterday and today.

The common theme with both groups is that they all need to learn, and in some cases relearn, good analysis, communication, and leadership skills. They need to understand how these skills play together in the BA role to deliver great products and solutions to users and customers, ultimately getting business results.

My biggest concern about most agile transformations today, and especially with the BA role, is that we are unconsciously recreating the same problem we are trying to fix. We have been trying to fix the problem of delivering solutions that users actually want and will solve for their problem for years. We keep fumbling, creating rework, missing expectations, and creating waste in an effort to do it faster over building the right thing. Agile, for many organizations and teams, seems to be just another way to speed up the process. What differentiates agile success from agile pain is if the right agile and analysis practices are in pace to build the right thing, not just build it fast. We are all trying to get great solutions users love, fast and with high quality.

When I hear leaders say, “I want projects done faster,” I don’t think they actually mean that so literally! I have no problem confronting this and asking them about it. When I dig deeper, what leaders really want is outcomes and faster results. The way we measure projects is rarely results based, so faster projects doesn’t get results, and the disappointment ensues.   This begs the question, are we defining and measuring the right outcomes and results? Do they align with what the project is trying to achieve? It is actually agile to do so, and waterfall best practices would agree as well. It is a key part of the BA role to work with leaders and stakeholders to define outcomes and results. Outcomes and results that matter! They don’t want the project done by the end of the month; perhaps they want to start seeing users complete their tasks faster with a new solution by the end of the month. Measure what matters! BAs are the role to define the measurements that matter!

When I hear leaders say, “I want less rework and less missed requirements,” again, I don’t think they mean it as literally as we hear it. What they really want is the right requirements implemented to solve the problem or advance the user and business goals. Getting the right requirements to solve the problem, will result in less rework and less missed requirements. Are you scratching your head yet wondering if you are measuring and focused on the right things?


Advertisement

I also don’t think that leaders want “less defects.” Instead, they want satisfied users, and it’s okay if there are lots of defects with satisfied users. It’s not okay to have users with more problems and lower satisfaction because we have a few really impactful defects.

Not relevant

Relevant

Speed of project completion

Speed to results and outcomes

Missed requirements & rework

The right requirements implemented

# of Defects

Satisfied users

The issue is that teams and organizations are measuring BAs and teams on the wrong things. And waterfall and agile teams are having the same issues with this. Unless the real outcomes and results from a customer and business perspective are defined, measured, evaluated and tracked regularly, the risk of project waste and failure is high.

It seems obvious, but why is this so hard for organizations to do? The methodology or framework you choose won’t guarantee this happens and won’t guarantee results.

  • No matter if you are working in a Waterfall, Agile, Wagile, Scrumerfall, or whatever you affectionately call it, my real questions are:Are you focused on what matters?
  • Do you know the results that the project intends to deliver from a user point of view?
  • These are not output results like: How much was coded, tested, etc. or if a feature was implemented. I am talking about results that the software creates for a customer or business.

Things like:

  • Decreased the amount of time it takes for a customer to submit a claim from 3 days to 3 min.
  • Increased sales opportunities by 15% by using AI to prospect and predict potential customers.

BAs play a critical role in defining and delivering results, getting the right requirements implemented and having satisfied users. Focusing on defining the results desired, and then managing and tracking them is key!

5 Reasons BAs are Critical to an Agile Team

I am still in disbelief that so many are saying that there is no role for a BA in agile.

Are you still fighting this battle too?

Though it frustrates me every time, I do understand where this idea is coming from, and I want to share some thoughts and perspectives.

Here is my case for both sides of this industry argument.

The “No BA in Agile” Argument:

The Scrum Guide does not say there is a BA role—it says the agile team roles are scrum master, product owner and the development team. Many teams start with Scrum in their agile transformations and get trained on Scrum and certified based on the Scrum Guide. This is taking the Scrum Guide far too literally!

By using this argument, the focus is on titles when that is not what I believe the Scrum Guide authors intended. As a “guide,” it needs to be generic to be readable and understandable to many different types of organizations with many different titles, and also many ways of organizing titles and roles. The agile team needs to be cross-functional and needs to have all of the skills needed to deliver value to the users/customers. Teams that skip analysis, build crappy solutions. Some teams do not use the BA title, but do great analysis and build awesome products, where other roles are doing the analysis. Teams need people with analysis skills for discovery, refinement, prioritization, elaboration, and delivery work. It doesn’t have to be a person with the title of “BA” who does the analysis work.

Historically, BAs in some organizations have been seen as document zombies. BAs in these organizations simply see their role as cranking out endless pages of requirements documentation and to be note takers. If this is the BA role that you know, I agree, this role is not needed in agile. If you, your team, and organization believe that BAs are more than documenters and note takers, and that BAs facilitate decision making, inspire collaboration and conversation, and analyze beyond what others think and say. Then yes, BAs or someone on the team has to play this role. To bring it full circle, I am not advocating for documentation going away. I am advocating that documentation in the form of long detailed spec documents changes to documentation that is useable in agile. Things like visual models as assets that the team uses to inspire deep conversations. Analysis models that help the BA analyze the context of the data, people, rules, and process to invoke the right decisions about impact and priorities.

The “Agile Teams Need BAs” Argument:

In many organizations, BAs have been seen and used as catalysts for problem solving and advocates user-centered solution delivery. These analysts guide the team on the intersection of people, process, data and systems for the big picture and offer a strategic link to the organization’s systems, products and processes. This view of the BA highlights the skill set needed on agile teams.

That being said, many organizations have many talented professionals titled BA, who have a crazy amount of skills to offer an agile team!


Advertisement

Agile analysis is needed for agile teams to be successful. Agile analysis consists of things like:

  • Analyzing the user need and impact desired
  • Defining, measuring and evaluating the solution against impact metrics
  • Leading the team in user centered thinking
  • Creating a product vision, and value centered roadmap and release plan
  • Creating and refining the backlog
  • Elaborating on the backlog just in time with acceptance criteria
  • Keeping the user centered approach in helping the development team understand user scenarios
  • Keeping the user journey front of mind and analyzing for gaps
  • Leveraging feedback loops to update the backlog items as needed
  • Facilitating deep conversations about the user’s goals and needs

So, if an organization uses BAs already and believes this is what BAs do, it seems counter intuitive to not have BAs do this work on an agile team.
If organizations have never used BAs previously, they may need to consider it to make their agile teams more successful.

5 reasons why Agile BAs are critical to an Agile Team

1. Many large organizations are struggling with the product owner role. They need BAs to partner with POs to bring customer focus as the team refines the backlog and delivers the work. BAs help manage value delivery!
2. BAs have a holistic and detailed view of the customer, user, data, processes and systems. Without this view, teams will struggle to deliver solutions that hit the speed, relevance, and quality metrics leaders are looking for agile teams to hit.
3. BAs truly care and have compassion and empathy for users. It’s in their DNA! When empowered to make users and customers awesome, BAs will rise to the occasion and represent the user needs on the team.
4. Great BAs speed up the team by having backlog items ready for the team. BAs can facilitate high-quality and fast feedback loops with users/customers which are critical to agile, speed and innovation success!
5. BAs are T-Shaped skilled team players. Great BAs have a wide skill set that comprises of technical, leadership, business, analytical, facilitation and communication skills needed to help agile teams thrive! T-Shaped team member are those s that have deep expertise and have the ability to collaborate cross functionally and apply their deep knowledge and skills in other areas to benefit the team.

Is agile analysis leading to success on your agile team? Are BAs empowered to truly play a BA role to help their agile teams deliver real value?

If your team or organization is taking the Scrum Guide too literally and missing out on analysis, you might be missing the key agile success—using an Agile BA!

Top 7 Things BAs should be Doing on an Agile Team

If you are like most BAs today, you are either on an agile team or know that it is coming soon!

Here are the top 7 things that BAs should be doing on agile teams. 

  1. Practicing the product vision in the mirror every day.

That’s right! Know your product vision and know how to communicate it to different audiences, different ways with a consistent message about why the solution is needed, who it serves, and how success will be measured. This typically is some sort of vision statement and high-impact metrics. Together these focus on the result that is expected from the solution.

 For example: The new CRM solution is a solution for our sales executives and account managers to better understand their prospects and customers. Unlike today’s solution it will provide a faster way to find prospects, qualify them, prioritize them and sell to them.

 Even if you are working on defects and enhancements, your product/solution needs a vision!

 As BAs we need to constantly remind the team and stakeholders what the vision is! It helps us help them make decisions, weigh trade-offs and set priorities. It helps everyone stay focused on the user and understand what direction we are headed.

  1. Defining the measurable impact the product is expected to have on the end users and/or customers.

Along with the vision are the high-impact metrics that define the results we are looking to achieve in more detail. These are the BA’s keys to managing stakeholders, priorities and proving BA value.

These metrics should be customer and value focused as well as measurable.

For the CRM example, a metric might be conversion rates and time lines of new prospects. With this we need to know the current numbers and a goal we are looking for this solution to achieve. For example: Today we convert 10% of prospects with an average of 6 months from first contact to first sale. Our goal with the new CRM is to convert 30% in 3 months.

Even projects and features that seem to not impact the end user or customer need to be looked at again.  They typically DO impact the customer in some way, and most organizations can’t afford to impact them negatively.  In these cases you will need impact metrics for both the business and the user/customer.

We track these metrics as we deliver small increments and see how each increment is making a difference in the metrics.

  1. Measuring the impact metrics every 2 weeks or more to see how the team is progressing toward the needed results.

 Yes, a BA can show value by not just defining the metrics but showing the team’s delivery work is moving the metrics in the right direction!


Advertisement

  1. Facilitating feedback loops and working to shorten the feedback loop by defining small slices that the team can get real user/customer feedback on.

 In order to get the metric truly performing we need feedback from the users to see how they feel it is helping them achieve their goals. So, BAs work with the team and stakeholder groups to facilitate frequent feedback loops. Increasing the frequency of feedback loops, requires small increments to be defined in the backlog that the team can get feedback on! BAs, you are on it!

  1. Prioritizing backlog items with the PO that move the high-impact metrics.

 To move these metrics, BAs need to help the PO prioritize what features, enhancements, defects and details will matter most to the metrics. Analysis is key here and BAs are at the center of it!

  1. Refining backlog items to only get the minimum built to move the high-impact metrics in the right direction.

To really make an impact, the analysis BAs do must work to minimize the delivery effort needed to meet the metric. This often means limiting our tendency to work in “feature bloat” mode and only focus on what matters to move the metric. I hear many teams are focused on MVP, and that is really tough if we don’t know what metric we are trying to move with an MVP. Again, BAs are at the center of this critical analysis work to deliver value fast.

  1. Inspire analysis and innovation in others on the team with use of visuals, models and charts that help ignite creativity and problem solving.

BAs who use conceptual visuals that are user focused can be a catalyst to a team’s innovation and problem-solving engine! Lightweight models and visuals make a huge difference! Are you ready to make it happen?

Agile BAs are a critical part of agile teams and can bring tremendous success to the team’s overall performance. Are you stepping up and being the best agile BA you can be?

RISE – Requirements Improve Solution Effectiveness

Prior to coming on-board as an application analyst at GLWA, I would spend 20+ years helping organizations define requirement strategies and requirements for applications that we built. 

Now that I have “driven” out of the automotive industry and “dove” into the wonderful world of Waste Water Recovery where solutions are predominantly purchased, I’m finding that teams report on similar problems with their procured applications. 

Requirements elicitation is, as often as not, treated as a necessary evil. Stakeholders feel forced to spend time completing this work upfront to check off a task on a project plan. The work is treated as though it was not important enough to impact the design, development, test, and launch activities and timeline. 

One can imagine the results of elicitation are often mixed at best, as unpredictable as throwing a handful of candy up in the air in front of a group of kindergarteners; you never know what you’re going to get.  Finger pointing ensues, with quite a few internal and external bruises to show for it. 

We don’t plan to do it right, but we have time and money to do it twice?
~anonymous


Advertisement

Some common problems with lack of solid requirement processes are:    
 

BUILD

BUY

  • Missing requirements
  • Requirements not matching test cases
  •  Design, Build and Test rework
  • Support problems
  • Customer dissatisfaction
  • Missing functionality
  • Functionality not matching test cases
  • Implementation rework
  • Support problems
  • Customer dissatisfaction

 

When a company builds an application off of the results of a poorly defined requirements process, costly issues are quickly resolved regardless of the implementation methodology used (waterfall or agile) –  blame is assigned and money is found to address the issues raised.

However, when a company buys a solution, the situation is quite different as there is a total reliance on the product vendor and their development path. In some of the worse cases, the organization has to start the vendor selection process over completely when the solution fails to address the needs.  More than the budget can be damaged in these cases. 

The risks are arguably greater when purchasing vs. building an application, but the underlying fault in both cases is frequently the same.

Too often solutions are determined prior to understanding Business Requirements

For both built and purchased applications, project initiation often happens before discovery, putting the cart before the horse.  Would an architect allow construction to begin on a building before every plan was drawn, reviewed, and approved?  No, but often companies are influenced by what they are familiar with, such as the applications employees have used in the past or by what an employee hears is the next best tool/toy.  In the world of purchased applications, companies often select the design/tool and then attempt to make their business needs fit the solution.  They want the requirement process to be quick and easy, but they are really just setting themselves up for disappointment. 

Making a conscience effort to elicit requirements prior to selecting a solution enables identification of the following:

  • Problems to be solved
  • True business needs
  • Organizational impacts
  • Goals and objectives
  • CARD considerations (Constraints, Assumptions, Risks, Dependencies)
  • Feasibility
  • Cost

Requirements, for applications both built and purchased, should feed the business case, which in turn informs the purchase, contracts, project charter, project plan, test plan, test cases, implementation, and project closure needs.  When requirements come first, the rest of the project deliverables are executed more smoothly, with fewer errors and increased customer satisfaction.  Reduced rework and lower cost positively impact a company’s budget and resources, but more importantly improves its ability to address other business problems within the organization faster.

 

Quality requirements enable IT to focus more on project delivery and support, which in turn nurtures IT/Business and customer partnerships.

Guiding an organization toward a more efficient requirements process does not happen overnight.  The IT PMO, working hand-in-hand with IT and the business customers can get us there given enough support, time, and patience introducing:

  • A defined project intake process (with full Business Requirements)
  • Accepted elicitation techniques (process flows, use cases, etc.)
  • Accountability for requirements through the procurement and project management lifecycles
  • The use of tools, such as an enterprise requirements management tool to facilitate ongoing collaboration on the requirements

In short, Requirements Improve Solution Effectiveness, therefore RISE to the Occasion!

Lessons Learned or Opportunities Lost?

Let’s say upfront that conducting a Lessons Learned process at the completion of a major initiative or project is a highly desirable and admirable thing to do.

But before you get too comfortable about the lessons learned process that you are about to manage or participate in, please consider some of the pitfalls that can plague the process.

Less is more

The measure of a successful lessons learned (LL) exercise is not the number of “lessons” identified but the relevance, quality and impact of the recommendations that you can pass on to future readers.

Three to five key recommendations will have far more impact than a two hundred line spreadsheet. The object of the exercise is to extract key learnings for future use on similar projects.

The LL exercise will undoubtedly generate a significant number of lessons, but these need to be reviewed and prioritised for your final output. Consider scoring the draft lessons to highlight those that are of sufficient importance and relevance to be worthy of inclusion. In the final analysis, discard lessons that are highly specific to your project, unlikely to be replicated, or items that are not supported by the majority of contributors.

The right participants

Ideally, participants should be invited to contribute from the broad spectrum of players who were involved at all levels in the project, from areas of strategy, planning, process and delivery. However, in inviting a democratic slice of players there are some behaviours that need to be understood and compensated for.

The strategists may want to concentrate on the politics and abstract aspects of the project, and ignore the nitty-gritty of implementation.

The planners and process people may want to concentrate of the efficacy of the process rather than the outcomes.

The delivery people, especially those that were deep within the delivery teams, may have a limited horizon, concentrating on specific issues that may only be relevant to that project.

So care needs to be taken in preparing the invitation list, facilitating the LL process, and generally managing the different perspectives that will arise from the roles and perspectives of each of the players.

Clear process guidance

A well-planned LL process will reduce the amount of time that is required of each of the participants, and also create a well-understood process that is psychologically safe for each of the players.

Generally, the LL process will include:

  • Identifying the LL process framework;
  • Identifying LL categories – time-based, process-based or output-based;
  • Seeking LL events for consideration;
  • Identifying for each offered event:
    • A title;
    • An explanation of the event;
    • Possible causes; and
    • Possible recommendations.
  • Gaining consensus from participants regarding the importance of the LL event, the causes, and the most appropriate recommendations;
  • Prioritising the outputs;
  • Preparing and publishing the LL report.

Advertisement

Psychological safety

The psychological safety of each participant is very important, as you want each person to “open up” and give their honest opinions without the fear that they may be ridiculed or castigated by other members.

Junior members need to feel that they are in a safe environment, and that their contribution won’t come back to haunt them at a later date. They also need to believe that their peers and bosses will respect their contribution during the workshop.

In this regard, the facilitator should seek an assurance from all the workshop participants that whatever is expressed at the workshop stays within those walls.

Participants need to be assured and should feel comfortable that final recommendations will be expressed in a manner that preserves the anonymity of each contributor.

Balancing positives and negatives

Unfortunately, there is a strong tendency for LL teams to identify and develop only negative LL events. This is because it seems to be easier for us to recall and analyse negative events rather than recognising the impact of positive items. Perhaps positive items are just taken for granted as the status quo? Perhaps also its because positive items tend to be related to processes with no emotion attached, rather than actual negative events that may have been emotive at the time?

It is extremely important to recognise key positive events or processes, as these will be invaluable to future readers. It is also a way to provide some balance in the recommendations, and to recognise and celebrate the successes.

If the positive attributes don’t appear to be generated during the early stages of the LL process, then the facilitation must include a specific reflective session to acknowledge key positive aspects of the project, and the extent that these should be published.

The final report should introduce the overall positive aspects first to illustrate that, in the holistic sense, the project or undertaking was quite successful, and why that is the case. (Except of course if the project was a total disaster, and everyone knows it!)

Avoiding recriminations

Unfortunately, a few participants may see their participation in the LL process as an ideal opportunity to criticise other individuals or “management” (commonly referred to as “they”), or to repeat their particular hobbyhorse, possibly to the exclusion of any other considerations.

So, participant selection is vitally important, and so is careful facilitation of the interactive process. However, the LL participant group should be selected as a broad spectrum of players, and some manageable level of antagonism may be a price worth paying to ensure that all relevant views and perceptions have been canvassed.

Optimising resource time

The most common approach is to invite players to participate in a workshop once the LL process and agenda have been developed. However, this approach can lead to a significant time impost for some of the players, especially key corporate executives.

Another approach is to initially seek suggested LL events, explanations and recommendations from players via a well-structured questionnaire, and subsequently to invite key players to a shorter duration workshop specifically to develop and agree key recommendations based on the questionnaire outputs. This approach also has the added advantage of minimising the opportunity for interactive personal recriminations.

The questionnaire approach can work extremely well in a busy environment, although it will require more preparation time from the organisers and the facilitator. Another approach involves interviewing time-poor senior executives in their offices, or by phone, and adding their contribution to the workshop, but again this requires more time from the facilitator.

Publishing and archiving

Apart from any cathartic effect that a LL process and report may have for its participants, really the key objective is to pass on relevant recommendations for future readers who are about to embark on a similar project or undertaking.

Therefore, it’s important that the report is concise and eminently readable, incorporating key recommendations in the body of the report formatted in a manner that future readers will retain. All supporting information should be relegated to a series of attachments.

The manner of archiving is also critical, and since most organisations now use some form of information management system (IMS), the LL report will need to be appropriately tagged and stored for easy retrieval.

Guaranteeing future readership

It’s not really sufficient to rely on passive retrieval techniques via the organisation’s IMS. All LL participants should informally monitor the organisation’s activities, act as advocates, and be prepared to offer relevant reference material and links to future players when the situation arises.