Even though agile is now mainstream, companies still struggle to change at the organisational level. The existing agile frameworks and those used for scaling them haven’t been useful in a company-wide adoption. At this moment, there is a strong focus on soft- and language- skills to help managers in becoming leaders. Yet, this is not enough.
Agile is implemented agile and although all frameworks promote and encourage healthier and more productive relationships, they do not rely on individuals for that. The focus is more on the system and the way of working. To say it differently: we need to improve the system for teams and individuals to thrive, instead of expecting them to change, to fix the culture.
Let’s look at some elements from a systemic point of view that are essential to create the right conditions.
Why the existing frameworks are not enough!
The existing agile frameworks could be grouped into two categories:
Specific ones
These approaches aim to solve one specific aspect, despite the fact that they are generic enough to be applied to multiple industries and business areas. Scrum is a way of building solutions. Kanban is more appropriate for continuous work (e.g., help desk or support team). Design Thinking is great to ideate new solutions (that we can later build using Scrum). OKRs allow us to align multiple teams. DevOps promotes cross-team collaboration and automation. Etc. All these approaches are based on the same principles, so they are compatible.
But none of them solves all the problems, like how the teams are built, budget assigned, etc. And each of them seems to ignore the rest, leaving the usage and integration up to each organization.
Scaling frameworks
Here again, we find two types. On one side, those that focus only on Scrum (LeSS, Scrum@Scale, Nexus, etc.) so they help in the usage of Scrum with many teams, but still focus on the same point: building a solution. The other group of scaling frameworks tends to be unidirectional, top-down, and it can be sometimes controversial how agile they really are. “Fragile” is the term used to express a traditional organization that without changing anything, has some agile teams trying to work in a different way, resulting in many friction points.
SAFe is the other common alternative, but it introduces many roles and artifacts, resulting in a major focus on processes rather than empowering teams to have an impact. It tends to homogenize aspects (like the duration of the sprints, or quarterly planning) and this conflicts with how risk is managed in agile. Also, regarding risk management, SAFe promotes “ignoring sunk costs” but agile considers them waste and as such, they should be eliminated. If we release incrementally, sunk costs tend to be reduced and eventually disappear.
The problem with soft skills
Soft skills are great and make a lot of sense. Depending on the culture, some of them can be seen just as good manners. Persuade and convince, instead of giving orders. Invite over inflict. Be approachable. Be vulnerable. All these points are correct. But this doesn’t mean that they are enough to make you a leader. They make you better, yes. But not a leader. They make you a better colleague, a better parent, a better friend. In short, a better person. So, they are important, yes; but not enough to become leaders.
A systemic view
If we take a systemic view, the point is not on the individuals and neither of course, on the skills. The focus becomes the surrounding conditions, and here we are getting closer to Netflix’s mantra: “Lead by context, not control”.
Aligned autonomy is achieved by, instead of communicating decisions, sharing the decision criteria. Teams make decisions in each specific situation, based on common values and principles.
In short, a systemic view is all about creating the surrounding conditions that allow teams to focus on value creation. These conditions include elements like transparency, common awareness, shared values and much more. But they also mean concrete aspects. Take for instance, the following examples.
Awareness
Tetralog is a company in Munich, specialised in IT solutions that optimize investment portfolios. One of their teams was already using Scrum, but a project initially estimated to be completed in seven months was, after 3 ½ months, less than 20% done. How did we solve that?
There were many actions taken. But to highlight what was done regarding awareness, we built a state transition diagram showing all dialogs in the main use case, as well as all services being called in the backend. The whole diagram was covering a room wall and things were atomic, even “done” or “not done”. There was no intermediate status (which is another important element).
The point is that by making the whole situation visible, people started making better trade-offs. A colleague who was requesting a few days to study a new web framework, after looking at the diagram and noticing how much was still pending, simply said, “This might not be the best moment for that”.
People started being more conscious about the whole scope, where we were, and what was still missing. They started making better trade-offs, and choosing the right balance at each step.
Another example was at Bayer, in Berlin. Multiple teams were working in a large program (~200 people) being rolled out in more than 150 countries. That was the first agile implementation for most of them and things were going pretty well. The IT program manager told me how satisfied he was with the actual situation but he also said, “My concern is that I do not have enough visibility about the future, and don’t know if we are going to hit the wall in a couple of months, due to things that we could be solving now”.
The solution was to implement a dashboard in an HTML page, with a simple visualization of the value stream. While the teams were able to use Jira, as it better fit their purposes, we could extract via Jira Rest-API the numbers of different stages and show them in an aggregated view, in real time.
While all columns of the teams down- and up-stream could have been more than 20, the consolidated view was something simple, like this:
The numbers were extracted in real time, and when clicking on them, the hyperlink redirects to the list of tickets in Jira.
That was a non-intrusive solution, giving teams full operational autonomy, while having the overall information consolidated in a single, aggregated view, with data extracted in real time and with a direct connection to the reality.
What was really interesting to see was that only by presenting this concise overview and making clear that what really counted were not the “story points” done during a sprint, but the number of features released in production, the overall performance raised in just three sprints, from 21-23 features per sprint, to more than 30. This is about a 40% increase.
Back to the original request of having a visible forecast, by storing the figures at the end of each sprint we could look at the different trends. And by viewing how the incoming change requests were growing, the approval ratio, and the implementation velocity, the conclusion (later confirmed in practice, and consistent sprint after sprint) was that the whole implementation was going to be done by October / November.
This certainty permitted us to start thinking beyond the actual situation and be better prepared for the future.
Atomic progress
A common flaw that some people tend to introduce is “precision”.
In the first case, a manager suggested using ‘Harvey Balls’ instead of just a red cross or green tick, to indicate “done” or “not done”. Harvey Balls show progress in 0 - ¼ - ½ - ¾ - 1.
There are many problems with this level of precision. Too much detail. Micromanagement. Task switching. Outside pressure. Justification of delay, by delivering fragments. And more.
We did not use them. The good thing is that once the company CEO was in the room and looked at it, he commented, “Even I can understand it!”
“That’s the idea” was my answer. Simple. Easy to read. Yes, this is another important aspect, because it doesn’t work if it’s too complicated. It should give an overview at a glance.
Back to atomic progress, I often show the following image in my trainings:
And then ask, “If there are two projects 90% done, one with 100% of the modules 90% done and another with 90% of them 100% finished, in which of these two would you like to be?”
After viewing this with hundreds of people, maybe a couple thousand, only one person once responded “In the one on the left”. The argument was to have “no surprises” on the remaining part. And I agree. But first, completing things before starting new ones doesn’t mean that you remain totally ignorant of the rest, and second, the riskiest ones should be done earlier and never postponed to the end. The one on the right is the right approach.
Remember: “stop starting, and start finishing”. Only 100% done counts.
As it was mentioned before, another important element for these information radiators to really work and increase awareness is that they need to be easy to read. This can be achieved in many ways. For example, by having a common view on how progress is measured.
Common unit of progress
It is not unusual to see different levels across the organisation of a large program talking in different terms. This is normal and expected. The level of detail that senior management has to deal with cannot be the same as that of the engineers modifying the cloud infrastructure of the deployment pipeline.
However, when talking about progress, if we have some talking about epics, others about features, implementation teams discussing stories, and others working on tasks, it shouldn’t be surprising that nobody really knows what the actual progress is.
In the same way that it is important to agree on the moment in which progress is measured (e.g., when deploying in production, or when there is a certain change in some indicator), it is also important to agree on the unit of measurement to be used.
Then we have a common unit of progress that is atomic. And by making this progress clearly visible, we raise the overall awareness. This results in a velocity increase that can be potentiated by other elements of the context.
Clarity of purpose
From a systemic point of view, everything matters. Not only are all elements important, but the relationships between them are especially meaningful. It is like those images we used to draw when we were kids, connecting the dots to see the figure hidden in between.
This is especially the case with purpose. It is not a point that needs to be precisely defined; it is more in the way it connects with the rest, providing direction and alignment, where we see its importance.
It should be clear enough to be unequivocally distinguished from other alternatives, but since its importance is in the direction and alignment that it provides, it is not a point you will necessarily get to. The north is not a precise place where you can be at, but a direction that helps to orient and navigate. This is an important element of the context, because this is how leadership makes clear what is expected from the teams. This is how organizations define their “raison d'être”, how they intend to delight customers, and by aligning everyone on the journey, the waste of having teams working in contradictory goals and cancelling each other's efforts is reduced.
When clearly and properly stated, purpose provides consistency, alignment, motivation, and other aspects that multiply productivity. When the definition is not so clear, strange things happen.
Take for instance the efforts done by Satya Nadella at Microsoft. It is really impressive how ways of working have changed. However, a way of working is just a means to achieve a bigger goal. Lack of clarity on this can produce strange things, like the “productivity score” in Office 365 that measures activities such as the usage of the different applications, the number of emails sent, or how many meetings each person has attended.
This is to go back to the old times, when instead of aiming for outcomes and having an impact on clear metrics, companies were just measuring activities, trying to get the most out of them. Typing more, sending more emails or going to more meetings doesn’t make you or your organisation more productive. It sounds even weird having to say this today.
Too much emphasis on the way of working can be counterproductive. Focus on purpose first, and the teams will find their own way. This is why “Agile Transformations” are an anti-pattern.
Measuring activities is not the same as measuring results. Favour “Outcomes over Output”, as Josh Seiden says. And by understanding these things, we start changing our mindset.
The mindset
The case of Microsoft is a good example of certain things we take for granted, rooted in our deepest assumptions, that leading autonomous teams demand to change.
When we were producing simple products, each identical and in a mass, focusing on activities made sense. The more workers do, the more we produce, and the more we sell.
These were the times when Henry Ford could say, “A customer can have a car in any colour, as long as it is black”. Why bother with customisations that slow us down? The market demand was so huge, coming out of millennia of artisanal work, that we could sell almost anything we produced at an affordable price. Cost reduction was paramount in the past.
But these times are over.
Finding a product-market fit is not easy anymore, and reducing costs is not necessarily the best strategy. Top companies run multiple experiments all the time. Between 80 to 90% of these experiments fail: “For every experiment that succeeds, nearly 10 don’t”. How do they survive? Simple: the bigger the risk, the smaller the experiment. I call it S.O.F.T. (Small, Often, Fast & Try again).
This is why it is important to understand that the environment is complex. It is like any scientist when running an experiment; we only know what the right activities are afterwards.
This means that tracking activities for performance measurement is pointless. Discussing those that have proven to be right and sharing the learnings with the rest of the organisation is precisely how teams learn from each other. This is how we learn as an organisation. Yes, this is also part of the right context.
A driving analogy
So, there are many more elements we could discuss, and even more implications when they start connecting with each other. Instead of continuing endlessly, it might be better to start bringing all concepts together into an example that gets us closer to the big picture.
There are many analogies to compare waterfall and agile ways of working. Without these analogies, people tend to judge everything from their usual point of view and some things can be difficult to digest.
One participant of a training I was giving many years ago was heavily arguing that it was totally unacceptable not to have a risk analysis document before starting the project.
One day, once the new ways of working become the normal way of thinking, it will be astonishing to think that huge programs used to be run based on a single, one-time decision, when the budget was approved.
To think that risks were covered by writing a document would be incomprehensible. This is like having a scientist experimenting to see if a given combination of substances is explosive, and instead of trying it on a small scale, decides to write a document about everything that could go wrong.
To demonstrate how all these elements that help to increase awareness work together, a good analogy is a GPS.
In the past, we used to have maps: big books with overviews in a matrix, each quadrant amplified on another page and so on, successively.
It was not unusual to make estimations and plans, trying to predict the arrival time, and in the case of a long trip, to also consider the stops and the time to be spent at each of them.
Today, with a GPS, none of this makes any sense.
You need a destination. The goal. We often use a precise address, but it could just be a city and we can refine the target once we get close. The GPS has a direct connection with reality. Figures are not a number in a slide, extracted from a spreadsheet, after importing the data from Jira. We can easily zoom in from the overview, to any concrete point. And we can be sure that we are viewing the same as any other colleague, at any level.
Information becomes trustworthy. Clarity reduces stress. We feel more productive, connected, “on the same page”. We are a team.
We all know what “progress” means, and we see it every day on information radiators, all around. Custom options permit us to choose which paths to drill down, from the common overview to our concrete team objectives. A carousel then shows the successive screens, from the overall company overview, down to us. And this is visible in our team’s room, our team wiki page, or anywhere needed. Full transparency.
Does this solve everything? Of course not!
But from a systemic and organisational design point of view, this helps in regards to leadership, high performance teams, and aligning the organisation in the pursuit of common objectives. This is how waste is reduced. Purpose becomes clearer. Our results make sense. And organisations learn, reduce stress, and enjoy happy and healthy environments.
Comments