As a matter of fact, even dissenting Managers that have been infested by the agile methods, Managers that reject traditional thought patterns as they notice that these have led us towards a dead end, wonder how it can be possible that a Team’s wish for more autonomy and self-determination will help in getting more out of the Team?! But let‘s be honest: This is the crucial point! It is what the management framework Scrum is all about!

Is it okay to be discontented?

Managers and, by now, also ScrumMasters are dissatisfied with the performance of their Teams. But are they even allowed to feel that way? If you believe in the agile ideology, which is vehemently defended by several Agilists, then demands and expectations of the Team are wrong. The belief is that the Team should decide for itself in what way it wishes to work and how much it wants to deliver. The Manager simply has to live with the results. My reason behind using the word “ideology“ is the fact that it works well with the elements of ‘good‘ and ‘bad‘. The ideologically-charged agile discussion on “bad“ traditional management and “good“ new agile ways leads us towards thinking in categories. I believe that to be absolutely pointless in this respect. No higher moral authority exists which could decide whether the one or the other is actually “better“.However, it is important to say that my rejection of moral reasoning certainly does not stem from arbitrariness – instead, I strongly believe that it matters whether you work in an agile or a traditional way. It is reasonable to say that agile methods and agile thinking are more effective than traditional schools of thought, such as classical project management or hierarchical organizational forms, since they deliver better, empirically-traceable results. The Standish Group’s 2011 report has made this very clear.

The answer to the initial question is yes. As a Manager, I am certainly allowed to be discontented with the performance of my Team. I am just as much allowed to have my own opinion as the Team is allowed to. We all know the highest principle of the Retrospective: that everyone has tried to give his best at all times. This maxim, of course, also applies to the management and the Manager’s personal thoughts. He can‘t help but have them. “It‘s not your fault“, says the psychologist Sean Maguire to Will Hunting in the movie ‘Good Will Hunting’. Here, Sean shows Will that he is simply a product of his own upbringing and environment. While he cannot exactly be held responsible for what he has done in the past, it is certainly his responsibility to learn from his experiences. However, it does not result in him being morally good or evil. Similarly, the Manager is neither to blame nor is he ‘evil’ if he tries to communicate performance expectations to the Team. These expectations are just as important and okay as the statement of the Team that it can only deliver what it delivers. Is it possible to justify this statement? Up until now, I have had difficulty in doing so. As a philosopher and sociologist influenced by natural sciences, I have always understood Norman Kerth‘s Prime Directive as completely logical. However, up until now, I have never gone through the trouble of actually substantiating it.

Beyond good or evil

The philosopher and journalist Michael Schmidt-Salomon closes the gap for me in his book Beyond Good or Evil – Why We are Better Humans Without Morals (original title: “Jenseits von Gut und Böse - Warum wir ohne Moral die besseren Menschen sind”). In a logical-empirical and grounded way, he makes it clear that humans cannot be morally guilty. This does not mean that we have to tolerate or endorse the actions (of criminals). However, according to Schmidt-Salomon, we have to accept that even the worst criminals in history were not guilty, as the validity of the laws of nature proposes that they had simply not been able to act differently than they had in fact acted. How does he come up with this proposition? In the previous 199 pages of this recommendable book, he contradicts two premises that many people take as a given, although they are simply wrong (as they are empirically and logically unsustainable) by saying:

1. Freedom of Will is an illusion. It is simply impossible that – under exactly the same conditions – someone could have decided differently.The Principle of Alternate Possibilities has to be dismissed.
2. ‘Good‘ and ‘evil‘ are moral fictions that have no equivalent in reality.

This leads us directly to the Prime Directive of the Retrospective. The dismissal of the two central premises of the Fall of Man syndrome has made its practical consequence obsolete too: the principle of moral guilt and atonement. It makes no sense to hold a person morally responsible for his decisions, when the person’s disposition and past experiences had led him to only being able to choose one thing in a situation. Exactly this had to be proven. Norman Kerth‘s Prime Directive states that

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” Norman Kerth

This way, Kerth does not create the wrong frame of arbitrariness or of “fatalism”, as Michael Schmidt-Salomon calls it. This, however, is difficult to argue against persons who do not see the clear difference between morally wrong and ethically wrong. All of the Team’s actions are neither morally good nor bad, nor are they correct or wrong. Every Team member had only been “able to do” exactly what he had in fact “done”. In hindsight, one can and should judge whether different actions could have been more quantifiably useful in the sense of effective for the reaching of a goal. Only then is it possible to regret one‘s failure and improve the next time around – without having to feel guilty.

Forgive yourself

This realization helps in strengthening one‘s courage for freedom and courage for freedom of action. The author emphasizes that if the results of the logical-empirical research are taken seriously and we rid ourselves of the Principle of Freedom of Will, it could lead us to the strengthening of our courage for freedom. Knowing that the Principle of Alternate Possibilities is a deception reduces the fear of failure and with that the psychological pressure, which many try to escape. Those who know that they were only able to act in the way that they had acted will still regret past mistakes, but will probably work on reacting differently from now on. They will not start with self-accusations, as it is pointless to blame oneself for something that had to happen in exactly the way it happened. This leads to a more relaxed approach towards oneself: if you forgive yourself, you will find it easier to forgive others, thereby creating a more relaxed relation towards your fellow human beings.

There it is – this recognition that I was only able to act in the way that I had done. It means that today I can correct my actions due to knowing what I did “wrong“ yesterday and try something different instead, something more promising. This again leads us to the credo of acting, which inspires my Team in their daily work: “Doing as a Way of Thinking!”

This approach is based on the awareness that one naturally takes on an objective responsibility for one‘s deeds. Schmidt-Salomon clarifies this in the way that there is an important differentiation between feelings of guilt and feelings of remorse. Both emotions stem from the same root. We feel guilt or remorse when realizing that we have acted wrongly and caused some kind of damage. The difference between these two emotional reactions is that in the case of guilt, we judge ourselves to be morally bad people because of the mistake that we have made. In the case of remorse, we regret our mistake and search for ways to correct, compensate or avoid the mistake in future, but we relinquish the moral condemnation of ourselves. This might sound philosophical as well as smug, but it makes one thing absolutely clear: that the participants, ScrumMaster and Team members mix up exactly those two emotions during the Retrospective.

A Retrospective is never about guilt …

…  but all too often, emotions are released that are not properly directed by the ScrumMaster, as he often lacks the right training. I am not criticizing. I know that it is truly difficult. Often, even experienced therapists fail in exactly this point when dealing with groups. It doesn’t always work that the person affected or the group judges itself only in an amoral way, thereby remaining capable to work. However, if the Team does manage not to morally judge itself (which is actually what the 6 Step Heartbeat Retrospective had been trimmed for, which I had invented 6 years ago and only realised a second ago), then something fascinating happens according to Schmidt-Salomon: While feelings of guilt can torture, paralyze or use up our entire energy, feelings of remorse make us active. Feelings of remorse do not affect our self-esteem.

Here it is: Checklist_ScrumMaster_2012_EN.

Please let me know whether it has helped you and/or you have found something else that needs adding?!

Related posts:

1. Certified Product Owner – How to ESTIMATE Business Value – Relative Weight
2. Does Cloud Computing Threaten Jobs?
3. Scrum Tools | Corkboards and Pen

Over the past weeks, we have thought a lot about Don Reinertsen‘s ideas on Second Generation Lean Product Development. His input lays the foundation for understanding methods like KANBAN, which was created by David Anderson and is currently being sold as the counterpart to Scrum. Having dealt with the ideas of Don Reinertsen intensely and having visited Anderson‘s seminar last year, it has become increasingly less clear to me why people believe that Scrum and KANBAN are entirely different. Alright, so these two may have different best-practices, but by the time that cadences are introduced in KANBAN Teams or a second row is entered on a Scrumboard to separate two projects from each other (swim lanes), the differences quickly subside.

So why are there still differences and why is there such a heated debate going on about whether Scrum is “revolutionary“ or KANBAN “evolutionary“ (David Anderson)? And why is it that in the beginning, I myself had felt heavily disappointed by KANBAN? I had not been able to see anything new in KANBAN aside from the idea of better metrics and the possibility of now being able to explain why Scrum actually works. Contrarily, I was able to see the disadvantage of KANBAN in inhibiting the agility of a Team by allowing it to include waterfall methods.

Two sides of the U

Finally, our Team member Sven Winkler – co-organiser of the Agile User Group Nürnberg (Agile Monday) – came up with the solution: Having learned of Theory U, one of the focal points of our ScrumMaster Pro Training, he came up with the concept that KANBAN positions itself on the left hand side, while Scrum sits on the right of the U. Eureka!

Of course! The power of KANBAN lies in pointing out the work and its bottle necks. Without having the problems lined up in front of one‘s eyes, one is not likely to change anything. KANBAN starts off by recording the current processes, depicting the value chain and pointing out bottle necks. This may create awareness about their ratio, yet no change is actually asked of the Team. Only when the Team itself realises that some step of the process is not working anymore, will it act. A “Work in Progress“ limit will then be introduced, followed by cadences and finished off with Retrospectives.

On the other hand lies the right side of the U, incorporating the solution, the synthesis and the epiphany. Scrum works by knowing which process (that is to say the Deming Cycle) will lead to continuous improvement and by making it clear from the very beginning that certain responsibilities must be fulfilled. Based on a scientifically evaluated, case study-proven image from the 1980s, this method has established itself by knowing exactly how product management should really work and what it takes for Teams to become truly successful. Scrum takes advantage of certain aspects that would become just as clear if KANBAN were applied over a long enough period of time. In his seminar, Don Reinertsen actually mentioned that Scrum is nothing else but Second Generation Lean Product Development.

In a way, Scrum already presents the solution:
Focus on the Team, transparency, best practices i.e. the Taskboard, cadences, regular meetings and deliveries, work in progress limits on the fly = WIP/ per Sprint = commitment and the Backlog.

Ergo, the idea of thinking in deliveries and not in Tasks.

Scrum leads to resistance

However, all of the above lies on the solutions side and not – like KANBAN – on the analysis side. If you take the SCARF model of David Rock (Your Brain at Work), you will immediately notice why Scrum often leads to resistance from Teams and Managers, whereas KANBAN is more easily integrated and adapted:

• Scrum evangelists approach Teams with the words, “You have to work differently“. This leads to resistance, as it reduces the status of the Team.
• Scrum evangelists often say, “You are the Team! Find out for yourselves how you would like to work“. This leads to instability and insecurity within the Team. KANBAN says, “For now, don‘t change anything. We appreciate what you have done so far. Hence, find out for yourself what you want to change.” By acting in that way, they respect the Principle of Autonomy more than the Scrum evangelists, since the Team eventually still decides by itself what it wants to do.
• David Rock further states that a bond between humans is important. Scrum pushes people into a “we are different and you have to change“ corner. This is not exactly how bonding works. KANBAN, however, does exactly the opposite by saying, “We are like you. We‘re just asking what kind of process you follow.“ (In German organisational development, this is called “Turn the affected into participants“).
• Last but not least: Scrum evangelists infringe on the topic of fairness. They highlight that the work processes – which had been adhered to until then – are far from perfect and that i.e. the Managers are to be blamed. Humans don‘t exactly like being shown in a negative light. In this respect, KANBAN again choses a softer approach due to being situated on the left side of the U-curve. KANBAN starts off by raising awareness and by using the explicit sentence of “The affected always know best how to work“ – hence, KANBAN ensures the statement of: You guys are okay!

Especially for the middle management – the usual source of resistance towards change – KANBAN, at first, seems to be the less dangerous option. Many consultants utilise this idea and make Scrum‘s reputation of changing things to their selling point – by positioning themselves against Scrum instead of against the waterfall. Instead of wanting to change traditional management, they want to be agile without Scrum. These consultants apply a very clever rhetorical option for persuasion by simply laying out a nightmare scenario with Scrum: “Scrum changes things, however, it is not yet clear what will happen to you as Manager. Scrum first changes the roles, so it is important for management to just go along with it“. [1]

Now, some of you might say (my wife had immediately intervened upon reading the last lines), “He is writing against Scrum – he is writing against his own business“! Well, at first glance, that is true. At least my readers now know how to effectively pitch KANBAN against Scrum. However, there is one thing that I have to get off my chest: Scrum is on the right side of the U. Scrum is the aspired mindset: It already includes Jurgen Appelo‘s Management 3.0 or Gary Hamel‘s Management 2.0 [https://www.phoenix.edu/lectures/gary-hamel/management-2.html]. Scrum has taken up IDEO‘s ideas on product development. Today, we are talking of the Discovery Phase – which is indeed happening in a fundamentally different way than the Zero Sprint that some had demanded. This phase is necessary, as we have come to understand that more than one Backlog is needed. Scrum has unveiled the fact that many companies still have fundamental knowledge deficits. This includes the developers that lack agile development practices, the product managers who are nothing but requirement managers, and the management that can‘t cope with creating an environment that fosters Team development. Together with the new development methods, Scrum has shown us the future, the vision.

The way that Don Reinertsen presents the Second Generation Lean Product Development in his book as well as his training, it seems like it is not yet incorporated in KANBAN. He talks of including ideas from the German warfare in the management of product development (mission-type tactics and manoeuvre warfare), while adding ideas from the US Marine Doctrine, such as “less detailed planning, little status reporting, reaction to battle, decentralised control“ etc. This way, he creates a model of the agile organisation, which we are already familiar with thanks to Peter Drucker and Tom Petersen – and which is today represented by Gary Hamel. It fascinates me to see that, again, war is the origin of all things: Scrum was invented by US military alumni and Second Generation Lean Product Development by a former marine officer. Could it be that ideas,which stem from situations where speed is important to gain new territory, might be the answer to the development of new markets and products? It has always been about the NEW NEW PRODUCT DEVELOPMENT GAME. How about we finally create companies together, in which humans can develop themselves in an optimal way.

[1] By the way, it‘s not like I just come up with these kinds of arguments. At the OOP 2011, a consultant approached me with exactly this chain of arguments as his sales pitch. Back then, it had truly shocked me. I had always thought that we – the Agile Community – wanted to “fight“ the waterfall, the management of the 19th century, together. The idea of trying to make a method look bad in order to sell one‘s own method – even though it has proven to desire the best for everyone – was simply alien to me. Of course, I had written against KANBAN, but only because we were already a lot further with Scrum than KANBAN. To me, KANBAN was and is a step backwards.

Related posts:

1. Certified Product Owner – How to ESTIMATE Business Value – Relative Weight
2. Does Cloud Computing Threaten Jobs?
3. Scrum Tools | Corkboards and Pen

Particularly when ScrumMasters have been operating in one company over a long period of time, they turn blind to organisational deficiencies. Of course, a good ScrumMaster would have already taken initiative and found someone that can give him regular feedback. However, it is not always that easy. For this reason, I would like to present you with the ScrumMasters‘ Checklist – it allows you to self-evaluate your own work and improve in the necessary areas. Of course, you can also use this Checklist as the basis for your coaching.

The Checklist for ScrumMaster 2012 can be found here.

Please let me know whether it has helped you and/or you have found something else that needs adding?!

Related posts:

1. Certified Product Owner – How to ESTIMATE Business Value – Relative Weight
2. Does Cloud Computing Threaten Jobs?
3. Scrum Tools | Corkboards and Pen

So far, we know that we can do Scrum with paper and we can do Scrum with software – where software means dedicated software, that is written for Scrum. Often overseen, most of the companies have already a tool that is usable to support Scrum: Microsoft Excel (or OpenOffice Calc if you prefer OpenSource or Apple’s Numbers, if you work on a Mac). When using such a spreadsheet tool to create a Scrum tool in a spreadsheet, you should be aware of some aspects, which I will discuss one by one in the following sections.

For Starters

When facing the introduction of Scrum, everything can be done by using paper, but especially the Product Owner needs a tool to create, update and prioritize his user stories electronically, otherwise he will find his desk covered in piles of sheets that were updated at different areas – in short, it will result in chaos. Therefore, the product owner needs a Scrum tool. Excel & Co is perfect for entering our Scrum world, as it is mostly already installed on every company’s computer – thus extra costs can be avoided. Therefore, it perfectly fits for exploring the idea of the product backlog (eventually, a dedicated Scrum tool might be favored, see the last section).

Customization

Another strong point of using Excel & Co next to a dedicated Scrum tool is that it is 100% customizable – in fact, every Product Owner will start from scratch by looking on a plain spreadsheet, that literally cries for data. Step by step, the Product Owner is able to create the rows and columns he needs for his very own Product Backlog. However, some functionality within Excel is quite tricky, especially when it comes to creating the Burn Down Chart. Excel offers lots and lots of different types of diagrams, but the one that matches to a Burn Down Chart is not available (a line diagram comes quite close, but the lines that visualize the burned story points are not completely vertical). To support Product Owners, I have created a very simple Product Backlog template, which helps to calculate the amount of story points per sprint and which offers a suitable Burn Down Chart:

• Product Backlog Template (prior to Excel 2003)
• Product Backlog Template (Excel 2007 and newer)

This template should not be treated as full-featured Scrum tool, it serves merely the purpose of a framework, that can be used by Product Owners to create their very own adaption of a Product Backlog.

Flexibility

Not everything is perfect in Excel. For starters it might be a good tool, but most Product Owners will likely stumble across the limited flexibility of Excel-based Product Backlogs. Take the very common example of shifting more important stories – in Excel one has to cut the row with the corresponding story and copy it to a unused row, only to cut the other row and copy it on the spot of the first row. After that, the backup row can be copied to the spot of the second row. You get the point, that’s not very flexible, in fact JIRA  & Co do a much better job.  And there are countless examples like the one above.

Wrap Up

Spreadsheet programs like Excel are good to start messing around with Scrum: most of the company’s computers come with Excel installed per default, and it’s grade of customization is amazing – still, the flexibility is rather low. But that’s how it works: every tool has its advantages and disadvantages.

Related posts:

1. Certified Product Owner – How to ESTIMATE Business Value – Relative Weight
2. Does Cloud Computing Threaten Jobs?
3. Scrum Tools | Corkboards and Pen

Now how do I get from the optimal heart beat to working in Scrum Teams?

Related posts:

1. Certified Product Owner – How to ESTIMATE Business Value – Relative Weight
2. Does Cloud Computing Threaten Jobs?
3. Scrum Tools | Corkboards and Pen

Go ahead and ask a manager whether s/he would be willing to accept the fact that his/her Team is only loaded up to 80 percent. What do you guess the answer will sound like? “Absolutely no way! Everyone‘s capacity should be stretched to the maximum and used in the best possible way.“

Tom DeMarco wrote an entire book in order to show how this idea is wrong. In Slack, he notes the fact that it is vital to allow a bit of leeway in order not to entirely stretch a person‘s capacity. He is right. Even from the point of view of production – as can be seen in the graph. Up to a capacity utilisation of 80 percent, the average number of activities that have to wait is under 5 activities. At a capacity utilisation of over 90 percent, this number of activities in line rises dramatically. At a capacity utilisation of almost 100 percent, the number of things in the queue becomes gigantic.

If a Team reaches a capacity utilisation of more than 80 percent, this will lead to a long list of Tasks that require working off. However, long lists of Tasks create an even longer time for them to get delivered. They increase the risk of working on something that has turned obsolete in the meantime. They create more pressure for change, more overhead, lower quality and little motivation. We all know this feeling: If you have a long list of things that need working off, you sometimes can‘t even be bothered to really start on it.

So how about we stop expecting people‘s workload to always be completely maxed out. It is simply unproductive and makes no sense. A reduction would lead to increased efficiency. Strange, but true.

Your next chance to experience Don Reinertsen live:

Second Generation Lean Product Development

Applying the Principles of Flow
on 10 and 11 September 2012 in Munich

Related posts:

1. Certified Product Owner – How to ESTIMATE Business Value – Relative Weight
2. Does Cloud Computing Threaten Jobs?
3. Scrum Tools | Corkboards and Pen

What is legitimation?

Thus there is good reason to ask about the meaning of legitimation in the role and function of ScrumMaster (PO Team leader, Project leader). Legitimation is an important formal element of leadership, whether disciplinary or lateral.

Legitimation (from Lat.: lex, legis = “law”, “justification”) in its present sense means empowerment, verification. Legitimation is the justification of existent structures and rules, and thus a relevant element in being authorized to take action for executives and functional power. Legitimation in this context supports Standing, conviction and the management´s power to influence. It is important to note here that legitimation should be regarded three-dimensionally:

• Legitimation through the system from above
• Team legitimation from below
• Self legitimation from “within”

System legitimation means that those responsible in the company allocate a clearly defined and formally agreed upon role profile to the person in this role. Responsibilites and competencies have to be determined, considering and making clear all possible consequences when
put into practice. If for example the ScrumMaster is allowed to communicate with the management on an equal footing, if he may give impetus in the area of personnel development, then he may or will even have to escalate when conflicts arise. The important thing is that commitment to the legitimation be clearly and explicitly communicated from above to the teams and also to interfaces in the system.

Team legitimation is earned by the person in this role through communication with the team and building confidence with them during intensive contact. This takes place indirectly through appropriate behavior in the role of leadership, and expresses itself in the acceptance of superiority by all team members, and in their specific contribution towards self organization. Team legitimation can also be specifically addressed and actively pursued, for example by clarifying expectations and demarcating competencies.

Self legitimation is the inner authority to take on a special role in the team´s self organization and working process. This means being convinced that one´s own role is useful and valuable for the whole, and confidently displaying this. Self legitimation means appreciating one´s own skills in order to practice them confidently, without arrogance, even if one can maybe still improve and learn more. Ideally this means appreciating one´s role. Only those who enjoy leading, lead well.

Particularly a ScrumMaster, not yet being a consolidated or standardized role model in the company, should ensure that he or she is sufficiently, even three-fold, legitimated, in order to play his or her key role well and efficiently. This does not always happen automatically, and is not guaranteed by a certificate, but it takes courage, effort and tenacity to get there.

Related posts:

1. Certified Product Owner – How to ESTIMATE Business Value – Relative Weight
2. Does Cloud Computing Threaten Jobs?
3. Scrum Tools | Corkboards and Pen

-  Once upon a time it was lineal-causal

People, who take on the role of reponsibility of ScrumMaster are not less concerned of being different or of becoming different, but just the opposite. A ScrumMaster must on the contary in his interactions  be a guiding helper on a team without being authoritarian. This means the ScrumMaster’s authority is limited to only control of the process. Unlike a project manager he can not take the position ” You have to do this, because I say so.” In order to help the team use Scrum or to remove problems of any type, the ScrumMaster needs a tool to help him overcome this (apparent) deficit of not having this authority. In addition he must give up or forget his usual manners of negotiating. We are used to linear-causal thinking. B results from A and it is A’s fault that B was created. Linear-causal thinking is always based on the past and is oriented toward causes. That means there are concrete causes for certain effects and clearly verifiable people, who are held responsible for specific results. As verifiable as a result may be, this is also an attempt to simplify the complexity of a situation and to completely ignore other reciprocal influences.

Good ScrumMasters never search for causes or guilty persons, but instead analyze which “patterns of communication, relationships or  actions in conjunction with other patterns led to these results.” (Radatz, 2000, p.67) i.e. they think systemically. Systemic thinking means thinking of consequences and as a result that no one is ever the only guilty one responsible for the creation of a specific situation, when others are/were also involved in a matter in some form or other. As a result it is totally insignificant, who caused something. A systemically thinking ScrumMaster doesn’t look back (at the problems), but instead looks ahead to the future (looking for solutions and goals).

"Problem talking creates problems. Solution talking creates solutions." Steve de Shazer

De Shazer would like to be understood above all, as the solution (the goal) never has anything to do with the problem. If you want to help a person to really solve a problem, then you need to know it does not help to discuss the problem and the causes endlessly.
Note: The problem has nothing to do with the solution.

Why why helps no one

Naturally systemic thinking does not exclude active confrontation with the past, but not in order to analyze the determination of cause or of unsuccesful action patterns. Instead of considering the past in a  statical- analytical manner, the goal is to ask about future aspects, behavioral issues and goal oriented aspects in order to develop well-thought out solutions.

If you want to to try out systemic questioning, then start with two things:

• Try, asking more open questions. Closed questions are decision-making questions, i.e. the person being asked can only answer yes or no. Naturally these type of questions must also be asked and are important. But if you want to promote communication, then closed questions do not ‘challenge’ the person being questioned. Closed questions are called closed, because they close communication.

•  Replace questions that start with question words like “Why, how, wherefore” with other question words.

You are certainly asking: Why?

If you want to find out the reasons for something, then it helps little to ask why. People usually answer a why question with pre-conceived answers. And these hardly promote understanding of the situation. Who, what, why questions usually are connected with negative consequences and makes the defendant look more and more guilty, pulling him down to the problem.

How do you question, if you you do not want to ask why? You will be inspired if you read the story from the wizard’s workshop about ‘sensitive question marks’. Try it. And when do you notice that you have asked a good question? The longer the person asked needs to answer a question the more serious the question was.

One thing is definite: Whoever asks the right questions, does not have to give answers, because in many situations the questions are answered on their own, as the effect of a question is to give order to your own thoughts to help you structure and to look at things from another view point i.e. to get to the bottom of a matter.

Literature:

Sonja Radatz (2000). Beratung ohne Ratschlag. Systemisches Coaching für Führungskräfte und BeraterInnen. VSM. (Advice without assessing. Systemic Coaching for managers and Consultants)

Alexa Mohl. Metaphern-Lernbuch: Geschichten und Anleitungen aus der Zauberwerkstatt. (Metaphors-study guide: Tales and Instructions form the Wizard’s Workshop) www.junfermann.de

Steve de Shazer (2010). Worte waren ursprünglich Zauber. Von der Problem zur Lösungssprache. (Words were originally magic: From the Problem to the Solution) Carl-Aue

Related posts:

1. Certified Product Owner – How to ESTIMATE Business Value – Relative Weight
2. Does Cloud Computing Threaten Jobs?
3. Scrum Tools | Corkboards and Pen

So far I had left out the manager in these networked org charts. Why, you may ask? Well, because it is not easy to place him or her in a structure without reverting back to reporting lines. But they should not be important and should rarely come into use. The line in line manager is the least of a managers tasks.

What does the line represent in a typical org chart? The person on the top end of the line has command power over the person on the bottom and reporting has to come back up the line. In other words: command and control. But in an agile organization, we want the manager to focus on very different things:

• Enable the teams to self-organize and self-direct as much as possible
• Make sure the teams and their members jell and are competent in what they do
• Give clear goals and guidelines to the teams
• Help employees and teams to find the best structure for communication with each other
• Make sure no organizational obstacles are in the teams’ way
• Encourage and facilitate continuous improvement of people, teams, processes and whatever else impacts the work of each employee

And, yes, some form of control / reporting will be there as well – however, primarily to measure how good the manager himself is doing with the bullet points above.

So I think we need to eliminate the reporting line entirely from the org chart. Here is an example of how it could look like:

Of course, management will have communication paths to their assigned employees. Just like for the communities of practice, this communication is color-coded rather than represented by lines. This makes the chart much easier to read.

It is imperative that the managers form a cluster (the management team) themselves. In the example above we have teams that are formed of people with different managers. This should not be an issue if the management team works together with a common goal so that all teams will get an agreed goal from the entire management team. Remember that setting goals is one of the important tasks for managers in an agile organization.

There are many issues that are still open and to be discussed. What about bigger organizations with more managers and more management levels? What about service teams that help the others but do not actually produce the product?  What about distributed organizations or even distributed teams? I will try to tackle these questions in my next posts, although I do not promise that perfect solutions will be forthcoming. And you can help me by commenting on my ideas.

Christof Braun, Trainer Management 3.0 & Management Consultant

Related posts:

1. Certified Product Owner – How to ESTIMATE Business Value – Relative Weight
2. Does Cloud Computing Threaten Jobs?
3. Scrum Tools | Corkboards and Pen