German readers might recognise the image above as a Nuremberg Funnel. For the rest of you: the Nuremberg funnel represents the idea that a teacher can simply open a students head and pour in learning.

First off, a warning: this blog entry might be more for me than for you, but its my blog!

Still, I expect (hope) some of you might be interested in my thoughts and reflections on how training, specifically “Agile training” sessions. More importantly writing this down, putting it into words, helps me think, structure my thoughts and put things in order.

Shall I begin?

I’m not naive enough to think training is perfect or can solve everything. But I have enough experience to know that it can make a difference, especially when teams do training together and decide to change together.

One of the ways I’ve made my living for the last 10 years is by delivering “Agile training.” I don’t consider myself a “trainer” (although plenty of others do), I consider myself more as a “singer songwriter” – it is my material and I deliver it. I’ve actually considered renaming my “Agile training” as “Agile rehearsal” because thats how I see it. I haven’t because I’d have to explain this to everyone and more importantly while people do google for “Agile training” nobody searches for “Agile rehearsal.”

Recently I’ve been prompted to think again about how people learn, specifically how they learn and adopt the thing we call “Agile”. One unexpected experience and one current challenge have added to this.

A few months ago I got to sit in while someone else delivered Agile training. On the one hand I accepted that this person was also experienced, also had great success with what he did, also claimed his courses were very practical and he wasn’t saying anything I really disagreed with.

On the other hand he reminded me of my younger self. The training felt like the kind of training I gave when I was just starting out. Let me give you two examples.

When I started giving Agile training I felt I had to share as much as possible with the attendees. I was conscious that I only had them for a limited time and I had so much to tell them! I was aiming to give them everything they needed to know. I had to brain dump… Nuremberg funnel.

So I talked a lot, sessions were long and although I asked “Any questions?” I didn’t perhaps give people enough time to ask or for me to answer – ‘cos I had more brain dumping to do!

Slowly I learned that the attendees grew tired too. There was a point where I was talking and they had ceased to learn. I also learned that given a choice (“Would you like me to talk about Foobar for 30 minutes or have you had enough?”) people always asked for more.        

Second, when I started out I used to include the Agile Manifesto and a whistle-stop-tour of Lean. After all, people should know where this came from and they should understand some of the theory, right? But with time I realised that the philosophy of the manifesto takes up space and isn’t really important. Similarly, Lean is very abstract and people have few reference points. To many (usually younger) people who have never lived “the waterfall” it can seem a crazy straw-man anyway.

Over the years I’ve tried to make my introductions to Agile more experiential. That is, I want to get people doing exercises and reflecting on what happened. I tend to believe that people learn best from their own experience so I try to give them “process miniatures” in the classroom and then talk (reflect) on the experience.

These days my standard starter 2-day Agile training course is three quarters exercises and debriefs. My 1-day “Requirements, User Stories and Backlogs” workshop is almost entirely exercise based. I’m conscious that there is still more stuff – and that different people learn in different ways – so I try to supplement these courses with further reading – part of the reason behind printing “Little Book of User Stories” is to supplement “Agile Reader” in this.

I’m also conscious that by allowing people to learn in different mediums, and to flip between them they can learn more and better.

My own thinking got a big boost when I learned about Constructivist learning theory. Perhaps more importantly I’ve also benefited from exploring my own dyslexia. (Reading The Dyslexic Advantage earlier this year was great.)

Why is dyslexia relevant here? Well two reasons…

Firstly, something I was told a long time ago proves itself time and time again: Dyslexics have problems learning the way non-dyslexics do, but the reverse is not true. What helps dyslexics learn helps everyone else learn better too.

Second: dyslexics look at the world differently and we have to construct their own meaning and find our own ways to learn. To me, Agile requires a different view of the world and it requires us to learn to learn. Three years back I even speculated that Agile is Dyslexic, as time goes by I’m more convinced of that argument.

So why am I thinking so much about all this?

Well, I’ve shied away from online training for a few years now – how can I do exercises? how can I seed reflection?

Now I’ve accepted a request to do some online training. I can’t use my existing material, it is too exercise based. I’m having to think long and hard about this.

One thought is to view “online training” as something different to “rehearsal training.” That is, something delivered through the online medium might be more akin to an audio book, it is something that supplements a rehearsal. But that thinking might be self limiting and ignore opportunities offered online.

The other thing is the commercial medium. As my training has got more experiential and better at helping people move from classroom to action it has actually covered less. The aim is to seed change, although the classroom is supplemented the actual material covered in class is less; learn less change more! – Thats a big part of the reason I usually give free consulting days after training.

In a commercial setting where there is a synopsis and a price tag the incentive is to list more and more content. One is fearful of missing something the buyer considers important. One can imagine a synopsis being placed next to a competitor synopsis and the one with the most content for the least price is chosen.

So, watch this space, I will be venturing into online training. To start off with I’m not sure who is going to be learning the most: the attendees or the presenter! (O perhaps I shouldn’t have said that, maybe I’m too honest.)

If you have any experience with training (as a teacher or student), and especially online training, I’d love to hear about them. Please comment below or email me.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

“Working software over comprehensive documentation.” The Agile Manifesto

Some have taken that line to mean “no documentation.” I have sympathy for that. Years ago I worked on railway privatisation in the UK. We (Sema Group) were building a system for Railtrack – remember them?

We (the programmers) had documentation coming out our ears. Architecture documents, design documents, user guides, functional specifications, program specifications, and much much more. Most of the documentation was worse than useless because it gave the illusion that everything was recorded and anyone could learn (almost) anything any time.

Some of the documentation was just out of date. The worst was written by architects who lived in a parallel universe to the coders. The system described in the official architecture and design documents bore very little relevance to the actual code but since the (five) architects never looked at the code the (12) programmers could do what they liked.

Documentation wasn’t going to save us.

But, I also know some documentation is not only useful but highly valuable. Sometimes a User Manual can be really useful. Sometimes a developers “Rough Guide” can give important insights.

So how do you tell the difference?

How do you know what to write and what to forego?

Rule #1: Documentation is just another deliverable

Time spent writing a document is time not spent coding, testing, analysing or drinking coffee. There is no documentation fairy and documentation is far from free. It costs to write and costs far more to read (if it is ever read).

Therefore treat documentation like any other deliverable.

If someone wants a document let them request it and prioritise it against all the other possible work to be done. If someone is prepared to displace other work for documentation then it is worth doing.

Rule #2: Documentation should add value

Would you add a feature to a system if it did not increase the value of the system?

The same is true of documentation. If it adds value then there is every reason to do it, if it doesn’t then why bother?

Rule #3: Who will complain if the document is not done?

If in doubt identify a person who will complain if the document is not done. That person places a value on the document. Maybe have them argue for their document over new features.

Rule #4: Don’t write documents for the sake of documents

Don’t write documents just because some process standard somewhere says a document needs to be written. Someone should be able to speak to that standard an explain why it adds more value than doing something else.

Rule #5: Essential documents are part of the work to do

There are some documents that are valuable – someone will complain if they are absent! User Manuals are one reoccurring case. I’ve also worked with teams that need to present documentation as part of a regulatory package to Federal Drug Administration (FDA) and such.

If a piece of work requires the documentation to be updated then updating the documentation is part of the work. For example, suppose you are adding a feature to a system that is subject to FDA regulation. And suppose the FDA regulation requires all features to be listed in a User Manual. In that case, part of the work of adding the feature is to update the user manual. There will be coding, testing and documentation. The work is not done if the User Guide has not been updated.

You don’t need a separate User Story to do the documentation. In such cases documentation may form part of the definition of done.

Rule #6: Do slightly less than you think is needed

If you deliver less than is needed then someone will complain and you will need to rework it. If nobody complains then why are you doing it? And what value is it? – Do less next time!

This is an old XP rule which applies elsewhere too.

Rule #7: Don’t expect anyone to read what you have written

Documentation is expensive to read. Most people who started reading this blog post stopped long ago, you are the exception – thank you!

The same is true for documentation.

The longer a document is the less likely it is to be read.
And the longer a document is the less of it will be remembered.

You and I do not have the writing skills of J.K.Rowling, few of us can hold readers attention that long.

Rule #8: The author learns too

For a lot of documentation – and here I include writing, my own books, patterns, blogs, etc. – the real audience is the author. The process of writing helps the author, it helps us structure our thoughts, it helps us vent our anger and frustration, it forces us to rationalise, it prepares us for an argument, and more.

So often the person who really wants the document, the person who attaches value to it, the person who will complain if it is not done, and the person who will learn most from the document is the author.

Join my mailing list to get free updates on blog post, insights, events and offers.