Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

 

Agile Mastery - The Dreyfus Model in practice

Mastering Agile practices doesn't happen over night. In todays post, we take a look at why Agile restructuring can get off to a shaky start and unpack the 6 steps to becoming an Agile master.

Posted in Agile, Marketers

Tagged agile

Diana Hennessy

by Diana Hennessy

Posted 29 August 2017

Read post

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.

agile fall

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.

Pasted image at 2017 08 29 02 58 PM

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’.

AgileBooklet

About the author
Diana Hennessy

Diana heads up the Channel Excellence team at SilverStripe, ensuring clients and partner agencies deliver amazing customer experiences through the web, every time, with the best tools and practices. Diana believes coaching executive level leaders in Agile practices and focusing on practical execution of Digital Transformation strategies is essential in delivering large scale transformations in both government and commercial organisations.

Post your comment

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments

Like what you have read?

Sign up for our weekly blog digest sent to your inbox.

Subscribe