Thursday, May 26, 2011

Why developers love Scrum and Managers Kanban, Part III

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?

Saturday, May 7, 2011

Why developers love Scrum and Management prefers Kanban, Part II

Let's have a look on Developers and their drivers today

My experience is that developers are striving to deliver high quality results, to improve their skills, the working environment and tooling. Feedback, collaboration with peers and education are important aspects to succeed. Scrum supports exactly this. Feedback and collaboration is built into Scrum by default. Additionally Scrum uncovers missing skills in the team. Pairwise programming is a mean to spread skills an of course the demand for trainings might pop up. That's why developers trend towards Scrum. Scrum guides individuals to form and act as a team, to strive for business value and to permanently improve the production process. Developers honor it to be treated as individuals.

There are downsides of Scrum as well. Still developers tend to misinterpret Scrum like this: No documentation anymore, managers are expandable, any regulations or standards of the organization can be neglected, the environment can be setup free and I can take any tool I like to.

Of course this is nonsense if these statements are taken literally. As these statement are threads for managers let's have a closer look on them.

No documentation needed. That clearly is nonsense. Vision documents on different layers of abstraction deliver value. User stories and storyboards are new techniques and result in some kind of documentation as well. Even comments in source code is documentation or automated acceptance tests written as source code. And for sure the organization has the right to demand additional documentation - because of regulations, compliance or security issues and such like. In Scrum we would add a demand for this last type of documentation eventually to the done criteria. If I look around only a very few developers would neglect this. So the statement "no documentation needed" clearly can be rebutted in case managers try to play that card.

Managers are expandable: Of course agility changes the job profile of managers towards creation of business value and foster the team. Change, especially under the stress of a middle manager always is threatening. The statement "managers are expandable" rather should be interpreted that command and control managers have to change towards a lean mindset. A new generation of managers is expected to grow. This new generation of managers cares for shaping common understood and by the team shared and supported vision(s). They care for training and skill sets. They care for a working environment and of course they care for education and development of each individual in the team. Yes, managers, i.e. persons taking responsibility will be there in the future, hopefully! Unluckily my experience is that a pretty high percentage of developers still believe that "managers are expandable". My personal impression is that one out of five delevopers follow this mindset. These are enough so that managers feel under pressure.

Any standards may be neglected: yes there are some rare examples of developers that prefer to work in chaotic state. I have to say I work with developers that care for a healthy set of standards. Standards that make sense. Even establishing architecture patterns in development is kind of a standard. This is the argumentation base to discuss with the few developers that neglect that standards exists. And yes, of course there are organizations where most of developers claim about standards within this organization. In this case I would like to challenge whether the existing standards really support the organization or whether the organization is just over-regulated and should start with lean thinking and avoiding waste. In over-regulated organizations often a manager was the seed of this by pushing in a compliance or standardization idea that escaped and turned into an unstoppable over-regulation carnivore.

Wouldn't you agree that these are scenarios and mindsets that exists out there?
No wonder that developers love Scrum and manager - hmm - at least have respects.

Let' have a closer look on managers in my next post.

Why developers love Scrum and Management prefers Kanban, Part I

Why developers love Scrum and Managers Kanban

Just to clean this out: This is not a discussion of kind 'what is the better tool: Scrum or Kanban'. This post is about misunderstanding or even abuse of concepts and terms. This post is about organizations changing from traditional toward agility and lean.
Let's have a look into enterprises. My observations are that Scrum has the better reputation at developers then on management level. IT-professionals talk about retrospective, emerging architecture, story points, daily stand-ups and such like. Kanban once again is more often requested and discussed by managers. They talk about bottlenecks and resources.

I often get emails like this: "hey, can you run a CSM class for the X-team" by a team lead or a request by a manager "I would like to run a Kanban workshop with my colleagues from management".
So I started to asked myself why?! Why do developers love Scrum and Managers Kanban?!

To answer this question the motivation and drivers of people have to be taken into account.
Drivers of developers are to deliver high quality results, to improve their skills, the working environment and tooling. Feedback, collaboration with peers and education are important aspects to succeed. Scrum supports exactly this. Feedback and collaboration is built into Scrum by default. Additionally Scrum uncovers missing skills in the team thus resulting in requests for training. That's why developers trend towards Scrum. There are downsides of Scrum as well. Developers tend to misinterpret Scrum like this: No documentation anymore, managers are expandable, any regulations or standards of the organization can be neglected. Yes there are some of these exemplars of developers out there, I met some personally. No wonder managers get panic.

Now, let's have a look at managers. Their drivers are either to optimize their field of responsibility - these are the lucky ones - or to outreach the goals set by their boss. Essential tasks at least for the goal driven managers therefore are to keep resources on the least needed level to reach the goals, identify bottlenecks on the way to go and collecting arguments why in case of failing this had been unavoidable, because the reasons of the failure are under somebodies else responsibility. Kanban supports at least some of these tasks, i.e. identifying the bottlenecks. The downsides of Kanban are that a certain type of manager stops Kanbann thinking right when the bottlenecks are known and classical thinking starts again.

What really should concern us when striving for agility and lean management, is that there are many hidden misinterpretations or sometimes intentional abuse of Scrum and Kanban principles out there. I will discuss some that I collected within the last years when helping clients towards more agility and lean thinking in upcoming posts.