Be careful with "Modern Agile".

I have a problem with a lot of the recent advice suggesting firms looking to adopt agile practices should eschew the stand-ups, estimations and fixed iterations of Scrum. Which is strange as a lot of that advice is coming from respected, experienced Scrum practitioners. However, I think what's happening is a dose of good old-fashioned unconscious competence. These people have been doing agile development for so long and so well, they've forgotten how difficult the basics were to learn.

This isn't unexpected in a world that's full of advice from technology evangelists, all at different stages of skill acquisition and working in environments of varying maturity. Experts advise other experts, and mistakenly believe their advice can apply to novices too. It's happened before: consider the story of microservices.

Modern Agile: The new Microservices

Back in 2014 Martin Fowler wrote a rather well-known explanation of microservice architecture. Working at an organisation where clean, modular code was utterly ingrained to the point of unconscious competence, splitting those modules into tiny services looked like the logical next step. It was unthinkable that anyone would be starting with a monolith that was not separated along clear lines of responsibility - that's just how code is written, right?

What's not so well known is that Martin Fowler has spent much of 2015 writing articles cautioning the use of microservices. Because what happened is the people who don't write clean, modular code latched on to the idea. They took spaghetti and made networked spaghetti. They didn't benefit from reusability and the ability to make new products by gluing together their microservices in different ways. Instead, they just added deployment complexity and network latency to their existing problems. If you read the advice on microservices now it's pretty much this: learn modular programming first.

Learn Scrum first

I think the same thing is happening again. Great Scrum teams concentrate predominately on driving out waste. They're continually making their processes leaner and more efficient. Eventually that attitude leads them to the point where the Scrum rituals themselves begin to look like waste. But there's a reason for that.

Jeff Sutherland in his excellent, concise book on Scrum talks about this in terms of Shuhari, the three stages of martial arts mastery:

• Shu: Novice - learning the forms
• Ha: Journeyman - extending and adapting the forms
• Ri: Master - ignoring the forms, leaving only philosophy

That's why masterful teams can find that the rituals which started their journey become wasteful. They simply stop needing them. No more daily Scrum, because the team communicates constantly. No more story points, because everyone knows what a big or small story looks like. No more retrospective, because the entire team huddles around waste the moment it occurs.

As such a team with ownership and pride in your process, you'd naturally want to tell others about your success. And this is where it falls down:

Masters are rare.

Most teams in the agile world are novices. 22 years of Scrum and most of us are still struggling to make achievable sprint goals, apply our retrospective actions or get through estimation without an argument over a bike shed.

Advice that these rituals are unnecessary are great for the master or aspiring journeyman. But for the novice? It's like the expert jazzman telling the beginner guitarist, "I just pick it up and play what I want". He's forgotten how hard it was just to make a single chord when he started out.

Yes, some of the rituals can be seen as crutches. But if you're starting out with a broken leg, aren't crutches exactly what you need?

Discipline

Going back to martial arts, a lot of what's taught in the early stages is about discipline. This is why the journeyman can adapt it and the master throw it away: they've internalised that discipline. To do things in a disciplined way is more than second nature - a master is physically incapable of being undisciplined.

This is why I still teach teams to start with a very basic, traditional Scrum model. What they're learning are not just the forms, but the essential disciplines I wish to instil as an architect:

• Eliminate Waste (retrospective)
• Communicate (daily stand-up)
• Prioritise (backlog estimation/grooming)
• Get Feedback (demos, frequent releases)
• Maintain Flow (estimation, fixed sprints)
• Achieve Technical Excellence (sprint planning, tasking)

As teams begin to internalise each discipline, they can decide on whether they wish to maintain the rituals associated with it. This is the team's decision, but there is a caveat: you shouldn't decide to abandon something when it's difficult and fractious. If you spend your planning sessions arguing then it's a sign you need to get better at planning and communicating, not a sign that planning itself is wasteful. The sign that planning may be getting wasteful is when every session is a short, painless formality because everyone on the team is united over what needs to be done. Don't get rid of stand-ups when you're struggling to keep them under 15 minutes - get rid of them when they're nothing more than the team spending ten seconds to agree there's no information they haven't already shared with each other.

What you might conclude from this is that the rituals will often stay ahead of the wastefulness curve as a team moves away from shu and through the ha state; as the need for them lessens, so does the time and effort put into them. Many teams in the ha state find the rituals become useful for other purposes - a common example being the journeyman team that chooses to have a morning stand-up mostly as a way to ensure everyone is in on time and there's no waste caused by non-present team members. (A ri team would, of course, be on time every day out of internal discipline and mutual respect. That's what mastery is about.)

Walk before you run

So, in conclusion, I read articles about modern agile or post-agile, and I understand where they're coming from and why organisations can work in that way. But I disagree that these ideas have universal applicability. Without the internal discipline that comes from having gone through the Scrum journey and mastered it, the ideas of eschewing rituals and throwing away planning are more likely to produce messy, wasteful seat-of-pants development than they are enlightened work.

There's no shame in starting out with a basic Scrum methodology in 2015 - if you do it properly, you are already distinguishing yourself from the morass of organisations struggling along with a mixture of seat-of-pants, waterfall, and bits cribbed from various agile methodologies without true understanding. Look at the masters as an aspiration of what you can do once you have the discipline and knowledge that comes from experience; but don't try to copy them on your first day at the dojo.

_{Image public domain}