Saturday, December 6, 2014

On Coaching Agile: Techniques - Show and tell

When coaching agile methodology as well as with any other coaching you are supposed to make your point in a way that coachees are not only able to repeat what you have said but to get the idea of it. They are supposed to be able to adopt the principles to their own daily work. This will only work if you get their attention and to make them listen instead of just hearing. If you do not manage to achieve that you could as well talk about little elves in the trees. The outcome would be the same with regards to agile methodology.

So, what stands between you and a coachees attention very often sums up to pure prejudice, which could be translate into one simple sentence: "This won't work for our code." Very often this simple statement prevented my coachees from listening in the first place. They would attend the training for they are supposed to do so, and they are willing to stand it, somehow. These people will not listen, they are not open to what you want to say. To get their attention is to get around their prejudices. How would you do that?

Many people these days want to publish their own book. There are a lot of book on demand offerings where anyone who hears the call could publish his or her book dreaming of becoming the next Philip Roth or J.K. Rowling. Unfortunately most of them are not at this level. However, they enjoy what they are doing. Many attend creative writing classes to learn about how a novel would be written, what principles should be followed. The result is there are many novels around that reflect these classes teachings. They share the ever same plot structure:

Plot point 2 - Mid Point (Crisis) - Plot Point 2 - Dark Moment (Even deeper crisis) - Resolution - Wrap up

Very seldom there is development, own ideas to what a plot could look like. Most of the time there is just repetition of what has been told. They heard but did they really listen? Has there been something to listen to?

Another shortcoming of creative writing novels are the fact that they tend to TELL the reader a story. Just like this one here:

"Pat has left. Tom was very angry in one moment. The other he was wiping his eyes out. He felt sad and empty, changing moods with a blink of an eye."

Everything said. Does this catch you? Probably not. There is no flesh to the bones, no room for my thoughts to flow around a scene, to come to conclusions about it. Thinking was done for me. These sentences are gone long before the end of the novel. Same goes for many coaches. They would just stand in front of a room full of coachees and read their slides of have their say. People try to get through it without snoring. If I would be a coachee in there I would still have my prejudice and nothing could be done about it. Once out of the room I would have forgotten what might have been said. Why?

Well I just were told something. No one tried to make me thinking.

This what differentiates a serious writer from a creative writing writer is the ability to create scenes, to show me places and people, to make me think about them, to give room for thoughts and still be in control of the flow of the story. The writer makes me think and guides me through the story. Just like this:

"Photographs littering the floor. Pat and Tom at some lovely mansion up in the hills. Pat and Tom diving. Pat and Tom at many places. Pat kissing Tom. Tom hugging Pat. Some of them are torn, showing either Pat or Tom smiling at someone who's no longer there. Tom was standing at the window staring into emptiness with a blank expression. A vase lying shattered between his feet. His cheeks were wet of tears. Suddenly he turned around, kicked a photograph into the next corner and screamed at the top of his voice."

This scene shows the moods Tom are in. The reader is able to think, to figure out what's going on. She will be involved with the scene for the writer SHOWed it to her. And this is what we want to achieve in coachings as well. Get the people involved by showing what me mean. Give them a chance to come to the conclusions themselves instead of telling them what you already know and they do not know where this has come from.

A very nice example I recently was able to experience has been the session TDD and Refactoring with LEGO at Agile Testing Days 2014 in Potsdam, Germany. Bryan Beecham and Mike Bowler showed the effects of TDD, refactoring, technical debt and lack of communication between teams working on the same project with simple but very effective hands on exercises using LEGO bricks. You could physically feel the heavy load of technical debt. You could physically feel the effects of refactoring and TDD. Whether or not you come with prejudices and the strong feeling not to be willing to get involved with this the pure fact that you would be allowed to play with LEGO makes you letting down your defenses. And this is what opens up your mind just enough to be vulnerable for new ideas. When doing my next class room training I want to try this instead of reading and explaining my slides.

Another approach to get around the prejudice and especially to get around the this-won't-work-for-my-code statement would be to actually show that it works for their code as well. Me and my partner spent some time upfront the training to lay hands on the code of the team to coach. We would let them show us some part of the code they do not unit test and they think not to be unit testable at all. Within a week we would create the moving parts required to build and run a first unit test suite. And we would do just enough legacy code magic to get sample unit tests done that proof the approach works. Within the training we would have a session "Legacy Code" and the examples their are taken from the teams code base. This would be the time when we show them what could be done to their code. And guess what we got each time: Wow! No other part of the raining got them more involved and open for discussions than this one. This usually would be the time to go back to refactoring and TDD principles, to go back to test isolation. And every time we did this the teams picked up from there to grow their unit test base steadily. We just had to plant the seed and SHOW them how it works instead of TELLing them that it would be possible.



A checklist to summarize:

Pro:
- makes people think
- gives room for own conclusions
- opens up peoples minds just enough to make them join the discussion
- this-won't-work-for-us will not work anymore

Con:
- for the LEGO thing: the session is harder to control
- preparation becomes much more expensive
- you would need access to the teams code base and some initial support



Read also:

On Sporadics - How to deal with intermittent tests in continuous delivery
Part 1 Part 2 Part 3 Part 4 Part 5 Part 6 Part 7

The opinions expressed in this blog are my own views and not those of SAP

0 comments:

Post a Comment