As part of my job, I travel around to lots of new companies helping get teams started with Agile methods. It’s something that I’ve done for a long time in a lot of different companies. I’ve coached a lot of Agile teams and I’ve worked as a delivery team member on a lot of teams as well.
Something that I’ve noticed more and more lately is an increasing demand for “rules” in applying Agile development. Honestly, this has concerned me for the past couple of years. I always silently gritted my teeth and provided guidance backed up by a lot of “unless” clauses. I’ve usually taught from a “principles-based” approach and encouraged creativity around the principles.
Although I think that I’ve done a solid job in communicating the benefits and application of Agile methods and practices, I also feel like in many ways that I’ve left teams begging for prescriptions, rules, and best-practices. In my mind – those things have always been more problematic than helpful.
On the plane today, I started reading Pragmatic Thinking and Learning by Andy Hunt. By the second chapter, I had that OS!M (oh shit! moment) where a lot of things start to pull together in my mind. This all happened while reading through Andy’s explanation of the Dreyfus Learning Model. Suddenly, a lot of things started to make sense to me from a coaching standpoint.
The Dreyfus Model is a five-stage model that shows how individuals make the progression from Novice to Expert. The Dreyfus Model explains skill acquisition and the related ramifications of how we learn at different stages. This model was originally developed by a couple of brothers that were researching how we learn for some work they were doing around artificial intelligence.
An interesting insight from the Dreyfus Model is that at the Novice stage (the first stage), individuals need recipes. Novices are concerned about their ability to succeed and they don’t have any experience to draw from. Novices aren’t necessarily interested in learning, they simply want to accomplish an immediate goal. They are most effective when they are given the exact instruction of how to proceed. Take out context, take out the edge cases, take out the “it depends” scenarios and that’s what individuals that are new to a concept really care about.
When we move through the stages then context, the edge cases, and the “it depends” scenarios really start to matter and understanding the big picture plays a more relevant role in our learning. This explains a lot of what I have been trying to understand with the desire to have a “one size fits all” or “best-practices” approach to applying agility. In looking back at my own progression, I can see the exact characteristics that are defined in this model.
When I “prescribe” a practice or I provide exact steps for achieving an outcome then I feel like I’ve somehow cheated. This is because I know that there are not any universal truths in how we approach problems with software delivery and with agility. Maybe this feeling that I get should be re-evaluated. Maybe it’s ok to be prescriptive. Maybe it’s ok to provide recipes to new teams. At the very least, this is a great opportunity to re-think my assumptions and my world-view on how to be a great Agile Coach and to spend some time learning more about learning.
I’m looking forward to finishing the book and thinking through the information that Andy has provided in the book so far (I’m only through the first two chapters). It looks like it’s going to be another great release from the Pragmatic Bookshelf.
