Agile Mastery - The Dreyfus Model in practice

One of the most common comments I hear when talking Agile practices with organisations is that they ‘have tried Agile but it didn’t work’. The second most common is ‘we totally have teams that do Agile here’, but what they really mean is that there are some stand ups, maybe a wall of sticky notes, and a whole lot of bad habits. I wanted to address these two points as they seem to be what hold many organisations back from truly moving forward with their development practices and successes.

To the first point: ‘We tried Agile but it didn’t work’

I usually start out having them describe what happened. Typically they respond that they ran ‘Project X’ with stand ups and called the Project Manager the ‘Scrum Master’. They had a bunch of meetings. So many meetings. It didn’t gel with the team (who had been thrown together for Project X) and no one knew anything about the practices of Agile methodologies. The project ran for a few months and ended up over budget, the dev’s never could tell them when they would deliver, and the business talking heads felt more comfortable going back to the old way of managing projects - it was just too loose and felt out of control.

Let’s be clear, the above is not ‘trying Agile’. What they did try was a hodge podge of ideas, that someone read about that was all the craze, or maybe there was a person who successfully ran/was in an Agile team before that is wondering why it didn’t work this time.

Agile practices such as Scrum or Kanban take a lot of discipline. More than any waterfall or traditional methodology. The reason these Agile methodologies work is that trust, transparency and ownership of the outcome is embedded into the processes themselves. A client of mine who successfully saw the benefit of Scrum throughout  an 18 month project with us, said it best:

Essentially waterfall methodology is about leveraging the process and trusting the process to deliver the outcome, whereas Agile is about leveraging the people and trusting the people to deliver the outcome.

I could have kissed her for that - it’s the absolute heart of it in one sentence. I felt like a proud parent :)

Which leads us to the second point: ‘We totally have teams that do Agile here’

Sounds promising right? Typically, upon reviewing these teams ‘doing Agile’, they are in the throws of ‘Agilefall’ which can look better than what came before, but ultimately, misses the point why Agile methodologies work well in the first place.

You can imagine how adding a few things like stand ups and sticky notes solve no one’s problems, but just creates a bad view of Agile practices. It feels so much safer to return to the tried and true traditional management style, even though the outcome is so predictably bad, statistically speaking.

The goal with embracing Agile practices should always to put the users/customers at the forefront of the decision making process, to inspect and adapt to quickly learn what is working and what isn’t, and to deliver useable things as quickly as possible to those users to get their feedback. To deliver this well, you need a high functioning, trusting team, and this typically requires some structural changes to enable teams to be set up like this from the beginning. That can take some time or multiple iterations before organisations are able to do their best agile work.

My view of both scenarios come down to the Dreyfus Model - the way in which we learn new skills and move through the stages of mastering a skill through instruction and practice.

Dreyfus Model:

• Novice - rigid adherence to taught rules or plans

• Advanced Beginner - Needs small, frequent rewards; limited "situational perception"

• Competent - Can develop conceptual models, can troubleshoot

• Proficient - Driven to seek larger conceptual model, can self-correct

• Expert - Intuitive grasp of situations based on deep, tacit understanding, monitoring awareness

• Mastery - Holistic recognition, intuitive decision making, absorbed awareness

For both of these scenarios, I usually recommend starting over. Starting over with an Agile Expert.

You don’t learn Agile from someone who read a book once, or did a three day Scrum Master course. True learnings would come from an Agile Coach who has helped organisations transition from traditional methodologies into Agile practices. Starting from scratch means bad habits are put into the past, the discipline can be established, and everyone is on the same page from day one. Everyone is a Novice at this stage, and it can last quite some time before graduating to Beginner. It is best to do this before the team is put together, well before the project is due to begin, as it can take some internal unpicking of processes to set it up well. It’s a bit like learning the theory of playing the piano. Once you understand the theory, you can then start looking at creative ways to play the music.

You may recognise where your organisation is at in my previous posts (here and here) about how to transition through each of these phases, and ultimately, we should be endeavouring to reach the Mastery stage, not just purely being competent at the practice of Agile methodologies.

In my experience, it takes around 3 to 4 years of actively using Agile methodologies in the right way, before becoming a Master of the craft. Once a master, you can break through the methodology and make your own rules, decisions and mistakes, because you know why you are doing it and the foundation for which you are working is strong. Until then, my recommendation it to stick to the rules to create the discipline, and with discipline comes the mindset change - the ‘why’ you are doing it, not just the ‘how’.