I have to restrain myself and not be the kind of guy who storms into somewhere, tells people what all they do wrong, what all they do not at all and what all they think they are doing good and which does not bring them anywhere anyway. I did that already and learned that this approach does not bring you too far as a coach even though my observations are shared by other outside coaches (I guess the guys are still mad at me even though … ok - I let it be). Helping others (or an entire organization) is (often) more difficult then I imagine – I consider myself to be a “Stehaufmännchen”.
Back to my current assignment. I have a longish list of findings, I would even say I am drowning in them … and the more I discuss with people, the more findings I get. How to get started in removing impediments and solving issues? Here is what I did. I divided my findings into four sections: (A) issues I can discuss directly with the team, (B) issues I can discuss with the PO alone, (C) issues for the Scrum Master Community and (D) all the rest.
The issues with the scrum master community are relatively straight forward. It is a small group, already open-minded, willing to learn and to change. This does not mean, it is easy. One of my older observation appeared again. The most difficult group of people to facilitate is a group of coaches/ facilitators – funny isn't it? Anyway, I am very optimistic here. We were able to identify rather quickly a set of issues which are related to this group and the SM's role in this organization, and we were able to identify a few concrete action what people can do. Lets see in two weeks when we come together again what has happened. This is not a systematic problem solving approach yet, as one of the items was that the most people are not familiar with a systematic problem solving method yet. One step at the time.
Section D is the most critical and most troublesome one. These are the items in which I try to initiate changes to the system - “Your system output is what your system is currently capable of, and if you want to increase your output you need to change the system”. These items in my section D affect broader part of the organization, they affect several stakeholders as well as cross-team aspects and the solutions typically introduce change contradicting to the current belief system and thus current practices.
My first little success is that I got buy-in from many people to make those issues visible. I got a prime spot – the big white-board in the coffee area :) I just read Kniberg's article on “Lean from the Trenches - An example of Kanban in a large software project” (thanx Nirnaya) and once more the importance of visualization is highlighted. It is one of the issues in this organization – too many things are hidden in complicated and complex electronic tools (I don't like the phrase: “its in the intranet”), where a basic course is needed to get the minimum out of it. I prefer pen and paper for such things.
I proposed to use a Kanban board and now I am working together with other SMs to design the board layout. There are many open issues related to the design, like who owns the board? Who will set priorities and so on – lets see how it will go. One thing I learned is that there is no need to design too much upfront – it will be much easier to decide what to do once you see what is the issue on the board. The challenge here is to convince others that this approach is a feasible one and others can “hold their horses” and give it a try. Besides the findings from the SM community, we also thought that this would be the space for all sorts of organizational issues (at least from that floor) – once more lets see how it will go and what happens once the board comes alive.
And then there are things happening outside this part of the organization and it appears to me that (upper) management is managing change instead of leading change and consequently imposing more actions to the teams to improve the quality situation, so that there is even less time left to fix the problems at the level where they can be fixed i.e. - the code base.
Any suggestions in how to deal with that are warmly welcome.