Typical training workshops are informative and can be a lot of fun.
Teams get away from their normal work for a week or so, try out new technologies and techniques on prefab examples, give the instructor a quick rating, and then go home to their normal jobs.
Is this the time for traditional classroom training?
Sometimes there are issues that reduce the value or appeal of traditional classroom training:
- The team needs to schedule several days away from their real work.
- The primary output is knowledge transfer, which fades in time.
- Skills learned in the course may not be applied to real code for weeks (or ever).
- Examples are engineered to teach a lesson or make a point; they may not be realistic enough.
- Sometimes the students are not ready to receive the information.
- The preplanned agenda may not fit the perceived needs of the team.
While traditional training still has tremendous value, sometimes these issues are significant enough that training is deferred indefinitely.
How Could We Do This Differently?
What if, instead, we turned this whole idea on its head?
What if it could be more like an intense coaching session or an un-conference than a classroom?
What if the needs of the developers took priority over the instructor’s agenda?
What if the instructor were to teach “just enough” and then move on?
This is the idea of the Real Work Workshop.
The new workshop is one to two weeks of intensive coaching/training in an environment optimized for rapid learning.
During the workshop, the attendees and the leader will work in the company’s own, actual code base.
The team doesn’t need time off from work. Instead, we do their work in the workshop.
We usually refactor some ugly code, introduce microtesting, and use microtesting and refactoring to produce new code.
On top of all of that, we use rapid delivery and rapid feedback from the content provider (PO, Customer, Manager, whatever) to steer our deliveries — an interaction that’s crucial and often missing in agile transformations.
Along the way we may learn any number of other things — unpredictably, according to the distinct strengths and weaknesses of the team.
How do you optimize for learning?
We have some standard behaviors which we find make the workshop effective:
- Working in REAL CODE and delivering REAL FEATURES grounds us in reality.
- We work with a new, unstarted feature so nobody’s half-finished code is exposed for critique/ridicule.
- As we work, we take teaching moments - short lectures to address or explore issues we uncover.
- We track our work with punch lists, and even use them to improve our decision-making.
- We use mob programming as a mechanism to increase the rate of learning and sharing.
- We celebrate our wins.
- We have daily retrospectives.
- We have daily deliveries of code.
- We plaster the walls with hand-drawn posters: illustrations, references, even slogans. By the end of the week, we are sitting inside of a week’s worth of learning.
- We like to have a three-month post-workshop survey to learn what lasting effect the workshops really had on the project.
Posters? What kind of posters?
We record things we’ve done, lessons we’ve learned, and things we want to remember.
What happens after the workshop?
Most teams take the learnings of the Real Work Workshop directly into their daily work.
When used with Scrum Teams, the POs usually leave with a new understanding of development work and a closeness with the team that makes early demos and continuous steering possible.
Team members have real-world examples of tests, including pin-down tests and microtests, and will apply the same techniques to driving new coding problems via tests.
Teams have more developed problem-solving skills. Some participants have become key influencers within weeks to months of a workshop.
Teams reported being more aware of, and effective in, the use of different kinds of tests, from microtests through end-to-end system tests.
Teams begin using pair programming and/or mob programming to share expertise and to more quickly conquer problems that have considerable risk and uncertainty.
Teams have a renewed focus on finishing work early and often.
Teams begin making small improvements which accelerate delivery – often visible first in custodianship of the delivery pipeline and local tooling.
Teams have reported having more knowledge-sharing after the workshop, whether in the form of morning meetings or lunch-and-learn sessions.
Are these workshops hard to run?
It depends partly on the facilitator being a skilled improviser, able to operate without the comfort of a fixed agenda.
Adjusting to different techniques, stacks, code bases, and teams can require a lot of flexibility.
The workshop facilitator has to have the skill and experience to perform intense live, on-the-spot coaching, deal with technology differences and programming languages, adapt to new domains, and help teams to pull together quickly to share their ideas and experience.
The facilitator must be ready and able to model a willingness to learn, which comes with a willingness to be vulnerable and express ignorance. This creates an environment where others can also feel safe to ask questions and to learn new ideas.
It helps if the facilitator has a large body of reference work to draw from.
In short, the style appeals to experienced technical coaches with a strong sense of adventure.
Now what?
If this sounds intriguing, then why not schedule a Real Work Workshop for your team. I think you’ll be amazed.
Have you experienced a Real Work Workshop? Would you be willing to share your experiences in the comments below?
