Plus Five Techniques To Change Their Minds
If you’re interested in this headline, it is safe to assume three things about you:
- Your team uses Waterfall methodologies.
- Most people on that team have been encouraged to “Go Agile” at least three times.
- You need to make them more efficient without compromising quality.
Agile is older than Windows XP, yet it still gives developers, project managers and business analysts that “too trendy to be legit” vibe. And their suspicion is reasonable. Like all the other buzzwords that have been so diluted that they’ve lost their meaning, Agile has been bludgeoned by sales teams, recruiters, and overzealous managers who didn’t bother to read the instruction manual. Yet in IT, we say RTFM for a reason…
Remember that your business & your team want the same thing – to produce the highest quality product with the least possible effort. There are five truths that keep a Waterfall team from changing their methods. Fortunately if you approach each truth individually, you can entice the staunchest of Waterfall teams to act more efficiently (just don’t call them “Agile” – nobody likes being labelled 😉).
1. “The ‘Current Way’ works.”
There’s a strong chance that management is happy enough with your team’s performance. The adage “If it ain’t broke…” exists for a good reason. You have documentation signed by stakeholders, and the systems work.
Technically Windows XP still works.
Encourage the team to pick a recently completed project and estimate two things:
- From the project intake to final launch, how many collective hours were spent working on the project
- Within that same time frame, how many collective hours were spent waiting
Parkinson’s law (“work expands to fill the time available for its completion”) absolutely applies to the first bullet, so don’t waste cycles dissecting that number. Focus on that second, rarely quantified, metric. When a team measures inactivity, you cultivate the desire for change – because healthy teams hate to wait.
2. “The stakeholders are too busy to stay involved.”
Typical business drivers prefer share the idea, define boundaries, and stay absent until the project launches. They have other important demands of their time and would rather avoid quality assurance testing.
Plans are worthless, but planning is everything.
Remember that the benefit of the stakeholder documentation process isn’t the finished Word doc, but the conversations that happen along the way. Too often teams adopt Agile and think they can skip that process. That is a horrible mistake.
The documentation process in Waterfall is the cornerstone of why it still works after 45 years. This is where great tools, like https://hackmd.io/, can evolve the documentation process in a natural fashion. Try moving from Word to a hosted service that forces minimalist formatting, while including modern collaborative capabilities and version control. Combine this with the best practices described at https://plainlanguage.gov/, and your solution will harm no trees yet everyone is on the same page.
3. “The list of features can’t change.”
In many organizations, it is the stakeholder’s responsibility to understand what the business & customers need and it is IT’s responsibility to create the system to fulfill that need. By assuming positive intent, IT should expect the stakeholder to only detail features that are essential to launch.
Visualization of progress is a beautiful thing.
If your stakeholder is physically near your department, write every feature request on an index card and pin it to a wall. If they’re not near your team, use Trello.com and set that as the stakeholder’s homepage.
Whether you’re Waterfall or Agile, everything is either To Do, Doing or Done. Once visualized in a way that makes dismissing a feature seem trivial (especially compared to rewriting a requirements document), it is mesmerizing how vital features requalify as nice-to-have.
4. “We can’t risk bugs getting into production.”
When IT systems fail, the business notices and the results can be catastrophic. This risk grows if the previous launch had bugs in production that should have been caught. If teams move faster, their odds of post-launch bugs increases drastically.
Know your risk tolerance and measure your Bug Factor (number of bugs × time since inception).
After a project has launched, calculate your Bug Factor. Discuss at your retrospective how this number compares to other projects.
| A retrospective is a post-launch meeting where a team discusses the good & bad parts of a project. Although tied to Agile ceremonies, it stands wonderfully on its own for any type of department or business. |
After your project launches, visit RetroMat.org and install Microsoft’s “Team Retrospectives” tool. When you spend 90 minutes reviewing what happened, your team can check if they’re spending the right amount of time fearing risk – or if they can start to tolerate more.
5. “We don’t have time to learn a new method.”
Your team likely has a dozen projects in the queue. They don’t have time to take seminars or rework everything in flight. Odds are there isn’t budget for the retraining either.
You can’t “Go Agile” using Waterfall methodologies.
Remember why you’re thinking about this – you want to increase your team’s efficiency. Think of “changing the process” as project and break it into distinct units: documentation, communication, engagement, and learning. Measure what you want to change, implement, review, and repeat until satisfied.