You
know: I strongly believe that Agile values and principles apply and work
very well whenever you have a complex problem to solve, something that you have
never done before.
So, if you have a vision of what to reach, but do not know
where exactly you’re going and your domain is not deterministic, there’s no
chance you can define your path upfront: the most sensible approach you can try
is to do one step at a time and strive for fast feedback to verify your
assumptions and adjust consequently.
Therefore an Agile approach suit very well many different
fields, even outside IT, given that people involved in solving the problem have
the right domain knowledge.
For instance, as a trainer, I use an Agile approach
for designing and delivering my Agile and Lean courses to Product Owners, Scrum
Masters, Teams and managers.
Last week I got interviewed by 4 students from a Human
Resources Master (a psychologist, a sociologist and two economists) about my
thoughts and experience on applying agility to training and education, which is
actually a complex domain. The interviewers resulted to be very passionate about the
subject and it was really an interesting 3 hours long discussion about many
aspects.
I will try to summarize the outcomes here by using the same
pattern we followed during the session: going through the values in the Agile
Manifesto and try to understand how they can be concretely implemented in the
domain of training development and delivery.
- Individuals and interactions over processes and tools
We normally use a collaborative team
approach (2-4 people) when designing a new course. We try to understand the
learning needs of the client and ideate possible solutions that are pulled from
the backlog and implemented incrementally by leveraging on pair working as much
as possible. We use a task board to visualize the work and understand the
progress.
We apply pair training for
delivery and try to foster a collaborative approach in the class, where the
trainers are mainly facilitators of people learning using different teaching
techniques.
We use tools like working
agreements to set a stage of ground rules for the class. Understanding is
prioritized over delivery of a pre-determined content and physical tools and
face-to-face conversation are preferred over other ways like web-based
training.
- Working software over comprehensive documentation
We try to get feedback as fast as
possible as we proceed with the training design, by showing concrete examples of
what we have in mind (slides, activities, other material) in order to validate
our assumption and verify whether they match clients’ learning needs. That’s in
contrast with detailing the training contents up front in a document and hoping
to get feedback on that, where clients do not have necessarily the domain
competence to understand and to map it with their needs.
We also think that learning is
achieved by means of a complex recipe, where magic happens during live training
delivery due to a combination of good material, inspiring activities, group
collaboration and teachers’ skills. That’s why we do not aim at producing
documentary or even self-explanatory material, which often gets the result of
having neither good training material nor good documentation. Training should
inspire, provide a vocabulary, create curiosity and new questions, which can
best be satisfied on the web or by reading books.
- Customer collaboration over contract negotiation
As I said, fast feedback is crucial.
For that reason you need to get your client involved in designing the training
with you. That’s why we engage an early collaboration which happens
face-to-face when possible or remotely (via mail, chat or phone/video calls).
When our contact person is not
the primary customer of the training, we try to get in touch as soon as
possible with a number of training participants (when they are available) to
interview and get a better understanding of their learning needs or even help
to get themselves understand their needs.
- Responding to change over following a plan
We try to keep our options open
until the last responsible moment, both during course design and delivery.
We’re open to late requirement
changes as much as possible, stated that they fit the allocated timing for the
training and propose other items to down prioritize if we think it adds too
much to allocate in the given time frame.
We divide the course in modules
and monitor the progress of the delivery by means of tools like task board or
burn-down chart, so that we’re ready to adapt. We follow a time-first planning
approach: we always finish on time and if the timing doesn’t go as planned, we decide
which modules to cut together with the class.
Looking forward to your comments, if you’re interested or
have experiences in the field of agility applied to training.
P.S. Thanks Valentina, Lydia, Patrizia and Francesco for the awesome chat and all the best for your work.
Quando progetto una giornata di "training" applico di solito cinque principi:
ReplyDelete1. progetto il prima, il durante ed il dopo: in modo da garantire uno sviluppo successivo (il dopo), ed una collaborazione di co-design(il prima)
2. progetto il feedback finale con un modulo formale fondato sulla customer experience
3. cerco, ma non ci riesco sempre, un feedback dai partecipanti nel "durante" per chiarire e adattare
4. il format è sempre molto interattivo (conoscenza tra i partecipanti, flip chart per ideare/valutare, ecc. ) e fondato su "casi", anche dei partecipanti
5. cerco di liberare le emozioni nel gruppo
Il tuo approccio "agile" mi piace perché introduce maggiore consapevolezza ed uso del feedback continuo e per una impostazione generale molto attenta a cogliere le esigenze dei partecipanti.
Grazie per le idee e per la chiarezza descrittiva.
Grazie per il feedback e per aver condiviso il tuo approccio.
ReplyDeleteE' estremamente "rewarding" per me, sapere di aver scritto qualcosa che possa essere di valore per altri professionisti.