I’ve talked before about the dangers of a “cargo cult” mentality when it comes to Agile practices, but in this instance I’m going to take a Devil’s Advocate position, at least it will appear that way.  All too often, people and companies start their Agile transitions with training about the “theory” of Agile — what it means, how it should work, what glorious and wonderful benefits are, and to attempt to indoctrinate people into concepts that may be entirely foreign to them and how they’ve done their work in the past.  The problem is, nobody really cares about theory — and all too often the theoretical underpinnings are lost as soon as people get back to their desk and start their next day of work.  Here, however, I’m going to propose a plan to implement Agile practices without the theory, and without creating a “cargo cult” mentality where you’re just going through the motions without understanding why…

SOMEONE Needs to Know the Theory…

First off, this plan can only be successful if there’s someone in the organization who knows, understands, and has lived the theory of Agile practices.  This person should be able to quote from the Agile Manifesto as if by rote memorization — they need to be your expert on what it “really” means to be Agile.  They need to have some training and experience in the principles of Agile, the fundamentals of Scrum, the benefits and drawbacks of Kanban, and know when theory has to bend to reality.  You might be able to get away with bringing in an external consultant or trainer to take this role — but it’s going to be a long-term relationship, not a jump-in / jump-out engagement.  They’re going to need to be there to push when it’s needed, to pull people back when they go to far, and to generally steer the ship that is your organization as it rushes headlong into the ice floe that is Agile.  But they can’t be someone who’s religiously Agile — someone who puts their CSPO or CSM “certification” ahead of their experience.  In short, this is a person who built their experience from the ground up, not just from a book or a classroom.

We Still Need to Understand “WHY?”

Now, if we have someone that fits the above description, we can start to deconstruct the practice from the theory, and essentially flip it on its head:

• Why do we have sprint planning sessions?  It’s not because the theory tells us to — it’s because we need to create a plan for the next iteration that we’ll judge our success against.
• Why do we have retrospectives?  It’s not because the theory tells us to — it’s because we want to reflect on what we’ve done and improve with each iteration.
• Why do we have prioritized backlogs?  It’s not because the theory tells us to — it’s because we want to have a “just in time” pipeline so that everyone knows what’s next in line to execute on.

Note that we’re not doing any of these things because Scrum “tells us to” — we’re doing them for actual, demonstrable, and important reasons that people can understand and adapt to…without being experts on the process or theory. We don’t need every team member to go through a massive amount of training or indoctrination — rather than tell them “we’re doing this because Scrum”, we can tell them a real, comprehensible, and valid reason for everything that we want them to do.  Hell, we don’t even need to use the actual names of the ceremonies if we don’t want to — the point is that we’re connecting the practice to an actual and valuable reason that has nothing to do with the “theory” behind it.

How To Avoid the “Cargo Cult”

The reason that many companies fall into the “cargo cult” mentality is that they focus on the practices without either theory or practical reasons.  They’ve been indoctrinated by the culture of our tech world that being “agile” is a magic bullet to being “better” — and you just have to check these five boxes to experience all the magical wonder that there is.  Now, as Product Managers, we know just how foolish and false that is…yet all too many companies fall prey to this drive to “be Agile” without knowing why or how.  Taking this kind of practical approach actually completely bypasses the “cargo cult” mentality because it focuses on the practical reasons to do something that’s otherwise often far too theoretical.  We can easily build out a translation for most Scrum practices that applies the real-world reason for them:

[table width=”500″ colwidth=”20|100|50″ colalign=”left|left|center|left|right”]
Practice,Reason
Daily Standup, All-team check-in to confirm status and raise blocking issues.
Prioritized Backlog, “Just-in-time” pipeline of work so everyone knows what’s next.
“Scrum Master”, Team facilitator and coordinator to keep developers coding and testers testing.
Sprint Planning, Establish a plan for the next two weeks to assess & ensure progress.
Story Pointing, Determine how complex and difficult (or not) a piece of work is likely to be.
Velocity, Understanding how much work can be consistently delivered across iterations.
“Product Owner”, The throat to choke when a decision needs to be made.
[/table]

…and so on.  This is just small sample, but every thing that Scrum and Kanban tell us we “should” do really does have a clear and cogent benefit to those who are involved in the teamwork as well as the organization as a whole.  And, speaking from experience, if you can’t tie these practices back to a process-independent reason, you’re going to struggle mightily to actual see the value from them once your plan makes contact with reality.