Imagine a highway so cramped there is no movement and only a few cars get through every hour. What a waste it is for everyone just sitting in their own cars waiting for everything around them to move so they can get through with their own car.
This is what happens when you have a project organization that depends on the same capacity to move forward and is built on individuals pushing their own thing, not allowing anyone to see the big picture.
A project focused organization treats every new idea and requirement as if it was a big project, and it needs to be big to get a budget and a project manager. What if there was another way? Projects get piled on people and when more and more pile up, since the world is moving faster than the pace we can deliver large projects, the system gets jammed.
To change this you need to look at what capacity you have and instead put things that need to be done in prioritized order. It is that simple.
So turn the focus around and look at the people you have, their capacity, knowledge, and experience and build teams that can perform together. And then stack work on the teams.
It is basically making people work on one thing at a time and helping each other out. No rocket science. The rocket science is to build high-performing teams, for that you need a lot of skills in product development, team development, agile leadership, agile management, HR and work environment to mention a few.
Where we started with our client that needed to shift focus was here, 22 projects stacked on around 120 people and the visualization of it looked like this.
Only showing what status the project had, green, yellow or red. Classic lean-approach. The problem was that there is no real information about what the purpose of the project is, who is working on them and when they are delivering any kind of value. And if green, yellow, red signals are to work there must be a very forgiving culture of showing red, and this wasn’t the case
Projects on a Kanban board
The first change we made was to create a kanban board where we added the project steering models to different steps, we kept the green, yellow, red signal mark to show where the project was at the moment. We also connected the project’s different parts to real business goals and in the bottom started to add teams that worked on the platform and with maintenance that the projects highly depended on.
Then we started with a stand-up every week with all the project managers (27 of them) and the people holding PM3 roles for steering the maintenance and the middle managers holding delivery responsibility for IT services, I think we invited around 40 people. It was a room so cramped the air ran out. Before the first stand- up several of the managers told me “this will never work”.
But it did.
I was told it was a “historic moment of change in their business history”.
What I did was just put everyone in the same room to make them see the big picture. And realize it didn’t add up. There was just not enough capacity to move all of this forward at the same time, the highway was so jammed no one was moving. And I don’t think anyone of them had seen that full picture before.
The next iteration the project managers contributed to making lines between their dependencies and the full picture got even more clear.
The first 3-4 meetings were pretty standard answers, “we are green, depending on this but everything is ok”. But then after about four weeks, something happened. They started speaking up and telling the truth.
“People are feeling really stressed about this”
“The next release is compromised”
“We don’t have enough testing capacity to deliver next release”
“Why aren’t we just moving people to work on the highest prioritized stuff?”
“Can we please just stop doing some of these things?”
And suddenly everyone saw that something needed to change.
The capacity loss to context switching was remarkable
We looked for one more dimension during this time. We asked all the employees to fill in a huge sheet on a wall in the kitchen about how many percent they were spending on a project or in a maintenance team, or on other stuff that wasn’t even on any of those boards. And the result was astonishing. One person asked me in the kitchen “Should I write the official percentage or the real one”. So from here, we got the reality of the people’s experiences. And it was scattered. The capacity loss to context switching was remarkable. People didn’t just have 2-3 projects or tasks they had 6-7 and that isn’t even on the scale of Gerald Wimbergs research. This was definitely one of the reasons no value was getting out.
Value stream workshops
The next step was then to try and find what they were actually working on to create value. So we did a number of value stream workshops where we put the value firs (client, platform, enabler) and then added all the work related to that value and put in the people that were working on those things. The template we used was this:
Yellow circles were the value and the white box on the left was people, the team. Yellow boxes on top we used as a timeline, in this case, quarters. The blue line was projects and deadlines, the yellow we called “initiatives’, the green was maintenance and support and the pink was if there was a team today (platform or outsourced) that worked on that value.
What we found out was that the people worked on similar values but in different projects, teams, or maintenance roles. But where actually creating value for the same client or platform. But we also did see a lot of people scattered, especially people that had been in the organization a long time, and others depended on, like the integration team that almost every new project depended on.
During this time we also did agile training and coached management teams and leaders and interviewed around 20 people to make a proper analysis of where to make changes to a more agile organization.
The next step was to use our agile expertise and all the information we had to actually make the changes. We presented a team-based organization idea to management and did two workshops where they got to experiment on what that kind of organization would look like.
They experienced two big challenges.
- One person can just be in one team
- We need different leadership
We had post-its of names of all the employees, and the managers had to agree on where to put that post-it, in what team. I had to several times just remove the post-it from the wall and say “It is just a post-it, it is this easy to move”. And by that I don’t mean that you should ever move people as easy as a post-it on a wall but in this workshop, we were just experimenting and making a hypothesis. And when creating teams for the first time you will never get them right straight ahead so you have to try, and you have to start somewhere.
For the workshop, we used the same template like the one above but we also added the Agile management quadrant which has four main leadership areas. People, process, product, and technology. Agile management is about creating a healthy dynamic between these four where different people can lead and strictly work with moving their area forward while pacing the others. And at the same time being part of the team.
Corona forced priority
When Corona hit the pain of not having clear responsibility areas for all the people was highly present, and some people had too much to do and others didn’t know what to contribute to when priority and focus changed to only delivering the cars first in the row.
We couldn’t move forward with the team hypothesis at that time because of corona-related circumstances but to help the people organize we started using a Trello board to replace the physical kanban board we had in the office. We never stopped with the weakly sync and more and more people joined in every week just to get an update on what was going on.
Co-planning workshop online
To get the highest priority cars upfront and through the traffic jam we needed everyone’s help and we decided to try a “big room planning”, in corona times of course was remote and online. The tools we could use where Skype and Trello. The first time was a struggle but the second time we got the hang of it and everyone contributed for the first time to planning and securing the deliveries of June and then September. And it was the first time all the people were together in one meeting and having the opportunity to speak up, be heard and really work together on the most important things.
Here is the last iteration of our board:
We decided to have two-week iterations and cards that needed to happen in those two weeks where added. And then we had a column to list what was planned of going out in the next release window. We used principles, purpose and goals as guidance during the planning workshop.
“The purpose is to create a mutual understanding and together make sure we have what we need to deliver”.
The goal was to secure the next release.
Principles we used:
- We practice together, it is ok to be wrong
- Planned releases are goals
- One person can only have two focus in a two weeks iteration
- Prioritize initiatives get capacity (people) first
- Present risks with suggestions to solutions
- We have a common responsibility that this planning will work
Some of the feedback we got from the planning workshop was:
“A real good step towards a common understanding”.
“Simple to see the big picture”.
“We now have a dialogue and transparency”.
“Good that everyone sees the same picture”.
Leaders had the courage to start trying
And just before summer one of the management team decided to go ahead with starting two new teams in the most prioritized area. They used the team hypothesis, everything they learned about agile ways of working and leadership, and most importantly they believe in their people’s capability and had the courage to start trying it out.
I’m proud of many of the leaders that have transformed into thinking people first and I know they will continue to do so. And I know that will take them to be in a better place with their technology, their process, developing their product, the work environment, and developing their people.
Isabelle Svärd, Agile Enterprise Coach