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?

---

---

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!