Part 9: Agile for non-tech teams

In the previous posts we have been talking about how to work in an agile way with software development and implementations, and this is natural since the Agile framework was developed for digital projects. However, there are huge benefits of introducing Agile methodologies also to administrative and operational teams.

In this post I will share an example of when I have done just that, how it was done and what the results were. This is a long post, so buckle up and take your time.

How a disgruntled team turned into an efficient machine

A few years back I took over as lead for 3 teams working with operations in various parts of Supply Chain.

One of them, lets call it Team ABC, I lead directly since no lead was in place for them. This team was responsible for integration with various business partners, and hence crucial for the automation efforts the company needed.

The team was dependent on various Product Owners and Engineers in order to get the technology needed for fast and smooth onboarding, and their own task was mainly to approach the business partners (suppliers etc), figure out how to map their information structure to ours and test the integrations before it all went live.

Since automation was of high priority for the company, the Product Owners had various OKRs to achieve, such as “increase digital invoices with X%”. This was a way to get the Product Owners to develop various technical solutions to make this increase possible.

However, since the operational teams were considered a kind of a clean-up crew (and in some cases as servants) by many Product Owners, they put huge pressure on Team ABC to achieve the OKRs of the Product Owners. This resulted in my team, desperately trying to get as many business partners as possible onboarded, irregardless of how big their percentage was of, for example, the total invoice volume. In many cases they spent time trying to get a supplier with 0.01% of the invoice volume onto EDI or other integration solutions. This is of course not a correct way if we want to use our resources wisely.

On top of this the team was constantly under pressure from buyers and others dependent on their services. Not least because the poor technical solutions resulted in a lot of problems with the information flows through the systems.

The digital products built to support the automation, were also very rigid, and the company demanded the suppliers to follow the standards we set up, instead of building more flexible and robust solutions that could handle different message structures.

Team ABC had a history of trying to push the Product Owners (POs) for more flexible solutions and also smarter ones, that would require less manual work. These attempts had absolutely zero success, though.

This imbalance between the Product Owners and Team ABC resulted in deep mistrust between the the POs and my team. And worse; having had a history of poor leadership in the team, combined with the enormous frustration the POs’ treatment of Team ABC contributed to, the situation within the team had become disastrous. Some of the team members simply stopped communicating with each other and they thereby became their own worst enemy.

The problems described above, can be illustrated in a problem mapping. It is of course impossible to find out exactly what is the chicken and what is the egg, but I set great importance to the leadership, so lets use that as starting point.

Apart from the above, the team also worked in silos internally. Hence, each team member was responsible for one process; Orders, Invoices, PRICAT etc. In practice this meant that each team member only could handle the onboarding of a supplier on one of these processes. It also meant that a supplier needed to be in contact with various team members to be fully onboarded.

The agile perspective

So if we see this situation from an Agile perspective, what have we got?

• POs demanded that Team ABC should fulfill the OKRs of the POs:
  • Result: Team ABC is not autonomous
• POs did not listen and no agile mechanisms in place for alignment and building work contracts:
  • Result 1: No real feedback culture, but a lot of finger pointing between teams
• The team members worked in silos:
  • Result: The team was not cross functional, which would make it impossible to onboard a supplier or other business partner on one or more processes if the team was decimated
• The POs saw themselves as stakeholders to team ABC, although in reality it was the other way around.
  • Well, obviously the POs were very poor stakeholder managers in this respect, and it resulted in very poor technical solutions for the work team ABC needed to do. Since they thought of themselves as stakeholders it also gave them “the right” (in their opinion), to use the team as servants.
• The team members did not talk with each other
  • Result 1: Nobody knew what the other person was doing, and nobody could get help to solve a blocker
  • Result 2: No real feedback culture, but a lot of finger pointing between team members
  • Result 3: Different messages about the team’s priorities to the POs
• No data driven decisions about how to prioritize the work
  • Result: Time was spent on onboarding suppliers that would contribute very little to achieve the automation targets set

Turning the tide and go Agile

In order to correct the situation I inherited, I put in motion a few different intitiatives.

The first one was simply to raise self awareness and create a sense of higher purpose for the team. I wanted them to become more of a strategic partner to the rest of the organization, than being a kind of service team and fire fighters.

I also saw that the potential in the team members were much higher than acknowledged. The work they did was basically “monkey tasks” where they executed other peoples orders and did not have to use their mental capabilities to any larger degree.

Reason to exist

The first thing I did was therefore to let the team define their reason to exist and their vision for the team. This gives the team members a sense of purpose and purpose builds pride.

Increased responsibility and personal purpose

The second thing I did was to give each team member a secondary role. I did this because I saw their potential and we also needed this in order to fulfill the vision in their “reason to exist”. I had discussions with each team member and we found out that one of them wanted to become an EDI Expert, another wanted to develop skills as Business Analyst, One wanted to become a Project Manager (which is not really an Agile role, but we tweaked it so that he would be the “liaison” between Team ABC and the Product Owners), etc.

This did not only serve as a way to give the members a purpose, but also to set a development plan for each one, which had value for the individuals and would propel their careers forward.

Agile rituals

In order untie some of the knots within the team, I needed to get them to start communicating. I therefore started by introducing Daily Stand-Ups for the team and I brought in an excellent Producer/Agile Coach (Antonia Svetina) to help with the work.
She held a few workshops with the team which resulted in the set up of our first Stand-Up Board.

Since this is not a tech-team we had to tweak it to fit the team purpose, and we decided on a structure where we had each Integration Process (Orders, Invoices, PRICAT etc) as horizontal lines. The vertical ones were “Contacted, Approved, Test, Live”.

Apart from this the team also had some smaller projects they were running, so these projects got their own row.

Worth noticing is that we knew, that this structure would be long lived, but it was a starting point to get going. We remodeled the board as we went along and when we had new OKRs to fulfill etc.

The result of the Daily Stand-Ups and the Antonia’s guidance during these, was that the team members had to start communicating on a daily basis.

One other important impact the Stand-Up Board and the Stand-Ups themselves had, was that it became visible for the POs that we started to work like them, and thereby that we as a team had the right to prioritize and structure our work in the same manner they do.

The Coach also helped introduce other rituals such as Team Retros and Cross Team Retros. The latter greatly helped in the communication with the Product Owners, and slowly the relationship started to improve.

Going Cross-Functional

In order to make the team members more engaged, more autonomous and give them a higher sense of importance, I also took away the current silos.

Instead of letting them continue to be experts on one of the business processes we handled, I made them into Key Account Managers for the various business partners we work with. Hence they become responsible for a number of suppliers, where they had the responsibility to onboard them on all of the processes.

This had several positive results:

1. Each team member became more valuable for the company
2. Each team member felt more important and felt responsible for “their” supplier
3. Team members had to collaborate and work together with each other to learn the various processes
4. The suppliers felt a closer connection with the team and had one person to turn to instead of 3 or 4.
5. Also in times of reduced capacity we could continue the work without interruption
6. We could work on onboarding in a more pragmatic way, since we could start with the lowest hanging fruits for each supplier

Becoming Self Organizing

When I took over the three teams, 80% of my time was dedicated to Team ABC. They had no team lead and they were used to be micromanaged by the former lead. Micromanagement fits poorly with Agile, and therefore it was important for me to let them understand that they were the experts in their work, I wasn’t.

It didn’t take long for the team to embrace this, and sometimes their urge to be Self Organizing might even have gone a little too far.

All in all, though; when you give people responsibility and you trust your team to take the correct decisions, they do!

As mentioned over and over again in this series, OKRs is a good tool for setting direction. We therefore introduced our own Team OKRs along with the department OKRs. This gave a direction for the team on a daily basis and helped them to know what needed to be done and when.

Apart from this, I used the Road-Maps discussed in a previous post, to make it clear for everyone within, and outside the team, where we were going and what we wanted to achieve.

With these simple tools, the team became Self Organizing very fast, and in some aspects I made myself redundant. That in turn gave me time to also be more engaged in the other teams and set in motion an Agile Transformation also for them. A Win-Win-Win Situation.

Leadership

Leadership is important also for Self Organizing and Agile teams. However, the role of the lead changes. So, for an Agile Transformation to work, the lead needs certain qualities:

1. The lead cannot be a micromanager.
2. The lead needs to shield the team from undue pressure from outside.
3. The lead needs to be willing to take the blame if a team member or a team makes a wrong decision.
4. The lead needs to know when to step in and take a decision (a business is normally not a democracy, and decisions needs to be taken even when team members do not agree).
5. The lead needs to be more of a coach and soundboard than a classical manager.
6. The lead needs to be the biggest supporter and fan of her team. You always stand on their side.
7. The lead needs to realize that the team does not work for her. The lead works for the team.

As mentioned, one of my team members wanted to develop into a Business Analyst. Now, it was’t only him who needed to develop his analytical mindset, but actually the whole team.

The reason was their poor communication with the engineers and POs. In these environments we want to take decisions and make prioritization based on data. Thereby no one will listen if you come with a demand like “Hey, we need this or that. Can you develop it for us”. You need to be able to tell WHY you need it and what the Consequences are if you do not get it.

My background as Business Analyst served me very well here, and I spent a lot of time teaching the team various techniques. Hence I was coaching the team a lot, and we developed various analyses together which resulted in a few leaps forward for process improvements.

Measurable results

Of course it is important to know if the actions taken have the desired results. Therefore companies should work with various methods to measure team and individuals’ happiness. In this company this was done every 3 months, and I collected the results every time to keep track.

The below graph shows the development.

Things always goes up and down, and during a period the company went through quite big changes that impacted negatively on almost all aspect, and especially leadership and impact in survey number 4.

However, I hope you can agree that the changes contributed to an upward trend in general and I am especially happy that the happiness with the leadership went from 30% to 75% during this time.

This is the last post in this series. If you appreciate them I would greatly appreciate if you share them on your various social networks or with friends.

You find the whole series of posts here