Growing Up Agile Vs. Growing Up Waterfall

I have been increasingly confronted with students who are trying to transition from waterfall to agileand 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 problems for years. We keep fumbling, creating rework, missing expectations, and creating waste in an effort to do it faster overbuilding 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 place 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 don’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 focusing on the right things?

I also don’t think that leaders want "fewer 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 relevantRelevantSpeed of project completionSpeed to results and outcomesMissed requirements & reworkThe right requirements implemented# of DefectsSatisfied users

The issue is that teams and organizations are measuring BAs and teams on the wrong things. And a 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!.

The "Master Business Analysis Training" is our flagship business analyst course. We have trained 1000s of professionals on the business analysis processes, concepts, tools, techniques, best practices, business analyst certification, and software tools via this program. Through active feedback collected from individuals & corporates, we have perfected this business analyst course via numerous updates and revisions to deliver the best possible results for individuals or corporates.

We conduct a classroom for this business analyst course in Pune and Mumbai, else you can join our live online business analyst course from anywhere. We have trained professionals from the United States, UAE – Dubai, Australia, United Kingdom, and many major cities from India through our online business analyst course. You can send your interest by registering for the. Online Classroom Master BA Training.

for more information visit : https://www.mcal.in/page/iiba-endorsed-business-analysis-training-cbap-ccba

Rishi Mcal In the Business Analyst field, many projects demand wireframing applications to showcase mockups of a proposed system. Typically a wireframing focuses on