Patterns for Living Organisations

My brother-in-law is an architect. Lucky me. Not because he helps us design changes to our house (which he does) but because he owns a great architecture book that has inspired not only architects but also numerous authors: A Pattern Language by Christopher Alexander.

I first heard about it when discussing software design patterns and the famous gang of four book (Gamma, Helm, Johnson, Vlissides: Design Patterns) with colleagues. Then it crossed my path again when reading the most excellent book Fearless Change by Manns and Rising who also mention it as inspiration for the pattern language in their book. I decided to check out Alexander's book but it has unfortunately taken some time again until I finally borrowed it from my brother-in-law.

You see, I have been thinking about patterns lately again because I am often confronted with the whole 'scaling agile' discussion (SAFe or LeSS or purist or ...) It occurred to me that, of course, all approaches are wrong for many situations but all definitely have valuable pieces. And these pieces can be applied in different scenarios, different combinations, different systems, different organisations. And sometimes you do not know which piece works best when and where.

So, are these pieces patterns? I think so. At least some of them qualify. And  I know there are many more not yet put down in words or pictures within frameworks or books or other presentations.

But scaling agile is actually too narrow a focus for me. Of course, we all want to figure out how to build products or run projects with multiple teams, multiple POs and many stakeholders involved. But true scaling of the agile principles means changing other aspects of the organisation beyond the (mostly software) production aspects, like HR, finance and similar services.

Now bear with me as I tell you about a documentary I recently watched called 'Augenhöhe'.

We will come back to patterns soon enough.  Augenhöhe shows six organisations that have somehow created or changed their structures and cultures and behaviours in such a way that the members of the organisation have much autonomy in their decision making, that hierarchies are not in place to assert power or reflect superior knowledge or competence and where it seemed that the employees were engaged in their work and indeed found enjoyment at work. I recommend watching the film here. Currently only in German, though. I believe an English version is coming, or at least English subtitles.

The film is meant to be an inspiration, and I believe it achieves this purpose. It basically shows that there are companies that try (and partially manage) to create living organisations rather than well-oiled machines. What the film does not do is give answers how to achieve this change. I kept on asking myself - what did they do so that they are how they are now. Which - wait for it ---- patterns did they apply? And it became clear to me that I want to find (distill?) these patterns out of the behaviours/methods/ideas of successful organisations and make these patterns accessible to everyone. Maybe this will help create more living organisations such as these.

And this is where the we come full circle - Christopher Alexander and his Pattern Language book will help me to find a blueprint on how to describe patterns. And the patterns in his book (250+ of them) are good examples of what to look for in organisations. Actually, I think some of the architectural patterns may be usable for organisational structures as well!

What needs to be done? Firstly, describe the language (i.e. how are patterns specified). Here I plan to steal and tweak from Alexander and Mann/Rising. Then just start by finding categories for patterns and offer examples for each category. Finally, I hope to get others on board to help me find more and more patterns and find a good place (maybe a Wiki?) to collect them and where everyone can retrieve them to use the appropriate ones in their particular organisational challenge.

Trust me - This is important

I know -  the title of this post sounds a lot like spam mail. But if you are here to read this, it seems you trusted me. And this is what this post is all about - Trust.

2013 was my year of trust. I committed to running my own business as a coach, consultant, trainer, enthusiast for all things agile. And I jumped into this business without extensive analysis and business plans - I decided to trust in myself to pull it off. Luckily, others trusted me - my family for one trusted me that I could earn enough to put food on the table (sometimes I even cooked it), and the customers I found trusted me to help them with their agile efforts. And I worked in some partnerships where I had no doubt it would work out because I trusted the person or organisation to get the job done and treat the partnership fairly.

As a Management 3.0 trainer, I had to think of the four types of trust we teach as part of the team empowerment module:

Image by Jurgen Appelo

1 - I trust my partners to treat me fairly and help get the job at the customer done well
2 - My family trusts me to provide for them and my customers trust me to help them
4 - I trust myself to being good at what I do and to being able to run a business based on that
3 - didn't come up above.  I know in my family everyone trusts each other and I believe this is also true for the partners I worked with.  I am not so sure that was the case with all of my customers, though...




Why am I going on about trust and how it helped me? Because it can help everyone!  Because I think there is not enough of it going around. I have lost count on how often I have encouraged people in organisations to have more trust in each other. Most people interested in increasing agility in their organisation understand  that the old-style management of command and control must be done away with. As a leader, if you trust the people you lead to do what you ask them to do, you will feel less of a need to control them. And if you trust in their competence, you will command them less, because you let them decide more on their own.

If a team you lead trusts you, it will generally mean that they will be less afraid to make their own decisions, to experiment and also to fail, as long as you made it clear that this is acceptable (maybe even desirable - this is still one of the best ways to learn).

How can we learn to trust each other more? This is a question I like to ask participants in my Management 3.0 classes. Check out some of the results:

 


Transparency and Openness are consistently on the list. And I am a firm believer that this is the single biggest contributor to trust. No hidden agenda. No 'For Your Eyes Only' stuff. No selective information distribution. If this is not possible than more often than not it points to a problem in your organization anyway. Yes, there are limits, especially when it goes into the personal area. But I can only emphasize that open communication and transparency are so valuable that it is worthwhile to consider going past your usual comfort limit in what you let others know about you and the business you run or are in charge of. Dare to bare! And if you think some things must stay secret then think about why this is. It just might be that you have to fix something, like unfair salaries.

Another favorite: Practice what you preach, in other words - do what you tell others to do. Don't tell people to trust each other and at the same time implement extra control mechanisms to check on them. If you suggest travel expenses should be lowered make sure that you pick the affordable options rather than the comfortable ones. (Seems obvious, but I have more than once seen the CEO travel first class after having told the organization that 'we all have to save money'. Remember the CEOs of the the major US car manufacturers flying in to the Senate bail out meetings by private jet. Who would trust them?)

Walk the talk means keep your promises, follow through with your announcements. Clearly this increases trust. If I can rely on someone to do what they say I will trust that person more than someone who does not follow through with  their promises. It's worth mentioning that this is true even if the promises/announcements are not along my own wishes and convictions.

And finally there is Lead by example. Some people think this is the same as Practice what you preach but the difference is - there is no sermon. As a leader you will influence people and organizations through your actions. To do this well,you need to trust yourself (see type 4 above), meaning you need to stick to your principles and values and live and act by them. Trusting people in your organisation without a large bag of preconditions attached will foster trustfulness in your organizations culture by all those who experience your trust. And if something goes wrong - don't panic, don't jump to control mechanisms but try to learn (also as an organization) from the failure. And trust that it will work better the next time.

Treat trust as an investment. Not only will you learn from a failed trust experiment which will generally make up for the cost of the failure. By leading with trust you will lay the foundations for a positive, trustful culture which will more than make up for the few instances where the trust is abused and was not justified.  

You may think me naive, but I have lived well on the assumption that most people are honest, fair and capable to do what they set out to do. The world is not full of con-artists and thieves nor is it full of people who do not know how to do their jobs. I'd rather give more trust to people and experience the occasional disappointment than lead a live full of suspicion and doubt about the people in my environment. It makes me happier, and I think it infects my environment with more trust and happiness. Try it! I think it will work for you, too. Trust me on that...

Evolution or Revolution?

It depends - of course. Which is the typical consultant's answer.

First off - I do understand that evolution does not necessarily imply small changes over a long time (though it mostly happens that way).  Species simply die out if they (their genes) do not adapt for better survival chances.  Translated into human society this means that some species (autocratic or oligarchic rulers for example) in some cases simply 'die out' because they did not adapt to society's changing demands (Louis XVI or Muammar Gaddafi are examples).  So, in that sense, revolution is just one way evolution works.

But this is not the point I am trying to make in this post.  I want to look at the different approaches that one can use when trying to make changes in your life or your organization.  Is the big bang better than small steps?  This is really the question I am trying to look at here.

This question has gone around with me for a long time. Politically at first when I was young and full of ideals and read about the French Revolution or Bakunin's biography.  Could the changes achieved by the French Revolution have happened in small steps with the king slowly relinquishing more and more of his powers? 

And once my student days were over and I started working in full-time jobs I realized that this same question crops up almost every time any bigger changes were attempted by myself or anyone else in the organization.

Introducing agile concepts is a case in point. Big Bang changes of the whole organization seem often necessary because everything in the system is connected and you will not be able to change one area without influencing everything else. But mostly this is too much to deal with for the system and the individuals involved.  Resistance to the change will be bigger than for a more evolutionary approach.

The 'evolutionists' love Kanban, because it changes nothing at the start and introduces gradual adaptations primarily in the local system that applies Kanban. Scrum in contrast requires a number of new meetings and roles to be introduced. And even though it is often done by using one or two pilot teams, it often turns out soon enough that the interfaces to non-Scrum teams and middle management are too many and too involved for them to go on without also making changes.


During and immediately following the recent Stoos Connect conference this discussion surfaced again.  Some folks did not like the strong and revolutionary rhetoric that was used in many of the talks.  They felt it was either too much too soon or even alienating to those who may be open to the ideas presented but not fully convinced yet.  Should we strive to abolish management and to increase our numbers so that our Stoosian army gets bigger?  Some non-Stoosians might feel they as managers are being attacked and must defend themselves rather than open-mindedly listen and slowly understand what this is all about.  In the this particular example, I think we have a very frequent pattern, actually:  Talk up a revolution (to make people listen) but implement the change evolutionary.  

Looking at changes in organizations I believe that an evolutionary approach is the preferred way if you do not have at least a substantial amount of management power on your side.  It is very hard to make changes in a big way if the CEO and/or many other managers are not with you. They run the company and they do so on authority of the ownership of that company (sometimes they are the owners themselves).  It just is not a democracy and the employees cannot forcefully take ownership and turn a company into that.  What it means is that you need to convince the powers that be to at least try some of the proposed changes in a protected, local environment and show the effects it has.  If you are right about your ideas, then the positive effects should help convince leadership to adopt them in other places.

Many of you probably know the adoption curve (actually diffusion of information) described by Rogers in the 60s:

This basically describes an evolutionary process where the adoption picks up speed and, after reaching the majority it will hopefully still convince the hesitant ones at the end.

But what if the CEO is the one initiating the change?  Suppose she will announce that the company is now going to be founded on agile principles, development will be done in teams that use Scrum or Kanban and management better start changing their mode of operation from command and control to self-organization with trust in people...  I think the curve will still hold up - maybe somewhat compressed in time due to the big bang start, but I still think that not every person in the organization will adopt to the new way of doing things at the same time.  In the end, you need to be convinced to really adopt to the change, not forced.  And I would hope the CEO who sees the light and wants the changes to happen will also understand that forcing the change is mostly not a good idea.

Which leads me to a final point: evolution to one person might well be revolution to another.  It is a matter of perspective.  How much does the change in question affect you?    How much risk is in it for you?  How quickly do you have to make changes?

Change is very emotional and even though it is helpful to make people understand the need for proposed changes, it is by far not enough to have rational explanations.  How will it make everyone feel?  And how much or how little change can everyone handle?

In other words - it depends!  Revolution or evolution - there is no right or wrong approach.  It must be decided based on the system you are trying to affect, on the people in it, the structure of the system, influences on that system and many more aspects.

Yes, we plan!

One of the tasks typically associated with management is planning. Planning of budgets, planning of resources, of personnel, of projects, roadmaps for products and so on.

However, as some organizations are getting to be more agile, a myth has arisen that 'when you do agile, you do not plan anymore'. This myth is fostered by the antagonists of agile who use it to point out how very unprofessional agile methods are. And then there are those who embrace the myth because then they can skip the tedious planning work.

They are wrong! And certainly the myth is wrong. Agile managers do plan. (And so do others in an agile organization, like POs, for instance).

But there is a difference between conventional and agile planning. To explain, let me back up a little.

What is planning actually? It is the organization of activities to reach a specific goal. It requires to make assumptions about the future and draws up actions for future developments.  In other words, lots of unknowns to take into account:  those unknowns that you are aware of - things that could happen but you do not know if, when and how they will happen (risk management typically tries to address these). For example, when planning a big project you can assume that some project team members will be sick some time, but you do not know who, when and for how long.

But then there are those unknowns that you cannot take into account because you cannot even imagine that those unknown events will occur. We call them the unknown unknowns. In hindsight these events make sense and we often hear: 'I could have known', or 'I should have planned for this' but in reality this was not possible.
A manager might, for example, plan personnel resources for the upcoming year.  The plan will likely become completely irrelevant after the company has surprisingly merged with a competitor.

In traditional scenarios, it is usually considered a major problem when a plan changes.  My observation is that an interesting process occurs: A plan is made by making assumptions about (predicting...) the future and once the plan is in place, it becomes fact, i.e. it is no longer just an assumption that may be wrong or may be affected by unknown events.  Rather, it becomes a known quantity as if it already happened.  Don't we all want to be able to predict the future?  And if we spend so much time analyzing it and writing it down in tools made just for this, then it simply becomes fact, or at least 95% sure.  Any deviation from the plan is a problem and is considered a bad thing or at least a nuisance. 

The big difference when planning with an agile mindset is that agile principles do not take the plan for fact but rather expect that the plan will change due to all the unknowns and that this will happen often and that this is actually a good thing.  Agile frameworks are founded on the principle of continuous change and therefore changing the plan will be part of the day to day process in an agile environment. Actually, it is the planning that is more valuable than the plan:

In preparing for battle, I have always found that plans are useless but planning is indispensable.
Dwight D. Eisenhower

Of course, the consequence of the ever-changing plan is, that you should not spend much time and effort working on it.  It is an illusion that working hard to try to foresee all possible events will yield a stable plan!  Remember the unknown unknowns.  You simply cannot predict the future - unless you are clairvoyant.  Which would make planning easy and require little effort.  I just haven't gotten the hang of  it.

So, please, you managers and planners out there: Make plans, but don't take them too seriously! All your plans will be mostly wrong until you're almost finished with whatever you plan. It is an ongoing learning process, and you will keep on discovering new facets that you did not expect and that will change your plans.  But if you do not plan, because the plan is probably wrong anyway, you will miss out on all the learning that takes place when planning.

Team: Management

In previous posts I have stated that managers must form a management team.  Let me explain today, why and how.

The easy and almost obvious answer to 'why' is that a good team achieves more than the achievement of the sum of its parts.  By that logic, a management team should achieve more than the single managers will achieve, trying to manage their organizations.  I believe this is true!  Why is that, you ask?  Communication is one of the main factors yet again.  Consider some of the tasks of managers: setting goals and constraints for their teams, structuring the organization they are responsible for, budgetary issues.  It is very obvious that close coordination amongst the managers for these issues is not only helpful but mandatory.  All managers will have a common goal for these tasks and should exchange status information as well as actually work together at common approaches.  This, to me, is the basic definition of a team: have a common goal and help each other to reach it.  A management team clearly makes sense. 

In fact, I think a management team is even mandatory if the organization has a matrix structure, i.e. if the various cross-functional teams each have members that report to different managers.  (Actually, I prefer to say: are assigned to different managers.  Reporting is mostly a relic from the command and control management style that shows how little other communication between manager and employee exists and that the manager does not trust his employees.  But this is not the topic of this post).  Teams with multiple managers is not an ideal situation but is still often used and sometimes not avoidable.  In such a case it is crucial that the managers speak with one voice to the teams. Even small differences in describing goals can cause unnecessary confusion and can keep a team from going into one direction.  And the level of delegation used by the managers towards a self-organized team must also be aligned.  If the managers have a different opinion on what a team gets to decide and what is still in the authority of the manager, then the team will never be able to organize their own work.  How could they?  They do not know what they are allowed to decide for themselves.

I truly believe that people are good and honest as default and do not try to abuse a system.  But given the option between two positions presented them, they still will often take the most convenient for them.  So, two managers whose postions are not aligned, will allow a team to go from one to the other, hoping to get a more convenient opinion or decision.  All you parents out there know this: If Mom doesn't let me do something I'll go to Dad, maybe I get lucky there.  Just like parents, managers need to send messages that are at least compatible if they are not the same.

Working as a team is often hard for managers.  One reason is that they sometimes see each other as competition rather than fellow team member.  Instead of helping, the manager will try to look good in comparison to his (her) peers and only follows his personal goals rather than the management team's goals.  Upper management must make sure to not give competing goals to managers.  Actually, I think it is best if the managers have the same goals or even better a common management team goal.

So, how can management achieve the team work that is necessary to speak with one voice to the employees?  Pretty much the same way that we expect all teams to work:

1. The goal must be clear.  Upper management must give the management team a common goal.  Or, alternatively, the management team decides on their own goal. What do we as a management team want to achieve? Delivery of a project / product can be a goal, but growing a team of employees so they can take on different work or increase their quality may even be better goals for management.

2. Hold regular meetings to determine if the goal is still right for the management team and plan how the management team will work to get closer to achieving the goal.

3. Use cadences to be able to track your success in achieving milestones to your goal.  Plan the cadences.

4.Visualize the tasks you as a team plan to do and let the whole organization see the visualization.  Such transparency will increase the trust the employees have in management.

5. Communication is key - meet daily to exchange information and coordinate your communication to the teams/employees.

If you have other methods to work as a management team, tell me - I would love to learn more about it. How do you make sure that management speaks with one voice to the employees?

Finding the Right Team

Who belongs in which team?  What is the best size?  Which roles need to be present in a team? How do we decide which team does what?  These questions (and more) come up again and again when discussing larger agile organizations working on multiple projects or products. And it is one of the manager's key tasks to help grow a structure of teams within an agile organization so that the organization's goals are being met.

Team size has been discussed at length in many books and blogs and I cannot add much insight here.  Remember that the teams must be able to communicate well and therefore the size must not be too large.  Any number with two digits is too large in my opinion.  And to be able to compensate for absences and have sufficient diversity, I believe four is the minimum number.  So there you have my suggested range: four to nine.  In a Scrum context, for example, I really like a scrum team of seven, with one PO, one ScrumMaster and five development team members.  I have seen this work well many times.

But who is on the team?  Conventional wisdom calls for cross- (or multi-) functional teams.  In other words have a bunch of people with diverse specialties on a team.  Depending on the organization and its projects these could be developers with various areas of expertise, QA specialists, documentation experts, UI designers, but even business people such as marketing and sales could make sense if the results to be produced include, for example, sales kits or other business materials.

For the most part, I agree with this conventional wisdom - cross-functional teams offer much greater flexibility and tend to be more efficient.  Why more efficient? As I have pointed out in previous posts, I believe direct communication is key to high productivity.  Efficiency reduces dramatically when communication takes long (not taking the direct route between the parties that need to talk) or even worse if the messages are compromised through too many indirections (I call this the 'Chinese Whispers' syndrome, after the children's game of that name - no offense to Chinese people or language).  So it seems natural to put the people into one team who need to communicate much in order to implement some functionality.  Depending on the functionality that the team typically needs to produce, this probably means that the team needs to have people with skills in various disciplines, in other words: cross-functional.

But what about a skill that is only required occasionally and does not keep a person busy for a complete development iteration?  It seems wasteful to include for example a technical writer in a team that only has a few paragraphs of help text for each implemented functionality.  Ideally a person with writing skills will also be able to code or test or do other relevant tasks to complete the implementation.  Unfortunately, there are very few gifted people that are specialists in many, diverse subjects.

This is why I also find functional teams a useful construct in an agile organization.  For example, a UIX team with experts on user interface design could make sense, or a team of technical writers.

And how do these teams work together with their cross-functional counterparts?

One option is to hire team members out temporarily to cross-functional teams.  This way the specialist will be very involved in the actual implementation and the communication is easy, especially if the hired out person really physically moves to the hiring team for the duration.  On the other hand it might well be very disturbing for the hiring team to incorporate a new and temporary team member, especially if the hiring period is short.

I much prefer the concept of functional teams as service teams.  They offer services to the cross-functional teams that those teams cannot provide themselves.  In this way, the service teams can grow together as a team because they offer the services as a team not a single person.  And they are able to have their own projects within an iteration.  The UIX team could develop general UI components, stylesheets etc.

But such service teams must be able to deliver services on very short notice.  A build and CI team, for example, may have to make branches available quickly due to an emergency patch to be delivered to a customer.  Often the cross-functional development teams notice the need for a UIX service (e.g. some graphical component) only in the middle of a development iteration.  So, the service teams will have to work in a highly event driven way, where the events coming in must be properly prioritized so that the team can focus on the most important services.  Often, a Kanban organization works well for service teams.

I use the term service deliberately.  Service teams must make it their primary goal to serve the organization as quickly and efficiently as possible while maintaining the highest quality.  All too often have we seen service teams deteriorate into isolated groups stymied by complicated service request processes.  The rest of the organization must beg them for help or does not even dare to ask.  Service teams must regard the rest of the organization as their valued customer and continue to ask them: How can we serve you even better.

Are there even more types of teams around?  What about Management?  What kind of a team are they? How do they organize their work?  I have some proposals which I intend to discuss here soon.

Manager in a Networked Organization

In my previous posts I have shown how to describe organization structures in a way different from the typical hierarchical line management top-down tree.  Because communication is at the heart of any organization that wants to be agile, with self-organizing teams and an innovation culture, the communication paths are the primary feature of the organization structure.  Companies become networks of interconnected persons and teams.


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 issue 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.

Communities are Communication Bridges

In my last post I made my case for describing organizations in terms of communication structures.  Persons that are interacting much with each other should be in one cluster within the organization.  Bridges between clusters are needed and are created by communication paths between at least one member of each cluster.  By crossing multiple bridges everyone will be connected to most other people in the organization.

Let’s imagine in the situation above the organization is distributed across different locations and the teams each develop software based on a shared data base but with different purpose.  Due to some performance issues, Team 1 needs to change the DB schema for some of the data.  They communicate this to their PO who in turn lets the PO team know about the need to change the schema.  One of the POs realizes the impact it will probably have on his team and informs them about.  This is the red path in the picture above.

However, such communication paths are not a good idea if they become too long.  Too much noise on the way will distort the message and even if the message arrives intact, it will arrive with a delay.

To remedy this, shortcuts must be introduced to get more direct communication going.

In other words, the teams should talk directly to one another.  But simply drawing such a shortcut in an organizational chart is not going to make the communication happen.  Since the teams in our example have little common ground save for the underlying data base, which has been stable for long, they do not know much about each other.  Team 1 does not know which team will be impacted by their changes.

It is necessary to identify what the content of the communication is that needs to take place in a more direct form.  Does it happen frequently that such messages have to take a long way to reach the proper recipient?  In our example the question would be, how often the organization has data base issues that need to be coordinated across teams.

In many cases the people involved notice the need for more direct communication and self-organize into virtual teams with the same special interest.  In other cases it needs a good leader to identify the missing communication link and help the members of the organization to establish such special interest groups.  The very appropriate nom-du-jour for these groups is communities of practice.  Maybe a community of practice (CoP) for DB administration would be appropriate in the example.  Such a CoP should have a member from each team that uses the data base in question.  They organize themselves, meet on demand or regularly, face-to-face or virtually, set standards pertaining to their topic, make decisions about changes, etc.  They communicate directly and do not have to rely on messaging through other persons, particularly not their line managers...

And yet again - there are no managers in the organizational chart.  Do we need them at all?  If so, where do they fit into the picture?  Watch this space for answers to this and other world shattering questions.

Communication as Structure

Most management experts nowadays agree that the management practice of command & control is not appropriate for organizations were the employees are knowledge workers that need significant cognitive skills and a creative spirit to do their jobs.  I wholeheartedly agree with them.  We know about different styles of management that foster creativity and productive cognitive work.  Unfortunately, this new type of management is not yet very widespread and I believe we need to find out why this is so and what we can do to change it.

Of course, I am not the first one to come to this conclusion.  Check out the Stoos Network for people, blogs and discussions about changing the way of command & control management to an agile leadership.

One of my thoughts on how to start breaking command & control is to start describing organizational structures no longer in hierarchical Org-Charts.  Every organization of more than 10 people feels the need to create an Org-Chart.  And we all know how an Org-Chart usually looks like:

Looking at this picture, it seems inevitable that the CEO will command his managers and they will do the same to the people in their organizational branch.  That's what the boss does, right?  And that what the lines from top to bottom imply, right? We even call the upper level nodes line managers.

I am not sure if we can abandon this idea completely, as one of the top management thinkers of our time, Peter Drucker, might imply when he says "The modern organization cannot be an organization of 'boss' and 'subordinate', it must be organized as a team of 'associates'."  But I sure am convinced that the hierarchical boss - subordinate structure is not the best way to describe how an organization should be structured!

So what is a better way, then?  Communication methinks.  Knowledge workers must be able to easily communicate with each other to exchange ideas and experiences and knowledge and information and emotions and and and...  So, when an organization or a system of individuals needs structure, it will hopefully align along communication channels so that the individuals that are in need of close and frequent communication will join together in an organizational unit.

Note that I have intentionally not spoken about creating an organizational structure, because I think ideally the structure will develop or grow with much self-organization involved.  The agile leader helps an organization to grow the required structure to enable the best possible communication.  See also Management 3.0 (the book and / or the course) to learn how to grow structure.  In many cases the structural growth will be a mixture of design and evolution.  Which sounds a bit like an entirely different discussion about what to teach in biology class in some states in the US…  I have a very clear opinion on this as well, but I will save it for another blog at another time.

In the end, you will need to visualize the organization’s structure, whether it grew or was intentionally created by someone.  Put the people that (need to) communicate intensively into a cluster:

 

Such a cluster is often called a team.  There is, however, more to a team than close communication.  So be careful to make sure that your clusters also have a common goal and the willingness to help each other to reach that goal if you want them to be a team.

The lines between the people are communication paths.  I suggest to leave them out of the picture and to imply that all members of a cluster will have sufficient paths to most of the other members so that information can flow easily between all members.  The picture will be a lot easier on the eyes.

Examples of such clusters in software development organizations are teams of developers or a scrum team (developers with scrum master and product owner) but also a team of product owners that work on a joint product backlog.  So, no matter if the members of such a cluster have the same line manager or not, do put them into the same cluster in your organizational picture.

If one member of a cluster has a communication path to a member of another cluster then they are linked by a bridge.  Bridges are particularly important when they connect distant clusters, making them near.

A sample subset of a development organization could then look like this:

These teams look like they can self-organize and are allowed to do so.  No manager to be seen (yet).

Of course, this is a first example.  We need to make it possible for the teams to also have bridges to one-another so that communication is not moving through the Product Owners.  And what about the managers?  I believe they are still needed.  So where are they in such a picture?

The answers to these questions need more space and time than this blog post allows.  You’ll just have to wait for the next installment.

Agile and Organizational Structures

Putting up a Kanban board or holding daily scrum meetings does not make an agile organization. Neither does the adherence to all the Scrum or Kanban - or whatever else - rules. You may even succeed in becoming really agile on a micro basis in your organization: The teams get a beautifully groomed backlog from their Product Owner, they deliver software at the end of each iteration and they inspect and adapt to get better in their own processes. And, I am sure, it already helps a lot with their productivity and motivation.

But then comes along the boss. And it is usually not a pointy-haired one that we all laugh about from a well-known comic strip. He (or she) has been the best developer in the organization and was outspoken for a long time, so he naturally got the promotion when the company grew and felt the need to introduce a new management layer of team leaders.

Now he has the responsibility for what the team delivers, and, of course, he knows best what to deliver and how to do it. So, he will let the team be agile but when he realizes they are not using the framework of his choice he must intervene! Let's create a task force to investigate what frameworks to use with a decision due at the end of the sprint. And he will be part of the task force. Guess what the outcome will be? And one of the committed stories of the sprint didn't get done again!

You get the picture... No, I do not mean to say that all management is evil. Certainly mostly they have the best intentions. But all too often managers cannot rid themselves off the good old "manager knows best - manager must make decisions" logic. And the higher up the manager, the better he knows.

I am convinced, that we need managers around. Leadership is necessary. But we need to curb the inflation of managers in organizations. The natural career path is still to become a manager at some point. But does the organization really need yet another manager?

And then there is the hierarchy in an organization where we all automatically think - the higher, the better, the smarter, the more money...

I believe herein lies a big problem for most organizations when they try to become agile. A hierarchical organization implies a command structure top-to-bottom that makes empowered and self-organized teams or departments so much more difficult to implement. So I propose to look at organizations in a different way.

In the following weeks I will put my thoughts on this into a small series of blog posts I will call Blueprints for Agile Organizations. I will examine the necessary minimal structures for organizations of different sizes and I will look into ways on how to describe the structures other than in hierarchical organization charts. I consider this one of many important steps to get away from command & control management to true agile leadership. Also, I want to investigate how such structures can organically grow and shrink over the lifetime of a company. I do not have the answer to all this but I have some ideas and this blog will hopefully help me to put some more structure into the ideas and get feedback for them.