In this blog post I want to share a powerful tool, the Leadership Health Check. It will help you become stronger as a management team and reveal improvement opportunities for how you, as a team of active servant leaders, better can enable the agile teams you support.
But first, let’s take it from the beginning.
One of my favourite exercises in my toolbox as an agile coach is something I learned during my years at Spotify; the Squad Health Check. It’s a retrospectives format, a self-evaluation workshop, in which the teams express how they feel they’re doing on wide variety of topics such as collaboration, value of what is delivered, ability to influence, received organizational support, etc. The result generates insights and commitment to actions of improvement for both the team and the supporting leadership. I love it because I believe it’s a great tool for strengthening autonomy, culture and continuous learning.
More than a year ago, a colleague at Spotify Georgiana Laura Levinta and I created a health check for the leadership of our Tribe (Tribe is a semi-autonomous department at Spotify encapsulating 4-8 teams and with a dedicated set of leaders and managers). Geo and I were inspired by the Squad Health Check, but the goal with this adoptation was to help the Tribe’s managers perform a self-evaluation of their ability to provide active supportive leadership to the squads within the tribe, and to generate a discussion on how they can improve as a team to be able to provide even better support.
Since then, I have together with my current client Casumo, adopted this for their context, culture and beliefs. We’ve run it several times with great success and value, both with the company’s leadership team but also on cluster level (semi-autonomous department). I believe the Team Health Check and the Leadership Health Check both are tremendously powerful; hence I want to unleash them to the wider agile community, hoping that more organizations will find them valuable and useful. Or at least be inspired by them, and then try something totally different.
Don’t stand in the way of great employees.
That’s one of the operational mantras that guide the finance technology company iZettle.
Two others are “Keep the startup spirit strong” and “Stay adaptable to changing market needs.”
In this blog post, we share some of the things we are implementing and tweaking at iZettle to keep producing great results and attracting in-demand, talented developers. My role has been to assist the tech development organization in making this work.
(Another blog post coming soon will cover the transformation of making the whole company agile, while this post focus on the practices that are put in place to keep a high performing, decentralized tech development organization at iZettle.)
Let’s begin by facing the reality of fast-growing startups.
The organizational challenges for most fast-growing startups
Most startups want a flat organization to keep their entrepreneurial juices flowing, but when new employees join in a steady stream there eventually comes the point where the founders or upper management feel overwhelmed by chaos.
Things get confusing.
Employees aren’t seen.
No one seems to know what’s going on.
What usually happens for most start-ups at this point is that bureaucracy processes start piling up. Layers of management are added, and project managers are introduced to coordinate the chaotic environment. And so are written reports for managers to send to upper management, and silos are building up between different departments. And decisions are taken somewhere else.
And then what happens?
Usually, entrepreneurial enthusiasm suffers and so does talent motivation and speed of innovation.
And that is exactly what iZettle wants to prevent.
But that is easier said than done when a company grows like a wildfire.
I recently published a video exploring how an agile team based organization could look like. How does it function under the hood? In the video I also discussed how you get there.
I got tons of great feedback so I decided to provide the contents of the video in the format of a blog. If you prefer to read instead of watching a 11-minute-long video, then this is for you 🙂
Last month, we had the pleasure of bringing Stephen Bungay to Crisp in Stockholm to share with us his wisdom and insights on how to use Strategy under uncertain conditions.
I find this topic interesting, since the interative nature of Agile can trick management into believing either that they do not need to have a direction, or that a few abstract statements would serve the purpose.
In my mind, nothing can be further from the truth. In a dynamic, fast paced environment, more attention needs to be focused on finding, communicating and revising your direction. The question then becomes, “How can we do a good job of it?” Stephen has studied how leaders do this (from the military to Formula 1) and has translated the strategies to fast-paced business environments. Interestingly, he notes, “Strategy is not a science. It’s a practice, which each generation needs to rediscover.” I think we would do well to do the same within Agile environments.
Apart from Stephen’s “Art of Action” class, which was highly recommended, we also hosted an open evening on the topic “Keeping Direction” which combined the practical experiences from LEGO with Stephen Bungay’s insights. The slides for the talks are available in PDF from the links below:
.
Here are the slides from my Agile Africa keynote Alignment at Scale (or How to Not become Totally Unagile when you have Lots of Teams). Thanks for a great conference!
And thanks everyone for the Emma greeting, that sure made an 8 year girl very happy 🙂
(Emma was supposed to join me on this trip, but couldn’t make it because I had missed some required paperwork for travelling with minors to South Africa).
The Spotify ‘model’ was presented in 2012 and has stired a lot of interest in the agile community and the software industry in general. In May I was asked to talk about this a the Bay Area Agile Leadership Network meetup in San Francisco (where I at that time was working as an agile coach at the Spotify office): Since 2012 Spotify has continued to grow hectically. How has agile evolved at Spotify since then? Going back in time, and following the latest structural changes makes it clear that the model was never the primary mover: instead a number of core principles and ambitions has worked as constraints on how to grow the most suitable organization for the task, with small enough structure to help but not be in the way: you could call it Minimum Viable Bureaucracy.
Last week, I got this great question from Faraz (a manager for an energetic customer support crew) who is experimenting a lot with getting more Agile. “What seemingly normal things do Agile people do?” I realized that we rarely talk about the small things that effective Agile people do. What makes a great difference is rarely the big sweeping change programs, but rather, the small everyday things we do without thinking about it.
So here’s a list of 12 seemingly normal things Agile people do which we don’t pay much attention to that can make a big difference.
Good meetings is very much about achieving deep collaboration. But collaboration is often hard. We go into meetings with different modes, intentions, and expectations. How can we make meetings both more fun and energetic? Surprisingly enough: maybe by being more formalized. read more »
Agile product development has become the norm in many industries (especially software). That means products are developed by small, self-organizing, cross-functional teams, and delivered in small increments and continuously improved based on real customer feedback. Pretty much as described in the Agile Manifesto – but replace the word “software” with “product” (because it really isn’t software-specific).
That’s all fine and dandy. However when things get bigger, with dozens of teams collaborating over organizational boundaries, things obviously get more complex and painful. Even if the entire organization is neatly organized into scrum teams, you can still end up with an unaligned mess! Here’s a picture that might feel familiar:
Låt oss börja med två okontroversiella påståenden: Företag bygger på vertikala hierarkier och horisontell specialisering Ok?
Låt oss ta det en gång till.
Företag är hierarkier. Jag skriver här medvetet företag och inte organisationer i största allmänhet. Huruvida organisationer måste vara hierarkiska låter jag nämligen vara en öppen fråga, men företag är hierarkier, per definition.
Det finns förvisso många olika teorier om varför företag finns, men i princip alla går ut på att förklara varför människor som utför aktiviteter på en marknad “väljer” att karva ut en bit av denna ekonomiska aktivitet och där slopa marknadsmekanismerna.
Huruvida skälet till detta är att det minskar transaktionskostnaderna, eller att det löser problem med så kallade externa effekter (marknadsmisslyckanden), eller för att det ökar effektiviteten i hantering av olika egendomar, eller för att det ger makt att hantera ekonomiskt överskott, eller att det helt enkelt ligger i den mänskliga naturen att dominera andra, spelat för vårt resonemang här ingen roll.
Poängen är att kärnan i företag är att någon (företagaren) skriver långsiktiga kontrakt med en eller flera (anställda) som avsäger sig vissa av sina friheter för att i stället bli företagarens agenter. Som en av pristagarna till Sveriges Riksbanks pris i ekonomi till Alfred Nobels minne sammanfattar: Företagaren “försöker utforma avtal med agenterna som ska stimulera dem att öka hans vinst, och han kontrollerar deras prestationer”.
Eller som Henry Ford uttryckte det i lite mer klartext: “Jag tänker betala er tillräckligt mycket för att ni ska finna det värt att acceptera mina diktat i jobbet”.
I guess you have heard about T-shaped people, that is, people with deep skills within one or a few areas combined with some knowledge in many areas.
Now it’s time to introduce U-shaped teams. That is, teams that are balanced and where teammates are helping each other. It’s a team where you might have a bad day and are allowed to fail without causing consequences. It’s where the teammates help you get back to normal and what’s more make you feel comfortably included in the team. Your team becomes your safety net and it’s the place where you can dare to be vulnerable. U-shaped teams are also good for productivity since safety means productivity. *
Every organization has its culture that you can see when you observe people at their daily work. This observed culture should be aligned with, or congruent to, the official organizational culture. In reality there is often a gap between the intended culture and the real observed one. For example, management might say that quality is above everything else, while pushing to release new versions of low quality product riddled with defects. Or an organization touts its focus on learning and removing impediments, while the reality is the complete opposite. This post discusses the impact and importance of cultural alignment.
So, you’re planning the future. There are is a lot of stuff you are eager to do. But stop and think – are you pushing forward in the right direction?
Make sure there’s a balance between:
Product – what would makes up evolving in the eyes of our customers?
We are not pushing features for ourselves right?
People – what would make this a better place to work in?
Are we leveraging the skills at our disposal?
Process – are we limiting WIP, improving quality, surfacing problems early?
Done right we should gain time to experiment and fulfilling creative ideas.
Purpose – are we contributing to the society around us?
So, you’re planning the future. There are is a lot of stuff you are eager to do. But stop and think – are you pushing forward in the right direction?
Make sure there’s a balance between:
Product – what would makes up evolving in the eyes of our customers?
We are not pushing features for ourselves right?
People – what would make this a better place to work in?
Are we leveraging the skills at our disposal?
Process – are we limiting WIP, improving quality, surfacing problems early?
Done right we should gain time to experiment and fulfilling creative ideas.
Purpose – are we contributing to the society around us?
If we set the decision lenght of a goal too far – the goals will be eaten up by the imminent future and risk lose focus.
If the set the decision lenght too short, we risk "decision thrashing" (organisation loses faith in leadership because of constant change in direction, seemingly without thought). An example would be changing strategy more often than the strategy can be implemented.
So it is very important we set the goal horizon to a periodicity which allows organisation understand, assimliate and produce results.
Meeting a senior management member from Volvo brought this issue to light for me many years ago.
"How long time does it take when top managment changes strategy from the decision until the shop floor worker understand what it means in his daily work?" – he asked.
"I don’t know" – I replied.
"Three years" – he replied.
I was then able to test some of my learnings from the PSL class in a exercises I made up just the day before.
The results were almost too good.
I divided the class in two groups (consisting of about 6 people each) and told them that they in this exercise would do a drawing during silence, following a requirement I would hand out. The would only have one minute to complete the drawing.
I provided them with a number pencils in red, green and blue and one big piece of paper each. Then I handed out one paper with the requirements to each group and started a visible timer counting down 60 seconds.
One of the groups got the following requirement:
Draw a beutiful summer meadow with blue and red flowers in green grass, some cows and birds under a shining sun.
The other group got the following requirement:
Draw a beutiful summer meadow with
10 blue flowers with 5 petals each
5 blue flowers with 6 petals each
13 red flowers with 6 petals each
2 cows with 3 black spots
1 cow with 5 black spots
2 cows with 4 black spots
2 birds to reside in the upper left corner
3 birds in the middle
one sun to the right with 5 sun beams
Before reading further, look at there drawings here and guess which drawing was made by which group.
Well, as you might have guessed, the drawing to the left was made by the group that got the open-ended requirements and the drawing to the right was made by the group with a lot of specification detail. And that drawing does’nt even comply to the base requirement; a summer meadow.
And the cows are, although rich in detail, on the wrong angels. – The group behind the right drawing had such focus on implementing every detail of the requirements that they forgot the main purpose of the “assignemnt”, to draw a meadow.
Do you recognize that from software development ? I for certain do, and I do remember how boring it have felt implementing over-specified requirements. I just wanted to get it over with. Which I think is a very natural reaction when you are left with no opportunity for your own creativity. Or worse, find out obscure ways to put in your creativity anyway, in ways that might yeild even worse solutions.
I felt that the class got the same “ah” experience as I did myself on the PSL class.
Once again I have to give my appreciation to Jerry Wienberg, Esther Derby and Johanna Rothman.
The Problem Solving Leadership class continues to make a huge impact on my life.
It is the most expensive class I ever spent my money on in terms of actual swedish kronas, but not a cost but truly profitable in terms of the leverage it has on my consulting.
If you are a consultant like me and work with teams and leaders I think you can do no better investment than attending the next PSL class. It will be held in late march, check it out and click here!
The PSL class was a remarkable experience different from any other class I ever attended in my life. The following youtube clip shows how much fun it was, here when we in "The Red Team" made a "Musical Performance" which we had only one hour to invent and prepare. Remember to watch in high resolution if your bandwidth allows it.
Everyday was full of experiences and triggered strong emotions within and between us who attended. Probably, the class will meet again many times, since we did a whole lot of bonding through the exhausting exercises.
Most of the exercises were simulations, that is they simulated situations we all where familiar with, but gave us a whole lot of different perspectives on.
In the biggest one, we simulated a whole company. And during the simulation I found myself feeling distrust for what the "development team" where doing, myself being part of the sale-force of the company (actually, and I am proud of it, I was the first one to figure the whole sale-process, and I got the title Salesprocess manager! 🙂 ).
I have seen people outside development teams, sales people and managers expressing exactly this feeling, and now I felt exactly the same, and I even didn’t recognize that until after the simulation.
Very interesting! Shows the importance of transparency and of trust I would say.
You might now wonder how did the simulation look like, but I will not blog about it, in case anyone reading this want to experience it themselves, I could risk ruin it for them if I would describe how the simulation worked.
So what did I learn ? So much, and I am still processing the experience, but I will try to express some insights I got so far;
1. "The problem is not the problem – it is coping with the problem"
Meaning, often we have a defined solution for a problem that is much more complex than needed. Our, or better, my instinct to quickly find a solution for any "problem" I face, often leads to a bigger problem, which is implementing the solution, which might be real hard, if the solution is not appropriate, and not what others want.
If I instead try to wait with interpreting the situation too quickly and creating a solution before I actually understand what the problem is, I get much better results.
2. "Finding a zero-level solution first makes it easier to develop a good solution onward"
Faced with any problem, it seems that if I first try to figure out what is the easiest and simplest possible solution for this situation, that requires the smallest amount of work, everything will be much smoother.
With the zero-level solution I get a security, that no matter what, there is a solution.
I can then build on it with small steps.
Which is exactly how TDD works, but this works for anything, not only programming.
3. Going with the flow is much more effective leadership than trying to lead by trying to persuade other to go for your solution.
Being smooth and going with a flow in a team is much more effective leadership than trying to enforce your own will onto the group. A process is always better than no process, and fighting about it waste a lot of time.
Often fighting or being in the Big Game (the powerstruggle) hides the constructive path to find a good solution.
As important it is to be honest about my opinions, it is important that I accept and commit to decisions made by the team. There is never only one perfect solution.
The first priority must always be to find a solution, any solution. Then we can refine it with the time and resources we are given.
4. "Problem-solving leadership may be defined as
The ability to enhance the environment
so that everyony is empowered
to contribute creatively
to solving the problem(s)." – excerpt from the class
I think this is so beautiful – and true. And it goes along the same lines as Patrick Lencionis work. Leadership is making a team work, and anyone can execute it.
5. Leadership and management is two different things.
Well of course. Leadership can be executed by anyone. It is of course good if a manager is a good leader, but it is not a necessitity. If there are good leadership skills among the team members that might suffice to make an effective team.
6. Doing nothing can be an important act of leadership.
Sometimes when a team is struggling, the best thing might be to do nothing, or rather just observe. Through observations you might get a better understanding of what the problem really is, which often has little to do with anything else than the people themselves in the team. 7. A lot of specification will be bad for the teams creativity and yield in a worse solution.
Letting the team use it’s creativity to find their way to a solution open up for the possibility for the team to get into a creativity flow which probably will yield a better solution than if the team has to work towards a detailed specification.
Of course there are usually boundaries for any problem that has to be specified, but let the team have as much freedom of creativity as possible if you want high productivity and neat solutions.
This I experienced several times in the class simulations as I have in my career.
8. Simulations are a very effective way to learn.
I will remember to use much more practical exercises and simulations in my own classes in the future. Some of us attending the class are also thinking about forming a society where we can meet and try out ideas for new simulations.
Simulations are not only effective learning – they are so fun!
Maybe because they bring about so much emotions. 9. Keeping a hand-written journal and notebook helps me organize my life and be effective.
I’ve tried to have TODO lists on my computer, and in many other digital forms (PDAs, cell phones etc..) because my handwriting sucks.
Jerry gave me a personal gift. A Uniball pen. It has done a miracle for my life.
With a small notebook from the class, I am now able to anytime anywhere write down ideas and todos and reflections on my own behaviour.
My life has taken a new direction, and only this little change has made a huge impact.
Slowly my handwriting will also be better. And it is fun! Writing notes on paper is actually fun! I didn’t know that! Thank you very much Jerry!
Jerry Weinberg, for those of you who don’t know him, is one of the foremost writers, speakers and thinkers when it comes to leadership.
You can read about him on his website www.geraldmweinberg.com.
I just want to give you some small anectdotes he told me:
As a young programmer working for IBM, the computer he was in charge for was hired out to companies, and he came with the package so to speak. At that time the computer he worked with, was 10% of the worlds total computer capacity. Having the opportunity to program a lot before most people ever heard about programming might be one reason why he soon was ahead most the others in the business.
Beside being one of the developers of the first Operating system, and the Fortran language, Jerry also was the Chief architect for the NASA Mercury mission, sending the first american into space.
He almost missed that assignment, because he first turned it down being tired after a journey. In the elevator down from the recruiter, someone told him about the mission of the project, and being very interested in anything concerning space and astronomy and sci-fi, he immediately went back and was able to get the assignment before anyone else took it!
For me Jerry stands out as the most impressive person in the IT business I’ve met so far.
Johanna Rothman was the woman inspiring me to attend the class. Watching her webcasts on InfoQ before the class, was what made me make up my mind.
She gave me such good advice on how to improve my consulting. I am very thankful to her for that. She is a very bright woman having so much insights about effective teamwork.
Esther Derby insights about agile processes, and calm and clear leadership was also a guiding light through the week.
I bought some of their books, on the shelf now is "Becoming a technical leader" by Jerry. "Manage IT!" by Johanna and "Agile retrospectives" by Esther.
I will surely blog about what I learn after having read these books and in connection with what I am learning from the class.
I will also attend Jerry’s class on simulation design later this spring.
