Coach? Consultant? Trainer?

Language is a funny thing.

As philosopher Wittgenstein said "The limits of my language mean the limits of my world."¹

Or, to take another angle, as Steve Young put it "Perception is reality" ²

Without wanting to re-iterate my whole earlier post, I would just like to shine a light to the fact that outside the agile realm the coach is much more prevalant in sports than in psychology (e.g. life-coaching).

And a sports coach acts quite differently from a life coach. Can you imagine a group of people who hire a coach because they want to become a soccer team and that coach would start by asking everyone how they think soccer should be played? If the distance of the goals is to their liking and whether a ball would be the best thing to play with?

If you can imagine this scenario, then I guess, it is either with a sarcastic glance at the way many agile coaches work today or you where reminded of some kind of comedy.

Life coaching, solution focused coaching, systemic coaching all have their places – even in soccer coaching – but usually not in the beginning when the players still are unaware of the rules of the game, not well versed in the moves and inexperienced.

And by the way: the oldest mention of a coach in what later came to be the agile realm was from eXtreme Programming (XP). To quote my aforementioned article and paraphrase from eXtreme Programming explained:

“... the [coache’s] job duties are as follows:

• Be available as a development [programming] partner [...]
• [make refactoring happen]
• Help programmers with individual technical skills, like testing, formatting, and refactoring
• Explain the process to upper-level managers.”

or – on a later page – “Sometimes, however, you must be direct, direct to the point of rudeness. [...] the only cure is plain speaking.” And also “[...]I am always in the position of teaching the skills [...] But once the skills are there my job is mostly reminding the team of the way they said they wanted to act in various situations. The role of the coach diminishes as the team matures.”(p 146)

So maybe – just maybe – it would helpful to be aware whether the team needs a sports coach or a therapeutic coach.

I find that both are appropriate at different points in time, but I have seen a lot of cases recently, where the client was looking for –and needed– a coach akin to the sports-coach metaphor, ended up with a coach conforming to the life-coaching metaphor and everyone just ended up really unhappy.

till next time
  Michael Mahlberg

---

1. "Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt", – Ludwig Wittgenstein, Tractatus logico philosophicus, 5.6, 1922.↩︎

2. "Perception is reality. If you are perceived to be something, you might as well be it because that's the truth in people's minds." - Steve Young↩︎

Sort! The first S of the 5S ...

...(Seiri, 整理, according to Wikipedia)

When applying the 5S-Approach to software development it is important to not just take the Wikipedia definition verbatim, but to also look behind the scenes.

So what does "sort" mean in software development?

First of all – it is not "sort". [Hirano][hirano-95], who wrote one of the defining books on 5S, describes this pillar as "organization" - the verb, not the noun.

Ideas from production (quoted from Wikipedia)

• Remove unnecessary items and dispose of them properly
• Make work easier by eliminating obstacles
• Reduce chance of being disturbed with unnecessary items
• Prevent accumulation of unnecessary items
• Evaluate necessary items with regard to debt/cost/other factors.

When you think about it, this is very close to "decluttering your life" – but with a focus on the workplace. (you might want to look up “100 items or less”)

How to apply these ideas to software development

Does “organize” mean you have to have a clean desktop? Either the one on your computer or the one your keyboards is placed upon?
Does “organize” imply you should not have any personal items on your desk or walls?
Does “organize“ require you to not have old printouts of code on your desk?
No, No and... Yes! Actually it does mean that you don't have any old, obsolete printouts on your desk. This is where things are quite similar between the workplace in a factory and a workplace in knowledge-work – don't put too many things you don‘t actually need in your workplace. Neither in the physical workplace nor in the virtual workplace on your computer

• Are you constantly clicking on the same buttons? Buttons which don't actually add any value to your work? Eliminate those clicks.
• Is your computer‘s desktop cluttered with old shortcuts? Remove them! Or move them to a special folder where they don't interfere with the day-to-day work.
• Do you have all of the Microsoft products installed but only ever use one of them? Sort at least the icons so that the unused ones are out of the way.

Take the time to organize your personal workplace – it pays of in spades.

The same holds on the product level:

• Do you have hundreds of files, that don't serve any purpose any more? Just delete them! If you're not sure if it is safe to delete them this might be a good time to take a good look at your source-code management system...
• Do you have local copies of old versions of your source tree, so that you can look up certain things? Once again a good option to familiarize yourself with the source-code management system of your choice. And then delete those copies. (And while you‘re at it you might want to have a look at git to get some more leeway with respect to source-code management)
• Do you use google to look up how the functions of your programming-language, libraries and frameworks work? Try thinking about compiling the relevant information and making it accessible locally to avoid things like google driven architecture (German article).
• Do you have dozens of auxiliary (self-made) framworks and libraries? Try combining them while weeding out the unused and obsolete code.

I guess you get the drift – organizing your work in the software world can be tremendously helpful and certainly is a good starting point on the way to a streamlined lean and agile software development process, but of course it is not the only thing that’s necessary. But then again it is called ‘5S’, so there is more to come.

Till next time
  Michael Mahlberg

The term conflict is vastly misunderstood

"We never have any conflict in our team"!

For me that is a really, really sad sentence. I really love to work with teams without quarreling and bickering – but I very much hope that there is conflict.

The meaning of conflict

What is `conflict´ after all? According to the english Wiktionary conflict is:

Noun conflict (plural conflicts)

1. A clash or disagreement, often violent, between two opposing groups or individuals.
   [...]
2. An incompatibility, as of two things that cannot be simultaneously fulfilled.
   [...]

And while almost everybody thinks about the first interpretation, the second one is equally valid and extremely valuable to recognize.

It's all about managing conflict - and that's a good thing

This is yet another thing that popped up when Tom and I prepared our hand on Agile and lean practices course - a lot of the techniques in lean and Agile are there just to handle conflicts in a reasonably civilized way:

• We prioritize work-items because they are competing for development time - there is a conflict for the time
• We queue deployments - there is a conflict for the deployment machine
• We use A3 reporting to point out conflicting interests.
• etc.

Recognizing conflict is an enabler

Without recognizing conflicting interests as such there is no way to resolve the conflict - take the original idea behind (non-automated) continuous integration: Software developers in the nineteen-nineties realized that they ended up with incongruent systems, when they all just committed their work to a central repository whenever they had a working result.
Apart from testing mechanisms and some other technical details, there was also a hidden conflict - the conflict for exclusive access to the system for modification. Recognizing this conflict enables people to find solutions. In the original example from Kent Beck, integration happened only on one machine, thus mediating the conflicting request for access to the system by queueing them. Denying this conflict on the other hand prevents solutions.
(Or this denial leads into misguided attempts on Jidoka like continuous integration servers which should really be called build servers and more often then not are just used as a fig-leave ... but that is another story – which will be up here shortly).

Conflict, there's just no way around it…

…but there are many ways to handle it wisely - by applying tools and techniques to resolve or manage it. As with change in the subtitle of the first eXtreme Programming (XP) book, fighting it only makes it worse. In XP they say "embrace change" - the same is true for conflict if handled responsibly "embrace conflict".

Priorities 101: I have to fell trees ...

Once upon a time ... ... I was wandering around the woodlands, when I heard a faint noise that drew my attention. I closed in on the noise and coming closer I heard heavy breathing and moaning and swearing and cursing - and the sound of an old mechanical saw cutting through timber.
Then I finally came to a clearing in the woods and saw a huge guy covered in sweat, wielding and old and worn out buck-saw to cut slices from an enormous tree he had cut down earlier.
I greeted him friendly and inquired as to why he was swearing and cursing so much. He looked at me friendly and explained with great patience "You know, the work of a woodworker can be really fulfilling if you have the right tools and are able to really excel at your work. But me? I only have this worn out buck-saw and I have way more work to do than I ever can finish."
So I asked him: "But what about those sharpening tools over there? Why don't you use them to sharpen the blade?" He looked at me worriedly. "Haven't you been listening?" he sneered, "I have way too much work to do, I DON'T HAVE TIME TO SHARPEN THE BLADE". And with that he turned around and started sawing away at the giant tree again...

I have heard and told this story in a dozen different ways - but I constantly have to remind myself to take my own advice. It's just too easy to get carried away in the everyday struggle of "getting stuff done" to take a look back at the big picture.
When I worked on the Hands-on lean and Agile practices course together with Tom Breur I realized that I had a lot of tools in my back that I constantly introduced to other people but neglected to leverage in my own work. Re-introducing things like A3 thinking and root cause analysis into my everyday (business) life has proven to be quite effective – and I am really happy that I took the time to sharpen the saw a little bit.

Note to self 13 - you can't assign responsibility, it has to be assumed

Michael, you might be able to say - or even order - that somebody is responsible for something but that doesn't really make them feel responsible for it. If he is assigned that responsibility without assuming  the responsibility he will most likely find ways to delegate this responsibility and to redefine the borders of the responsibility. 

An example for assumed responsibility would be this guy I know who develops his own software for a living - they lengths he goes to circumvent the glitches of the operating systems are impressive. For example even if the java installations on the client machine are completely effed his software will still try to figure out the best match for his needs and will 'just work' - Although he could just lay back and take a position of "Well, if the user can't correctly install java it's his problem" he doesn't. He feels not only responsible for implementing his software. He feels responsible for the users experience with his software. (And given the fact that he is able to make a living from a $30 software package his commitment seems to pay off)

It's unrealistic to expect this kind of behavior from people who are assigned responsibilities - especially if they don't believe in the goals or the underlying beliefs of the people who try to assign the responsibilities.