How can you escape the waterfall trap in agile?

Frequent scope changes are usually more of a sign of a VUCA environment than of a waterfall planning approach. However, adopting an Agile way of working may help the team better respond to unexpected changes and emergent learnings.

Other giveaway signs include the presence of quality gates upstream of any part of the process, whether cause or effect of siloed roles; Managers or Team Leads assigning work (a cause of siloed roles); features or whole increments being "released into test"; inter-team dependencies; annual budgeting rounds creating annual project lists; working projects rather than products and many more. "Frequent scope change" is caused by fixing scope too soon, exemplified by detailed requirements documents - so these symptoms are not independent of each other.

The agile approach always helps the company and the team with creating a pseudo shield for unforeseen issues and challenges. It definitely provides a structure, a framework and ease of access/bandwidth in accomplishing larger tasks piece-by-piece.

One big sign which is very easy to spot is when upper layer drives on cost, budget and scope e.g. Product is a separate org and funds the requirement and the delivery team is a separate org working hard to deliver adopting the agile workflow. Such marriage between waterfall & agile are the biggest indicators. Another great way to understand the structure is by visiting the organizations job board an understanding how they position roles for hire.

The first sentence in the "Recognize the signs" prompt section is "The first step to escape the waterfall trap is to recognize the signs that your team is not really agile." For leaders, the first step is to actually recognize if they themselves are not agile leaders. Their behaviors and mindset will always eventually be mirrored in the team.

The mindset shift is essential for successful transformation. In my experience, unless a tipping point of people understand the mental models and mindset, the transformation is doomed to failure.

I don't think this in reality is the second step. Logically it makes perfect sense but in reality, mindset shift is the last thing that occurs. A seed of Agile is planted, we kindle the fire with curiosity, interests and benefits. The intent is to get a driving force of leaders who can help build momentum for the change. Start with basics that build habits habits repeated over time become culture & value. That is where the real mindset shift occurs. Right until that time, it may feel like we are running waterfall in an agile bubble but we need to constantly measure progress & the trajectory of this progress.

And much more; value continuous flow over big batch; breadth of expertise over narrow specialization; respect for all people over reward, recognition and performance reviews; networked organizations over hierarchical; decide just in time over decide as soon as possible; customer satisfaction over adherence to specification ... and much more.

The first mindset shift is not aligning with "agile values and principles" ... it is recognizing that dealing with uncertainty requires different thinking and approaches. This recognition, and then adaptation for uncertainty, transcends just software-related applications of "agile" to agility in any organizational function and even the organization overall.

Not only embracing the new and iterative concepts helps in larger improvement but also provides in removing cognitive and non-cognitive biases which the team or individuals might have around the process. And that moves the needle to get improvement and success.

The practices are there for a purpose; understand the (real) purpose of each. User Stories, for example, are not requirements, they are placeholders for requirements that will be gathered later, and the card contains just enough information to know how to prioritise the story and who to speak to when it becomes top priority. Waterfall mindset people tend to pile ever more information onto the card, destroying a lot of the good work that it should be doing for us - of deferring as much as possible until it's really needed. The same sort of understanding - and misunderstanding - applies to each of the agile practices. So don't just adopt the practices in name; understand the part they play, and why.

Ask yourself a simple question. When do we test? You cannot escape a Waterfall(Or series of mini-waterfalls) if you have traditional staged SDLC when you test after development. Test as early as possible, before and along with the development. Apply Acceptance Tests(ATDD, BDD), do Test-Driven-Development. Use other Extreme Programming practices like Pair Programming and Continuous Integration to encourage a collaborative process instead of making stages.

A lot of online tools help in framing the requirements in the format of user stories and acceptance criteria making the adaptation of agile methodology easier than thought. It definitely might come as an inertia for the start but would become a needle mover to the larger success in the long run.

I think the end measure is value. Have a baseline of the previous state and track how you trend on the output metrics. This will give a fair idea if the right practices are in place or a tweak is needed. Fun fact - 10/10 implementations always iteratively change, revise, adapt and improve. This is the way !!

Indeed. The team should be trained before the agile practice gets adopted by the team and the company. Less to no training might create friction which becomes tough to remove for the longer period.

One good way to avoid the common pitfalls is to have support from leadership. Influence is key to being nimble & kind of disruptive in the beginning.

If your business stakeholders understand the Agile approach so much the better. It's easy for a BA with the wrong mindset to disengage with the regular feedback sessions that are so crucial, especially in the early stages when there might not be much to see.

Avoiding these pitfalls is essential for a successful transformation. We must reiterate agile principles and values regularly and promote a safe environment where people feel comfortable sharing concerns and working collaboratively toward success.

If folks are going to recommend particular classes or certifications, then the Agile / VUCA MBA classes have helped thousands worldwide.

I think, LinkedIn is a great place to start. Find the right groups and never shy away from an opinion. Trigger a healthy discussion and debate. In the end, convince or get convinced.

One of the finest certifications available in the market is SAFe POPM which every program manager, product manager and scrum master should take. It should ideally be driven by the organization. It not only provides theoretical knowledge on the agile practice but also provides actionable insights on the latest developments.

As an advisor to organizations on agile transformations, I recommend celebrating successes and recognizing and rewarding team members for their contributions. By celebrating successes meaningfully, you can create a positive and motivating environment that will help you stay on track and succeed.

Consider how you and your finance are structured. Organisations are often structured by functional specialisation - teams of analysts, teams of engineers, teams of testers. These groupings are useful but they can mean we structure our deliverables in the same way, with work following the structures of the company, passing from one team to another. This can result in what appears of be a waterfall approach. Another thing to consider is funding and finance. This can lead to stage gates appearing in projects and deliveries, aligning these to financial milestones and cycles. This can me decision making becomes driven by financial reporting needs and not the project, delivery or products need. This then begins the shape and distort the work.

Empower people to learn and grow. Create an environment where people feel comfortable asking questions and trying new things. Be empathetic to the challenges people face. Understand and address the concerns of your team members. Focus on progress, not perfection. Don't be afraid to make mistakes and learn from them.