Chart Your Own Path
There's No Absolute Agile; So Don't Be Distracted by Someone Else's Pet Approaches
By Jesse Fewell, CST, PMI-ACP, PMP, contributing editor
I recently asked project professionals I've worked with this question: “What does agile mean to you?” Dozens of people answered, and one pattern emerged: Nobody agreed. For some, the agile movement is about “humans as customers and creators.” For others, it's all about embracing change. Meanwhile, one person declared that “agile = common sense.”
If everyone has a different definition of this agile thing, then how does anyone know where to begin?
None of this is wrong, per se. But if everyone has a different definition of this agile thing, then how does anyone know where to begin? Here are some tips to sail past opinions and seize opportunities.
First, know why. When I ask project leaders why they chose an agile approach, sometimes the answer is correlation: “It's a software project, and we all know that software must be done that way.” Sometimes it's mimicry: “Everyone else in the organization is doing it.”
But the answers that most impress me go deeper. For example, causation: “Our prototype incurs a lot of change due to stakeholder opinions, so an agile approach will get us to the right prototype.”
Avoid “all-or-nothing.” Too many agile experts demand a project adopt their pet approach without alterations. Others will say any hybrid approach or intermediate state isn't what agile is about. But the truth is, nobody ever got it right out of the gate.
A pragmatic approach is better: Try a few techniques related to your “why,” and allow the time and resources necessary to get the hang of it.
Tailor techniques. Once you know why an agile approach is needed, then you can start a conversation about which parts of it should be emphasized and which should be ignored.
For example, if your organization is struggling with product quality, then fussing around with scheduling techniques like story-point estimation is a waste of time. Instead, explore quality-oriented techniques like pairing team members, or remove distractions. Or perhaps your team has a lot of trouble with collaboration and teamwork. Don't distract yourself with a dive into agile requirements. Rather, hold some deep retrospectives with a skilled facilitator to find the source of discord.
Banish confirmation bias. I know several project leaders who declare, “This is how agile worked at my last company, so this is how I want to do it here.” But your new organization may not be so tolerant of the process waivers you used then, or stakeholder objectives may now be less about speed and more about compliance. You get the idea: Agile there does not mean agile here.
Bottom line: Focus on one key problem, pick techniques best suited to solving it, and move forward. PM
|Jesse Fewell, CST, PMI-ACP, PMP, has served on the core team of the Agile Practice Guide and the Steering Committee for the PMI-ACP® certification. He can be reached at email@example.com.|