Breaking down the silos - Part 1 of 3

This is a three-part article, on how to break down the silos that still exist and slow you down, even though all teams are agile

Part 2 | Part 3 (tbd)

--

You are helping your company become more agile! That's great news! The company will be able to adapt to (inevitable) changes, while keeping customer satisfaction high.

Maybe this transformation started easily enough. The teams re-organized as small units around a stakeholder representative (the Product Owner, or PO) while committing to completing work every other week or so. They follow Scrum and Extreme Programming. They are agile teams, every team is an agile team. It's beautiful. We are an agile company!

But you notice that something is not quite right. Though each team works in two-week cycles, it still takes 3 months to finally be ready to get customer feedback. The Head of Product communicated an amazing idea yesterday and today already the teams are working on it, and you know you won't see a functional demo for another few months!

What if in 3 months, when we can show this to external users, this is no longer what they needed? What if we were wrong all along? What if we addressed the wrong problem anyway? 3-months from concept to first demo is too long! It's less agile than you had hoped, and it's starting to feel like our agile transformation is not working.

What are we doing wrong? Or does agile not work when more than one team are involved?

The good news is that you're not doing anything wrong. Having done what you did is perfect: re-organized in small units, focus on 2-week deliverables, follow something like Scrum and Extreme Programming.

However this is not sufficient. It works well if each team delivers end-to-end products, but as soon as products are multi-team efforts, then agile teams are no longer sufficient. What you need next is to move from several agile teams, to one agile organization, or one agile company even.

The main obstacle in the way of moving from many agile teams to one agile company, are the silos. You need Silo Busters!

There are many Silo Busters you can introduce. Some you can start doing today, some will take a little bit more planning. They all fall under three big categories:

More Transparency (part 1), Team Collaboration (part 2), and Frictionless Technology (part 3)

Part 1 - More transparency

With more transparency, the silos are still going to be there, but at least now you can see what's on your side of that silo, and they can see what's on this side. Instead of silos made out of metal, we have silos made out of glass. That's better.

1) All teams using the same project management system

This allows any team to see what other teams are working on. Perhaps even offer to help when they realize the team they depend on is working on something they're experienced in. The needle will move in the right direction, more or less dramatically depending on the severity of the problem.

This works because everyone has visibility into other teams' backlogs, without having to learn a new tool and potentially giving up because that other tool is confusing.

2) Company-wide demos

Every Friday or so, teams spend an hour or two demoing what they have built since last time. Each team can spend as little as 5 minutes. The idea is to share what the team has been working on, and not to impress other teams. 5 minutes is plenty.

By seeing what everyone else is working on, teams start identifying areas where they can collaborate more naturally. Even leveraging ideas and solutions from the other teams.

It's also important than managers (all levels) attend these demos since they have a better understanding of the big picture, and can better see the different parts coming together. Perhaps even influencing direction when necessary, iteratively, the agile way. 

This works because everyone learns from each other, while reducing duplication.

3) Information Radiators

Information radiators work a little bit like heat radiators: you're not actively looking for them, but when you walk by then you are radiated. In this case, by information.

A few big screens in high-traffic areas will work beautifully. It's important however to choose the right information you want to radiate. If your company has a small set of KPIs (3 to 5 is good), then have those KPIs very visible to everyone.

This works because everyone will start connecting their daily work with what's really important to the business, and eventually start making the connections with other teams.

4) Measure 3 things

Ask every team to report on 3 simple things each sprint:

1. Sprint goals. What was the goal for the sprint that just ended (agile teams think of each sprint as experiments, validating certain hypotheses). Report those goals here.
2. Completed functionality. What is deployable (if the business really wanted to deploy). It's important to not simply report progress here, but to report completed functionality that is ready for collecting feedback.
3. Learnings and Surprises. What have we learned this sprint, and what slowed us down.

Amazingly, all three topics can be automated if all teams use the same tool, and if that tool allows for some automation. If teams do not use the same tool, or they do but the tool is not easily automatable, then use a shared spreadsheet or even simpler, email.

This works because as a company we will start seeing inefficiencies more clearly. The teams themselves will focus on communicating relevant progress, which will encourage them to rethink how to work, and what to work on.

4) Pre-all-teams-standup

If most individuals come to work more or less at the same time, say 9 am for example, then have a big, all-teams, standup. Free breakfast from 8 to 9 for example, is a good strategy to encourage more people to show for this mega-standup.

This is not your typical standup where everyone is expected to share. Instead this is an informal meeting where everyone is *welcome* to share if they want to. Maybe someone joined your team today, introduce them. Maybe you have been stuck waiting for team X to come back from vacation, say that.

In practice, 4 or 5 people share something on any given day, which makes it very manageable.

This works because everyone is aware of the big challenges of the day. They might even offer solutions (maybe someone else can cover for that team who decided to go on vacation at the same time)

5) Shared Roadmap

Once a quarter, for example, get all Product Owners to share with the rest of the company what their goals are for the next couple of quarters and year.

This works because each team now knows why they're doing what they are doing, and they know what other teams they should collaborate with. They will immediately start talking to each other, and build a plan for how they can accomplish the vision that was just shared.

--

Stay tuned for parts 2 and 3, on Team Collaboration and Frictionless Technology