In my time working with both product and consulting companies, I’ve discovered the only practice that’s consistent is that no practice is consistently implemented. Every company, department, and team has its own internal languages and shared histories; its own ways of working that are tailored to that culture. When changes are made to these aspects of a company, which are considered sacred— especially when instituted abruptly or without the right planning and communication—the results can range from unfortunate to disastrous. Entire projects, money, and careers can be washed away in a flood of backpedaling and blame. More often than not, the process itself is implicated. What people forget in the aftermath is that the process doesn’t choose itself: We create these environments; We make the decisions that lead to these results. Whatever methodology we choose might not work out, but is it because the practices themselves are terrible, or because we’re choosing the wrong fit for our projects and companies? Agile methodologies frequently become the scapegoat for any number of failures, and as a result “agile” becomes a four-letter word—or a Method-That-Must-Not-Be-Named.
This series explores the most common explanations companies give for Agile failing upon arrival, and uncovers the real root causes for your company’s split with Agile. Sure, it’s possible that Agile just isn’t “the one” for you. As mentioned earlier, no practice is truly consistent between organizations—it’s nearly impossible to drop any major operational change on a company and expect it to be implemented flawlessly without taking this into consideration. But before you change the locks and put those suitcases full of sticky notes and user story cards on the curb, let’s take a deeper look at your history with Agile to figure out what went wrong and, hopefully, set things right.
[Cue the wistful, nostalgic music of your choice]
“We tried Agile, and there were just too many meetings, so no one participated and it just sort of fizzled out.”
Let me make you an offer: I’ll give you a ridiculously fast car, top-of-the-line and race-ready, but with two caveats:
- You can only drive this car in 25 mph residential areas, and
- You have to stick to that 25 mph speed limit at all times.
What’s the point, right? You’d much rather travel using your preferred method of transport at a speed of your choosing. Some would probably take the deal just to say they’ve got the fancy car, sure, but artifice doesn’t ultimately get a person where he or she needs to go.
The intent of adopting Agile is not to say, “Look, we’re doing the ceremonies! We have sprints! We’re totally agile!” The intent is to enable teams to choose which methods work best for them—equipped with different options and guidelines that can boost productivity depending on the situation—and let them move forward as they see fit. One of the core values of Agile is, “responding to change over following a plan.” If there are too many meetings, meetings are too long, people aren’t attending, or the meetings aren’t productive, question the practices in place to ensure they’re the right fit for the team before taking any other actions.
Feeling Scrummed out?
Let’s take a look at sprint planning, for example. For Scrum teams, the prevailing guidance is to hold planning once a sprint, timeboxed to eight hours per one-month sprint. That doesn’t mean sprint planning has to be eight hours long just because it can be, certainly not if you’re running a shorter sprint cadence. If sprint planning has turned into one person talking about tickets while the rest of the team carefully studies the insides of their own eyelids, work with your team to form a better communication strategy. Questions you might ask:
- What does your team actually need to get out of sprint planning?
- Would time be better spent in advance breaking down features, either solo or in one-on-one conversations?
- What format works best for the team, while providing the necessities to work successfully?
- If the team and project don’t require the boundaries of set sprints, why follow Scrum? Why not consider something more flexible, like a pull-based system?
- If external business pressure, the needs of leadership, or input from stakeholders indicate a specific Agile method might be better, are all parties aware that the chosen course might not be the right one for the team?
Make time to discuss these preferences, and be sure to bring evidence as to how a different path may produce more fruitful outcomes.
Imposing unnecessary ceremonies on your team “because Agile” isn’t any better than me offering you that fast car without a proper track for driving: It will only slow them down, frustrate them, and keep them from finding the pace that works best for them.
“Standup” not “sit-down”
Another common meeting is daily standup. This ceremony of Scrum keeps everyone on the same page with work-in-progress and provides a forum for airing and addressing impediments to said progress. If your standups are turning into sit-downs, dig into the potential reasons why before scrapping them. Consider:
- Does your standup have a set agenda? If so, is someone on the team ensuring that agenda is followed?
- How many people are attending standup? If you have guests attending standup that aren’t on your team, are they aware that their role is that of an observer first?
- Is everyone on the team able to get through their own standup items, and are tangents put on hold for follow-up after the entire team has gone?
When meetings become less-than-efficient, remember that you always have the power to change the format.
Tips for maintaining engagement
Setting expectations for participation is a critical step. Ignoring this can turn a 15-minute rundown of the day into a tangential gabfest that leaves everyone feeling unheard and irritated. Let’s review some do’s and don’t that may help you reignite the value of daily check-ins:
- Don’t hold meetings that provide little-to-no value to the team
- Don’t stick with a process that doesn’t work for the sake of saying, “Look, we’re doing it.”
- Don’t force the team to work in ways that ultimately slow them down
- Don’t let meeting topics run wild
- Do listen to team members and their needs
- Do align with leadership on delivery expectations and practices
- Do work with your team to refine practices, and revisit regularly
- Do plan an agenda, and stick to it
- Do invite only those necessary (you can always send out notes to interested parties)
Most people believe that doing the same thing over and over again and expecting a different result each time is the definition of insanity, but really, it’s the definition of folly. Much like throwing good money after bad, it’s only going to drain the company’s wallet, and the confidence of those following your lead. Why waste your own time—and the time of your colleagues—on a process that’s clearly not working when you could get busy finding out what does? Take the time to build that confidence by listening and adjusting, by being agile in your everyday actions, and you will successfully get your team and organization into a more fruitful— and stable—long-term relationship with Agile.