5 unexpected Agile/Scrum lessons I learned by teaching it to others.

by John Christian

As a Scrum Workshop trainer/facilitator, I've come to appreciate just how much I myself take away from the very workshops I give.

Every workshop gives me a chance to interact with another real-world team and I am constantly adapting my material to remain in flavour with the overall Agile zeitgeist in Brisbane especially. I thrive on trends and how I can better use those trends in improving the content of the workshops of the future.

Here are the top 5 lessons I didn't expect to learn by teaching Agile/Scrum to others.

1. The word 'Agile' is becoming an anathema to the original spirit of the Agile Manifesto.

People are becoming more concerned about the process of their Agile implementation than the people implementing it. The processes are supposed to support the people, not force the people into a particular process.

"How are we going to implement Agile?" is the wrong question.

The right question is "How can we innovate faster?".

The answer to the first question will give you a list of processes to follow (the anathema of what it means to be Agile) the answer to the second question will, ironically, become your Agile implementation.

2. Retrospectives are virtually nonexistent.

Retrospectives are the one chance teams get to learn how to innovate faster and yet they are rarely afforded the luxury of doing so. It's a shame because, in my opinion, 'Agile' and 'Retrospective' are synonymous.

Not running retrospectives is like a body builder skipping their protein intake. You've done the hard work but are you building muscles to make it easier next time?

Even if you start simply, start doing retrospectives in a meaningful way. Think of one thing that worked well, and expand on that next sprint and look to overcome the challenges of something that didn't work well last sprint. This is the 'one-in-one-out' approach and a great place to start with your retrospectives.

3. There is a real resistance to cross-functional investment.

I understand more than most (coming from a developer background) how challenging it can be to become cross-functional across your team and their skill-sets. I get it. But just because it's challenging, doesn't mean we say it's not worth it. Cross-functional teams innovate faster. It's a fact.

Like most of the Agile theory - Cross-functionality starts off as a mindset first, the benefits are realised later. Are you willing to dedicate some time in this sprint to cross-pollinate your skills and knowledge with your team? You may not be a cross-functional team member now, but small investments every sprint can translate to a powerful, cross-functional team in fairly short order. Start spending even just 30 minutes a sprint cross-pollinating with your team. Have the UX guy write a session handler in some pair programming session, get the DBA involved with styling some CSS. Do something that forces you to think at a team level, not siloed.

4. Managers want change more than developers.

I really didn't expect this one. Entirely counter-intuitive. I had this preconceived notion that selling Scrum to developers would be easy and that the friction would come from upstream who would be less likely to stick their necks out for change. Nope. The opposite.

Yes, developers are interested in learning, but not necessarily motivated to change. Managers however, frustrated with processes that are overbearing and oppressive, are the ones motivated to change and to start effecting that change in their organisation.

On reflection it might be easier to see why they are seeking out Agile approaches since implementations like Scrum introduce a lot more transparency into the development process. Developers have had (for too long) the monopoly on opaque models. Few managers are allowed to peer into the innards of the development team - so in hindsight, it might not be all that surprising why developers want to protect their castle, and managers are coming to me to help break down the castle walls.

5. The terms 'Agile' and 'Waterfall' are at war - over nothing.

Remember the schoolyard fights where no-one remembers why they started fighting in the first place? In the left corner, Waterfall. The "old" way. In the right corner Agile, "the new age hipster way". If this is your view, then it might be extremely valuable to note that Agile ideals have been around longer than Waterfall. A lot of ancient themes in fact running through Agile course material. I learned more about ancient Japanese culture, martial arts and language doing my PMI-ACP certification than I did in school. Agile principles are virtually as old as humanity. They've carved a niche and become more tangible in software development in very recent years - but the origin at the heart of Agile thinking is undeniable.

I failed to appreciate just how at war the word 'Agile' is with 'Waterfall' - when there really isn't an argument. Waterfall is a proven process for quantifiable projects where the scope either definitely will not or inherently cannot change. There is nothing wrong with the word 'Waterfall' much like there is nothing wrong with the word 'water'. We might see more benefit from using water to quench our thirst than as fuel for our cars, much like we use Waterfall for some types of problems, perhaps Agile thinking or framework for other types of problems.

This is why I do the marshmallow challenge to kick off my workshops, to help practitioners understand when to pick a certain approach over another. Agile is not a project management panacea or cheat mode for project managers. Agile is simply a mindset to tackle complex, adaptive projects specifically (where Waterfall fails) and frameworks such as Scrum is a proposition to help implement that mindset into reality.

Posted by

John Christian