Are you feeling ok? An Rx for component-based eng orgs

Agile transformations can be confusing. There are tech companies out there that still haven’t realized what going agile means. I’m here to help them along. There are strong reasons for wanting to put in the effort:

• Agile transformations bring business value to organizations.
• Agile values promote equal voice and empowered employees. Happy employees are more productive.
• Code written by agile software teams is much cleaner.

Your brain can’t think clearly under duress, making seeing the root cause of what is getting in your way difficult to see.

I don’t mean to pry but, can I ask you something: Is your engineering organization structured by component? If so, your structure is limiting you. It is adding complexity. It is making you slow. It is causing errors. Let me take you through the symptoms, the snake oil, and how you can walk away from a cured org.

Is your engineering structure making you sick? It’s time for a remedy.

The Symptoms

• It’s an epidemic and you’re all infected… It takes a gaggle of people to do a project: not just a visionary and a tech team. Noooo, the project must have everything just right to succeed. Here are just some of the people required to manage this complexity:

Business team → Business Analysts → Architects → System Architects + Business Analysts debating → Team backlogs → Wait for perfect timing → Teams develop (with handoffs and dependencies) → Integration → System Testing → Deployment → Ops/Bugs

• It’s a personal problem… The teams are specializing in their own services, UIs, codebases. They are I-shaped people.
• It doesn’t look good… They protect it like it is an adorable herd of baby goats. As time goes on, it gets ever more complex. The documentation isn’t good because they know how to work in it. They don’t refactor because they know what to touch and what they can’t. Also, they don’t refactor because [maybe] they aren’t empowered to put that time in to make the code work well or [maybe] there just isn’t any reason to. After all, the people who need to know how to work in it, know how to.
• It doesn’t feel good… It’s giving you a headache. Teams need to coordinate with other teams to finish their work. There is a lot of waiting. That spreads a lot of task switching.
• You’re flying blind… When you can’t work on the most important items first (items that deliver value, opportunity enablement, risk reduction, or time-based). See if you can follow this flow:

In this image, there is one backlog and 9 component-based teams.

Two projects are prioritized. Each requires contributions from four teams to fully ship. Notice that two teams are needed for both projects. Those teams are likely feeling a bit of pressure already.

The 3rd project is prioritized. It also requires work from four teams. One team now has 3 simultaneous priorities at once, and 3 have 2 simultaneous projects. They are overloaded. New projects that require their contributions or consultation will have to wait or the team could be funded with more people.

The idol teams are not equipt to handle the 4th, 5th, and 6th priorities, so they start on the 7th priority. They rely on other teams to complete the work though, so they must wait because their work is not as high a priority in the backlog.

The whole process is a complex, frustrating, painful mess. In this model, code is often shipped with lower quality because multiple hand-offs add complexity. You are also paying the tax of time to market. In this fast-moving technology space, that tax could be the ax over time.

Cost of delay may just be the thing that puts you out of business.

The Snake Oil

You know it isn’t going well, so you try to fix it. You hire PMOs to manage the complexity. You add structure and process. People complain but you, for the health of the system, proclaim “It’s for the greater good!”.

You resolve to follow a macro framework to the letter. SAFe, LeSS, waterfall, ANYTHING to make the team more predictable, deliver more value, increase quality. But the more you press on the teams to follow the plan, to ship on time, to reduce the handoff, the more they are frustrated, silent, cameras off, and resentful.

Predictability is impossible in a component-based system.

- Simon Powers, AWA

Does this sound like you?? If so, don’t fret. I’ve got your Rx right here.

The Cure

A sad and common mistake: Trying to find a quick fix instead of solving the underlying disease. The solution is not to manage the complexity but to eliminate it. Here is a game plan. It isn’t the only option. What is right for your org may be something completely different but start here and noodle on how it could apply to you.

1. Take a bath. Everyone needs to take a few weeks and clean up the code. Refactor so that anyone with average skills can get into any part of the code and understand it in 1 to 3 days (preferably less). Code standards, good naming practices, and quality refactors go miles here. Create architecture diagrams anyone can edit and keep them up-to-date.
2. Stand up straight. Help the teams encourage all to become T-shaped people. Encourage people to speak up with divergent views. Create psychological safety everywhere.
3. Make some friends. Form cross-functional teams that have everything they need to deliver E2E and laser-focused around problems, not siloed repos. Celebrate teams working together, learning from each other, and creating communities of practice.
4. Fix your thinking and get out of their way. Everyone, especially leadership, needs to adopt these beliefs and exhibit them in their thoughts and behaviors always:

The Complexity Belief — The problems we are solving are complex, adaptive problems. By understanding the problem, it changes the underlying problem itself. This is the nature of the work we are now in. This is the reason manufacturing work and knowledge work is fundamentally different.

The People Belief — You must hold people in unconditional positive regard. Leaders and teams but believe that people are competent and want to deliver for the team/company/society. We all must believe in this positive intent at all levels of the organization in order to act in a way that promotes psychological safety.

Continuous Improvement — we all at all levels of the organization must be committed to continuous learning and improvement.

This is just the beginning. If you aren’t here yet, I bet you are feeling the pain. Know that small changes over time can lower your blood pressure and your teams’. There is no magic pill but you don’t need to live like this. The choice is yours.

Some of this content is adapted from the Enterprise Agile Coaching certification material produced by Adventures with Agile. It is published with their knowledge and consent.

This article is now also posted on my site here.