Agile

Teach the “why” as well as the “how”

Photo by FourTwentyTwo If we believe, as I proposed last week, that there is an “Agile wash-out effect”, then is it actually possible to be effective with Agile these days without learning it from its originators? If not, doesn’t that mean Agile is a dead methodology?

To recap: there is an effect observed when applying learning methodologies very widely which has been termed a “wash-out effect”. It is that the more steps you are from the originator of the methodology, and the more you try to package it to train more teachers, the more diluted and ineffective the methodology becomes.

I believe that Agile is a very powerful and effective approach. If it is doomed to be washed out then so is any other methodology and we will never collectively learn to deliver technology effectively. There is a circle that needs to be squared if we are to have hope for the future — and I do have hope for the future because I do believe Agile can be learned.

I think the answer comes in being clear about what we are learning. We need to learn and teach not just how to do something, but just as importantly why its like that.

No two scenarios are the same. Applying exactly the same tools in exactly the same way to different situations will not be successful. As I say when describing my general approach: one size fits no-one. That means we have to adapt our approach, our tools and our techniques to different situations, and we can only do that if we have a deep understanding of those things. We need to know why we do them, we need to know what underpins them, and then we can intelligently adjust accordingly.

To give a very simple example: In some situations I have advocated that a senior developer lead the daily stand-up; in other situations I’ve advocated that it’s a business analyst. How the stand-up is run is clearly different. But answering why we run the stand-up helps explain it. The stand-up is about focusing and balancing the priorities of the day, including the needs of the technical and non-technical people. I have found some development teams have been ground down and lack confidence, so if one of their number leads the stand-up then it helps give them more of the voice they need. I have also found some development teams to be over-confident and in need of a steadying hand to prevent them running away in unhelpful directions, and in that case it helps if someone else provides the perspective each day.

Those techniques and methodologies that are very prescriptive can be packaged for learning much more easily. But I would say their chances of success will be more limited. Those techniques and methodologies that are looser are more difficult to learn effectively but are likely to be more effective if they can be learned. It’s too easy to take a broad approach such as Agile and package it for easy consumption — but the results will be far less effective.

Advertisements

Discussion

2 thoughts on “Teach the “why” as well as the “how”

  1. I’m never sure of this “learn why” argument. I think there is something about finding your own understanding through doing, rather than having someone else try and impress upon you their understanding.

    Do we really care why it works, if it works ?

    The technique of asking “what works for us” (the ol’ XP mantra) without doing the autopsy of “why” is most effective, in my experience.

    Posted by John S Nolan | 7 February 2013, 11:56 am
  2. Learning through doing is definitely very powerful, and it’s certainly more powerful to learn that way than have someone tell you. And it’s true that if we have something which works then there’s not much reason to care why it works, as long as it continues to work.

    It gets a bit unstuck in a couple of situations, though. First, if it actually doesn’t work then you’ll need some help. If you apply something that works for other people but not for you then it’s important to have a deeper understanding of what’s going on. Second, if the situation changes (you move environment, or the environment changes) and your thing-which-worked stops working, then again you need to have some kind of deeper understanding to help work out the new thing-which-works.

    It’s true that “understanding why” may not be the only kind of “deeper understanding”. But it’s a very useful one, particularly if you’re helping someone find out what will work for them: this worked over here *because* of X, Y and Z.

    Posted by Nik | 7 February 2013, 12:16 pm