Why we need multilevel Retrospectives

March 11, 2017

Why Retrospective is the most important tool?

In this post I will not talk about how to do retrospectives. I think there are plenty of articles and books which describe dozens of ways to do team retrospectives.

Where I want to focus, is the reasons about why every software company that tries to be agile must have multilevel retrospectives. Particularly I want to describe that by showing what problems individuals and departments are facing when the company uses the old traditional way of creating software.


I use the multilevel term referring to the hierarchical structure for the majority of the companies.


Retrospectives are the lever to transform a company to be more Agile! That's a fact! The reason is simple. If you don't stop and see what went well and what didn't, you will not have the chance to improve. 


Many people think that retrospectives are only for a development team which uses e.g. the scrum framework. Also they don't realize that a retrospective is a gathering which could be and must be done from every team or department.


Even better if it happens between two "levels". It that case the retrospective should step in and demolish that structure. It sounds scary but if the retrospective is performed with some rules in mind and from a skilled facilitator, everyone will be in the same hierarchical level at the end... called Agile.

If you want to get to the root of problems, you have to use retrospectives. Every company is a living organism. It may be divided in departments and teams, but if they do not cooperate efficiently and effectively,  things will not be good for anyone.


For those who do not know or forgot the Agile principles here is the list:

  • individuals and interactions over processes and tools

  • Working software over comprehensive documentation

  • Customer collaboration over contract negotiation

  • Responding to change over following a plan


All of these need monitoring and improvement. These are achieved when you stop, think, produce insights, identify problems and take actions. These words are the translation of the Retrospective and since all of the Agile principles are written for everyone in the company, it means that everyone should do Retrospectives.


Also, since everybody belongs somewhere in a company and that place has interfaces with other people, departments etc, retrospectives should be used by all the involved parties.


The problem with the "unknown" and the "status quo".

I'm sure many of us have experienced the feeling that we don't know what other departments of the company actually do.


Also I believe many times your task is delayed by some process related with another team or department and you didn't know what to do. Except from sending an email to someone of this department to explain your needs. You may have told that to your manager and you wished he had time to do the middleman.


The approach is different from company to company but most of the times two things are in the air:

  1. We don't know what these guys are doing. Unknown.

  2. Well since everybody is in the same situation with me, then maybe there is no other way to do things. Status quo.



I think this is a big problem I have to say. But first let's try to find what is the most common reason of these two issues. The most obvious reason to me is the hierarchical structure of the company, along with the waterfall project management way of creating software.


Let's face it. When you get a job to a company and you start working, you are given a title, a department, a manager and the tasks you have to do. So immediately you are inside some kind of boundaries.


Maybe someone will introduce you to other people outside your team. Probably to the people that you may have daily or weekly communication. Just enough to do your prescribed job.


The truth is that these people are not the only persons you will need to get the job done with an efficient and productive way. Almost everyone in the company is connected in some way, and the cumulative work of the people defines the outcome to the market.


Hierarchy makes it more difficult to define the proper connection between people. Lets face the fact that, in one way or another,  it's more difficult to talk openly to a person who is one of your "bosses".


So the most likely scenario is that you will continue that way, until you face all kinds of problems. Then you will accept the status quo, or you will move to another company.


Maybe you will start complaining, but most of the times your complaints will not leave the door from your department/team. Of course your manager will hear you in your personal evaluation and then you will feel again the emptiness of your job.


The problem of the "local" solution.

When you face problems or challenges what do you do? Your best chance is that if this involves other people or processes, you talk to the people and maybe you have some progress.


Solutions will be given with one or the other way, but most of the times will be just for you or your team without having a big talk about it. 


Local solutions could be from working all day and night to deliver a project, or for example request from the IT department to give some hardware for setting up an integration testing environment. 


Is the "deliver the project" a local challenge which requires only a "working all day and night" local only solutions?


Well many companies hide under the carpet situations like this, making the developers think that its only their job of succeeding or not with the delivery of the project. This impression exists because people in other departments choose to give as many information as they think a developer should have, and she must not care about other processes in the company.


The same thing happens more or less in all the other departments. They think too much locally like a company inside the company, having internal stakeholders and competition.


There is a big chance in this environment, any "solution provider" makes you feel she is doing you a favor of solving your problem or helping you with your challenge.


Sometimes, this takes the form like a senior with a junior developer relation, in which the senior has an bad attitude of sharing knowledge, or an IT guy which gives you access to a port that you wanted some days now.


Inner-companies appear, personal knowledge-stores hidden or visible, making the job less and less interesting for everyone even for those having this kind of "power".


Use Retrospectives to change.

If you are working in an environment like the one I described earlier, then you should start doing retrospectives in all levels. If the company have not used it in the past at all, then it should start by doing retrospectives per team, department, division etc. 


For sure you will need facilitators who knows how to do retrospectives. This is critical because an un-facilitated retrospective between people who do it for the first time, it could lead to disaster. You don't want retrospectives to be abandoned.


Again for getting value out of retrospectives you will find plenty of books and articles. Personally I suggest Ben Linders and Luis Gonçalves book "Getting Value out of Agile Retrospectives". Find more at http://www.benlinders.com.


Retrospectives in the teams and departments will bring change. Apart from improvements, you will be able to define better which are their needs from other teams and departments. When this happens its time to do multilevel retrospectives.




Gather the teams or departments together and do retrospectives. You don't have to bring all the people of the company in one room. Start by doing closely related departments and then scale depending the actions that have been decided.


Be sure that more and more dependencies will be revealed. Don't be surprised and afraid if some dependencies and actions are pointing directly to the CEO. Many times we have the illusion that the CEO is doing fine and the problems is with the rest of the company.


That's a huge mistake. In order to transform to Agile you have to do it both ways. From bottom up and top to bottom. So the CEO must be aware what Agile means and should be open and more active from what he was in the past.

Please reload

Featured Posts
Please reload

Nikos Raptis -
Agile Coach, Speaker & Developer

I'm a scrum master, speaker and software developer. I love Agile values and principles and...

Contact me

© 2015 Created by Nikos Raptis

  • Google+ - Black Circle
  • Twitter Black Round