The issue: knowledge sharing & alignment

It is frequently seen that even though people are working on the same delivery there still is misalignment on the way of working, with what degree of finish (D.O.D. interpretations), etc. 
This especially happens with different skills and contexts that imply different perspectives on how to look at software.
Either way you place it: knowledge sharing is lacking. 
One of the better ways to learn from each other are Dojo’s, regardless of functional or cross-functional learnings. E.g. a team member with more development skills learns from team member with more testing skills, etc.

Say whuuut??!  Dojo?!

Dojo’s exist in many disciplines.
They are called Hacker Dojo’s, Coding Dojo’s, Testing Dojo’s …

These are sessions where the day-to-day work is done (coding/testing/…) through a projector or screen sharing. 
Fellow colleagues can look for themselves how this person is doing it.

But it gets better: When a colleague has a suggestion or improvement, he/she can take control and show the improvement instantly to the others.

Such sessions open up the opportunity not only for others to take over the keyboard/control, but also for the rest of the spectators to learn from each other and align.

So, no boring teacher with a show-up-or-throw-up slide deck.

Since these kinds of sessions are practical and direct: 

• the benefit of learning is also direct.
• knowledge gaps are being filled in the shortest amount of time.
• the overhead is minimal; it is existing work that is done
• it’s about practical knowledge to get backlog items over the line of “Done”.  So the focus is on aligning. 
• it encourages respect & understanding for each other. Especially when it’s about cross-functional learnings.

What do we need for that?

• Safety.  People need to feel safe to make mistakes and be ‘helped’ by other colleagues.
• Willingness. 
  • to learn: People with genuine curiosity.
  • to align: People with a genuine sense for common purpose rather than individual interests. 
• Tools:
  • A system (desktop/laptop) where the screen can be shared from, or a projector if co-located.
  • A meeting room like for a Demo, with an audio bridge configured if not co-located.
• Work that is waiting to be done. In practice, this should be an item from the Sprint backlog. 
  Nothing should be prepared for this exercise: it’s not a polished demo, but exposing the day-to-day struggle to trigger each other to help and improve. 

A real life example

​

Alignment in testing & development activities. 

In one case we noticed the lead time of testing impact was not in proportion to the development impact.
So organising a testing Dojo was useful.  It could allow to learn from each other. 

Team members mainly occupied with testing could show how they do it, and be assisted by members mainly busy with development. 

The Dojo’s were organized 1 hour / day in the beginning.
The Dojo hero of the day could point out the next guinea pig for the coming day. 
Work got done, things were cleared out.  

The Gains 

The Dojo’s revealed several things:

• testing could be done semi-automatically through SoapUi. Moreover, several tests can be done simultaneously! 
  Despite the fact this is already common practise in UAT & development, people learned from each other that this way of testing could go faster.    
• test data preparation was done in a sub-optimal way:
  • always NEW test data was created, through another system than the E2E flow. 
    people learned by using SoapUi this could be done more effeciently. 
  • test data maintenance did not happen at all. 
    people learned from each other that through a shared Google Docs document this can be facilitated.  
• testing activities themselves took less time than previously in the Sprint. 
  • this did put testing a bit in an uncomfortable position. 
    We are not at the bottom of this, but as far as we discovered: 
    • according to testing this is because of waiting for fixes. 
      However a simple calculation shows a potential huge room for improvement on testing lead time. 
    • according to development fixes did come very fast; the day or the day after. 
  • this uncomfortable position learned:  
    It’s the learning that should be central. 
    It’s the Team that should provide the needed safety to allow for mistakes.  
    It’s only transparency that will help pointing out improvements.