I’m not sure what triggered it, but at some point while I was on vacation a few folks started getting really ticked off about the state of “Agile” these days. People adhering to rules or tools, not understanding what it means to bring agility to a project, or building giant runways in the jungle hoping an aircraft drop of supplies will come by.

I don’t necessarily disagree with the points made by the authors, except perhaps the insinuation that all consultants are a bunch of wannabes trying to fleece money from unknowing customers by using buzzwords and flashy smiles. What I didn’t understand: what was prompting this? Have we just reached a tipping point where the first generation of agilists is getting fed up with dealing with ‘fake’ agile?

To me, the problems we are facing today are an improvement over what we had before. Before, there was an ignorance to the problem, so all of the issues we still have today were compounded by the “head in the sand” approach of just continuing to waterfall, even if it didn’t make sense. At least now we have individuals who do not understand WHY what they are doing is wrong, or HOW to fix it, but at least they know something IS wrong.

So these folks adopted a bunch of tools instead of training their people on how to bring agility to a project.

And these folks incorporated a bunch of processes from a Scrum training seminar instead of communicating with each other more effectively.

And you probably are still required to write a boat-load of documentation instead of spending that budget on features and bug fixes.

And the contract for your latest agile project was probably put together in such a way to prevent any sort of negotiation over scope or time.

(And somebody’s grammar-brain is exploding right now because I started four sentences in a row with the word ‘And’.)

This is OK!

Changing yourself over to an agile way of thinking after years, or decades, of strict waterfall processes is not easy. Any consultant or ‘expert’ that tells you otherwise is selling you swampland in Florida. Most organizations are built, both from an employee and a process perspective, to fail at agile delivery. Our group, a relatively small service delivery firm, is still refining and adapting our processes after more than 2 full years of trying to switch to an agile delivery framework.

Just like a new team trying to get through from forming to performing, the initial iterations yielded a lot of benefits, but also a lot of heartaches. It wasn’t easy to find which tools from the framework would work for our teams, and which wouldn’t. At first, we adopted a lot of standard Scrum practices to see how they would work:

1. 15-minute stand-ups
2. Poker planning
3. Sprint planning sessions
4. Retrospectives
5. Team collaboration areas
6. Burndowns (and Burnups… a lot of burning really…)

Some of our initial stand-ups had everybody sitting down for a 30 minute status update. Every day. Our Poker Planning sessions were much loved in that they weren’t tied to estimates in hours and days, and then we would turn around and try to figure out how many points equals a day of effort. I remember sitting in a retrospective and taking down Start, Stops, and Continues and the group wondering why we were duplicating everything in Start and Stop.

Do you know what happened next?

We learned we were wasting time in our updates, saying stuff that could be said in a smaller group offline. We started tracking points burndown as a ‘total scope’ against a budget, and not caring about how days factored into the equation. We switched to Pluses and Deltas, because that worked better for how our team was thinking.

We adapted.

We changed.

And you can too.

This was very hard for me in the beginning. I have always supported iterative development and continuous delivery of functionality from the developer shop, but I’m also a control freak. Relinquishing control and oversight into all details requires me to give more trust to my team than I have historically allowed myself to do. It was scary, and is still scary. I am very conservative in my estimates and in my willingness to hand over trust to others. If your past is like mine, you have a history littered with people letting you down, or perhaps you just had to do everything yourself to make sure it was right. Coming from this background makes it hard to trust others to do important things.

Now, imagine you are not a developer who understands all the benefits of agile delivery. A person who has never had to be in the trenches and see what the old ways brought upon us. Imagine all you know is that your team doesn’t seem to be performing correctly, and others have put together a playbook to solve that problem.

The first step is the hardest

The important step is happening. People are realizing that something is wrong. Large organizations that seem to have so much red tape it would take a millennium to make a process alteration are actually adopting agile practices. Sort of.

This isn’t the time to say that agile delivery is dead. Agile isn’t dead, it’s just hitting its teen years, getting into post-neo-punk-dub-step, trying to hang out with all the cool kids, and trying to figure out what it’s going to do when it grows up. This is the time when agilists are needed the most to provide solid role models, give guidance, and help others understand what is going on in this wacky world we live in.