Agilifying Agile Coaches: 2 of 6

What People Often Get Wrong Is The Difference Between Different And Wrong.

I was at a rather fine conference last week. The conference was good, the people great

As we all know though, nothing is perfect. I watched one session where the presenter started to talk us through their approach. They prefer to work in a continuously integration approach rather than as Scrum does with branching.

Then they spoke about how they prefer Kanban to Scrum, as you can launch more frequently, unlike with Scrum which only allows you to launch every 2-4 weeks.

Now, as you probably know, these things were wrong. Factual errors. Mistakes made by the presenter. Scrum doesn’t even comment on engineering practices, but a lot of Scrum teams use Extreme Programming. And Scrum does not stop you launching as frequently as you want.

I myself (as a very ex-developer), liked to work in a CI/main branch style, and prefer frequent/daily releases. We did this on our very first Scrum product delivery back in 2003/4.

However, sometimes people confuse different with wrong.

If we revisit Cynefin, (see last column), it talks about complicated work normally involving good practices. Just remember, good does not equal best. Just because something works in your context, and perhaps many other contexts, does not mean all contexts. This is why the idea of best-practice-suitable-in-all-contexts is best left in the simple domain of work. In complex work we could be looking at emergent practices, that evolve as we learn and gain feedback.

This could sound like an excuse to avoid something like Scrum, but I would suggest that could be an error. The philosophy of Scrum, is of a meta-framework to allow you to inspect and adapt your products and processes. So, Scrum really is the mechanism to discover which practices and approaches are most appropriate, and is not the practices themselves. But either way there are a range of practices that we could adopt and/or evolve.

As an example, I was once hired to produce a 60-minute session on something Agile, for a large insurance company. I chose to do the session on Agile “project” initiation approaches.

I ended spending about a month developing the presentation. It did not seem the best return on investment for me at the time.. But it has been the gift that keeps giving!

I interviewed a range of companies (IIRC seven or eight), and did a site visit for about half of them. I wanted to find out what they actually do to get Product development going, and how Agile they feel they are.

The results were in one way not surprising. The more “Agile” they felt, the shorter and higher level the initiation processes were. (The one exception, was one company that felt chaotic and had almost no processes at all!)

The other way more interesting. Each had effectively grown their own approach. Each had inspected and adapted their approaches. Each had adopted and co-opted other good practices (Kanban, Lean Start-Up, etc) into their models.

So they (even the very limited, barely agile companies) were being “agile” with their approaches.

Or were they?

You see, some had adopted other practices into their approaches. One company based theirs around the classic PRINCE2 approach. (https://en.wikipedia.org/wiki/PRINCE2)

Now, whether you are fond of PRINCE2 or not, (and it has slowly evolved over the decades), it does still encourage a very traditional project approach in most implementations I have seen.

So could that be “wrong”?

Wrapping core practice with subjective good practice with potentially bad practice? Is that a recipe for success? Or disaster?

ENTER STAGE LEFT – SCRUM.

A lot of Scrum is not Scrum.

I have heard a fair bit of bad mouthing of Scrum across industry. Like Ford or Hoover or Google, it is often peoples go to mental model when someone says “agile”.

And like Ford, Hoover and Google, being popular and famous has its disadvantages. There are many many many half baked Agile implementations, most based around the most popular approach, Scrum.

I remember at one conference, a speaker standing up and declaring they are stepping away from Scrum… They are stopping using Velocity

//Cue shocked audience.

And I thought…. Great! Velocity isn’t part of Scrum, it’s just a practice a lot of us use. It gets abused in many companies, so good for you for finding another way.   

But it was then I realised, that a lot of people think it is part of Scrum.

Ah. Confusing a “good practice” with an essential core one, is a mistake. They are different. You could be throwing the baby out with the bathwater.

ENTER STAGE RIGHT – PURSUED BY AGILEBEAR

THE NIGEL SCALE.

https://nigelbaker.wordpress.com/2011/08/01/the-nigel-scale/

I first published The Nigel Scale on the private Certified Scrum Trainers (Now Trainers and Coaches) forum sometime around 2009. I published it publicly in 2011. It is now in use by at least one coach on earth. Me.

Simple put, The Nigel Scale was a model originally created to differentiate between what is Scrum and what wasn’t, back before documents like the Scrum Guide (www.scrumguides.org) existed. This was a time when Scrum was still quite malleable.

It was used in discussion amongst us trainers to help us differentiate what should and shouldn’t be taught in a Certified ScrumMaster (CSM) workshop.

The model works as follows:

NS1: This is Scrum as now recognised by the Scrum Guide. Before that, it was Appendix C in “Enterprise and Scrum”. The core essentials.

NS2: This is stuff Scrum doesn’t officially care about. The gray area of “Good Practice”. This is where we use our previous experience to help coach organizations to self-organize their own answers to their own complex problems.

NS3: This is Anti-Agile: These are anti-patterns or negative behaviours we stay away from. They have a detrimental effect on a value delivery, productivity, general happiness and moral. In short, risk inflation strategies.

Now, hopefully you can already see that this scale can be useful in many situations – Not just for a esoteric mind game by trainers!

There is a huge difference between core practices, good practices and BAD practices.

As a coach, this is where we can choose appropriate stances, and appropriate discipline. We can start to see, where we should vary or flex, where we should be strict and where we need to cut.

That’s easier said than done, however.

So if I asked you to identify the various elements of this phrase via the Nigel Scale – Could you?

“The Tester put the User Story ticket into JIRA so it would be visualised on the Task Board, and so the Product Owner can calculate Velocity correctly.”

Answers in the comments please!

In my opinion, the general direction of Scrum over the last 15 years has been a gradual thinning out. There is more and more movement of what was “Scrum” into the big box of “good practice”.

So the Nigel Scale can help you better understand the fundamentals of Scrum and better understand the good practices that many add to the framework.

But that isn’t the end. Now you can take my model and apply it to things like… Kanban. I am of the opinion that there is a heck of a lot of “Kanban” in industry today, that isn’t actually Kanban! I remember XP suffering because inexperienced people thought it was an all-or-nothing approach, and thus chose nothing.

Sad.

So, how as a coach can I apply this in the real world?

We could use this model to first identify anti-patterns, and then prioritise these defects and remove them. Again, a whole new topic to discuss! There are a range of impediment removal models available to us as coaches, though I probably wouldn’t want to be the person doing the actual removal. If we collaborate with the teams and management, I am sure we could help them find appropriate mitigation and elimination strategies. You can see a little more here: (https://www.scrumalliance.org/community/articles/2011/september/five-tips-for-impediment-resolution-with-scrum)

That is hard, fixing wrong practices and the causes of wrong practices, but on the scale of “hard things for Agile Coaches” probably not the hardest.

For me, that is the variability of good practices.

Which, looking at the word count (and the clock) is going to have to be the next article!

Here is article 3: https://lnkd.in/dh5EeSQ

P.S. If you want a bit of entertainment (and some value!) before the next article, perhaps run the Nigel Scale over something big and chunky and possibly smelly. like SAFe.

Or even Jira.....