Let's have a look at the drivers of managers
That's an interesting point. Typically we would say managers main driver is to optimize their field of responsibility, aligned with the goals of the whole organization. Now let's face reality. The drivers of managers are deeply bound to the culture of the company. Within a supportive team culture this main driver will guide through. In command, track and control structures even enforced in controller determined organizations with annual budgeting runs, the primary driver of a manager is to outreach the, by the boss set, annual goal and to get the highest possible budget to do so.
These differences in culture must be understood to recognize the consequences that determine the derived actions in management and to see how Kanban might be misunderstood or even abused.
Kanban and the theory of constraints behind Kanban gives you the chance to identify bottlenecks in your organization. Next step then is to develop options to mitigate or to get rid of the bottlenecks. The options open you the potential to improve (see http://www.agiledesign.co.uk/2010/theory-of-constraints-for-beginners).
Now we reached the point where misinterpretation or abuse starts. Let's discuss a sample case. And yes, let's be a bit extreme and cynical. The case: When analyzing the Kanban board the identified bottleneck proved to be the manual acceptance testing. The duration of the acceptance testing phase before going into production is far too long.
The command and control manager will and want to see only one option: demanding additional testing resources. The bottleneck will be gone. Beside of this, he will be more "important" because of the increased head count in his department. So even testing monkeys will be welcome. No interest to find keen testers or to develop the team or to invest into software development best practices that produces less defects or use automatic testing to find defects efficient or any other options.
The lean manager discusses these options like automate testing, train people, avoid defects in development. Even an invest into requirements engineering might be an option to elicit requirements, user stories and input just in time and as close to users and stakeholders as possible. It depends on how good the good the management skills are what options he will actually implement. Best he cares for together with his team.
Did you get that point? Not Kanban is the reason for strange decisions, the culture of the organization and the mindset of the acting persons are essential whether improving or detrimental actions are derived.
Another interesting question is: why can this happen? Is there a systematic weak point? When I reflect to what I lived to se, the main reason is missing or avoiding transparency as a key principle of lean management and agility. Kanban trusts that transparency is in place but does not enforce it. The command and control manager following a hidden agenda tries to avoid transparency and has the chance to do so even when applying Kanban. And even managers who try to follow lean principles - myself included - struggle often what the right level of transparency really is.
Now let's see the Scrum way. Scrum enforces transparency by concept. Two principles play together. The team as the main player is one principle, the two feedback cycles daily and per sprint are the second principle. It is hard to drive a hidden agenda in this setup. Yes the whole team is able to, but the individual typically not. And in addition, from my experience, a good level of transparency is established. Important things pop up while the integrity of the individual is respected.
So to be successful with Kanban, transparency either must already be in place - the culture thing - or must be active guided. This is a hard to achieve on management level. Imagine the CIO of the organization sets the goal "we have to turn into an lean organization" and passes over this task to middle management. Will the management be able to live with transparency starting from the very next day? Are the managers already working as team or are they rather acting as a group of individuals heading for more or less the same goals? What model to become lean will they choose, the Scrum way or the Kanban way?
No comments:
Post a Comment