Wagile is the worst. It’s a mashup of the agile and waterfall methodologies, and many think this hybrid approach provides the best of both worlds. In reality, it creates chaos and confusion, which — to put it bluntly — ruins effective project management. If you have a wagile scenario to share, please send it to [email protected], and we’ll take a look.
The Problem With Testing the Waters
Dear Kevin and Tommy:
I have worked on agile teams where individual practices (e.g. daily standups) were adopted incrementally, rather than committing and transitioning completely to a specific method such as Scrum or SAFe. This results in an iterative process that is neither agile nor waterfall, with significant inefficiencies and a lot of exceptions.
In my experience, teams with formal training adopted almost all of the documented best practices and were the most successful. I realize this is not always possible, due to budget constraints. How does one fix this for teams already deep in project work?
Sincerely,
Andre in Agony
Many Ways to Swim
Dear Andre in Agony:
The process of adopting a few practices and not fully committing from the beginning is what we would call “testing the agile waters.” It is much like wanting to gradually enter a cold lake from the shoreline instead of quickly jumping in from the end of a dock. By entering slowly, the option to turn back always exists, but the process takes longer and is wrought with fear and doubt the entire time. By jumping in, on the other hand, the swimmer is instantly and completely wet — and can conquer the fear quickly.
“Testing the agile waters” occurs when IT or business leadership lacks commitment and only offers some light training right before go-live. In this day and age, there is a lot of information available for little to no cost. You can simply read articles and books, network with colleagues, follow industry experts on social media or subscribe to online video training. An agile migration does not require you to buy expensive software or send your entire team to training and conferences — although it should be acknowledged that dedicated collaborative training time with the entire team does flatten the learning curve. For leadership to commit, they must first understand the benefits agile brings.
IT and business leaders cannot possibly be up to date on all technologies and methodologies. Helping your IT and business leadership understand the benefits of agile over waterfall is the first — and most critical — step. Without their support, resistant colleagues can and will derail the effort.
To use the lake analogy again, prudent swimmers will first ensure that the lake is deep enough to jump into without causing injury and that there is a ladder they can quickly swim to if the lake is colder than expected. Nevertheless, they are willing to take the risk because they believe relaxation and fun await them. Foolish swimmers run and jump off the end of the dock, assuming the best possible outcome, regardless of temperature or depth. Late-arriving swimmers who see their friends already swimming can safely assume the lake is deep enough and at a pleasant temperature. Finally, if someone or something is chasing the swimmers, they may choose to jump into the unknown lake because the alternative is much worse.
When Leadership Is Reluctant to Commit
IT and business leaders are usually like the prudent swimmer, and they will challenge the agile methodology. Be prepared to address these challenges with relative facts in a helpful tone, not hearsay or guesses in a condescending or confrontational tone. You will need to convince leadership that you are not the foolish swimmer, but rather a combination of the prudent swimmer, the late-arriving swimmer and the swimmer being chased.
By increasing awareness about the positive results the switch will bring — instead of the specific details of the switch itself — you can inspire a desire to change. If that desire is not strong enough for leadership to fully commit, you can raise it by providing examples of successful changes via industry white papers or small internal pilot programs. You can also highlight a burning reason to make the change, such as market competition or a lack of legacy skills in the talent pool.
Once leadership desires the change, you should begin working on your team’s own awareness and desire. However, an agile transformation does not occur at the team level; it occurs at the individual level. Once the members of the team collectively transform their mindsets, the team itself can change. Therefore, while you may be able to introduce agile awareness at the team level, you’ll need to discover each individual’s personal motivation to change. While leadership will focus on improving the typical project constraints (better, faster, cheaper), individuals will want to know what is in it for them.
As the change initiators, you and your IT and business leadership will need to practice patience and listen to their concerns. Some will be concerned over their performance in a new model. Others will not want to change their daily or weekly routine. A few may be close to retirement and not want to put in the effort to change anything or learn anything new. If large change initiatives have failed in the past, many will not trust this change is going to stick and just want to wait it out. Whatever the reasons, each individual will need motivation tailored specifically to them.
The Power of Time
Once IT and business leadership and the majority of the team want to change to agile, you should train the team on new tools and processes. You need to follow this up with time:
- Time for your team to get comfortable using new tools.
- Time for your team to learn and follow new processes.
- Time for your IT leadership to address new resistance.
- Time for your business leadership to adjust to new commitments for feedback.
- Time for your IT and business leadership to get comfortable reading new reports.
- Time for everyone to make mistakes.
By slowing down on deliverables, your team and leadership will not feel the pressure to slip back to old, comfortable (but less efficient) ways of doing things. This will be the hardest thing for IT and business leadership to accept, and it’s why we recommend waiting until a firm awareness of the benefits is achieved before addressing it. A switch to agile is a long-term investment, and as with any long-term investment, positive returns will not come overnight.
To reduce the risk of people falling back to their old habits, IT and business leadership needs to reinforce positive behavior. Even when (and it will happen) a team struggles immediately following the change to agile, recognizing small victories is a crucial action that IT and business leadership should perform.
Sincerely,
Kevin and Tommy
In a Rush? Here’s the Takeaway.
- Ensure leadership understands the benefits of agile and has the desire to change. This is typically achieved through: a) Offering knowledge; b) showing proven success through industry white papers and a small-scale, in-house pilot program; and c) providing a burning reason to switch, such as market competition or a lack of legacy skills in the talent pool.
- Educate the team about the benefits of agile.
- Remove blockers and address concerns for each individual on the team from here on out. You should provide training — which doesn’t necessarily require a large budget (but dedicated, collaborative training usually leads to higher-quality results).
- Provide time to adjust, practice and make mistakes.
- Reinforce positive behaviors and results.
- Address negative behaviors.
