What are the biggest enemies of effective software development? The evil forces that undermine even the best Agile teams. That prevent you from gaining the full benefits of all that great work you put into your DevOps tools and practices.
The three biggest enemies that form this axis of evil are:
-
Working in silos
-
Too much Work In Progress (WIP)
-
Untested assumptions
Read on to know your enemies. See how they cause problems for your team and organization. And just as importantly: see how you can reduce their impact!
1. Working in silos
Silo work becomes a problem when a team, department, or function only works to meet their own targets. They optimize their way of working and prioritize their backlog to maximize the benefits for their own team.
This mainly happens in larger organizations where you often have monetary incentives for specific teams or departments. A team with its own targets may decide to do something that is detrimental to the organization as a whole.
Organizational civil war
A silo means there are borders. Borders slow or stop the flow of information. This slows innovation, and may for example lead to multiple teams implementing similar solutions. And that, of course, can be a massive waste of resources.
But a silo mentality also has another dangerous effect: It often leads to power struggles within the organization. Office politics becomes important, and there is a kind of “organizational civil war” going on all the time. A mentality of “We must win” prevails over what is best for the company and the customer.
How to fight the silo mentality
The most important defense against silos is open communication. But achieving that is not easy. Open-plan offices may or may not help. The office layout and a “no rooms for people” policy is not a solution, but it can enable more open communication.
Open communication
To foster open communication, you also need to consciously break down team barriers. This can, for example, mean:
-
“Ambassador-style” visiting workers (as retired US Army General Stanley McChrystal would call it)
-
Shared project work across team borders
-
Visiting guest lectures or introductions
-
Discussions and communities across team and function borders
Get to know the people
Increase trust around the organization. And since it is easier to trust someone you know and have worked with, you should encourage workers to get to know people from other teams. To do projects together. Visit their work. Send ambassadors to work with the other teams.
Another way is informal team-building style activities that break down team borders. And is your organization chart visible somewhere? Is it possible to see what the organization looks like and who works on what?
Make leaders approachable
This one is more important the higher up in the organization you go. If the CEO, and the immediate directors below her, are effectively using an “open door policy”, this reduces the silo barriers considerably.
But you also need to combine this with activities and policies to increase psychological safety. Anyone can then raise a topic across organizational boundaries. When they do, this should be celebrated, not punished.
Have a common mission
Few things break down silos faster than having a clear, common mission that is shared throughout the organization.
Then the individual product teams or departments build a “goal hierarchy” that builds on that company mission. That hierarchy breaks down into product visions, product goals, and short-term sprint-level goals.
This goal hierarchy is incredibly important and often overlooked, and tt requires regular upkeep.
2. Too much Work In Progress (WIP)
This enemy comes in two forms:
- The organization has too many ongoing projects, or tries to develop and maintain too many products. This stretches the resources too thin.
- At the team level, the team has far too many work items ongoing on the Kanban board.
When you have too many projects or products
Having too many products will confuse the market and your customers. You do not want to become the infinite general store of your market. If you try to overreach or serve too wide a market, the market requirements will easily become overwhelming.
It is also easier to develop a product than it is to support it in the long term. So you will have more internal conflicts over resources and priorities. The development teams will feel more pressure, as no product or project is staffed with enough resources.
With too many projects or products, you will also “fatten the middle” of the organization. There will be fewer developers and testers compared to project managers or product managers. And if you try to keep the middle management thin, they will be overworked and fail to:
-
fully understand the market
-
define the work effectively
-
test their assumptions (causing the third and final “enemy” that I will cover later: Untested assumptions)
When you have too much work in progress at the team level
Teams that have too many work items going on at the same time, feel like they are working hard. But this hard work may not be productive. What they in fact are achieving is a whole lot of task switching. Task switching wastes time each time a developer has to reset her brain to work on the next thing. Parking another task for later, stops the workflow.
Teams with high WIP are guaranteed to have a slower workflow. If they instead focus on a smaller number of tasks, they will see all kinds of benefits:
-
get more work done per time unit
-
shorten the time from start to finish
-
iterate and get feedback faster
-
a more predictable cycle time — making it easier to manage the backlog and prioritize, as the Product Owner can accurately predict when items currently on the backlog will be produced.
Lower quality of work
Both the high amount of WIP at team level, and the high number of projects or products, hurts quality. It makes it very hard for the team to focus on delivering good quality and maintaining a reasonable level of technical debt.
How to fight too high work in progress
Remember, it is not about keeping everyone busy, but to maximize outcomes. At the team level, here are some things you can do to combat too-high WIP:
-
Train teams and Scrum Masters in effective Kanban
-
Play educational games like getKanban
-
Start setting WIP limits in different Kanban boards throughout the organization
-
Deliberately underload Scrum Sprints (hummingbird Scrum)
-
Place more effort on backlog refinement, Definition of Ready, and Definition of Done
At the organizational level, here are two things you can do if you have too many projects or products:
-
Try using Kanban throughout the organization
-
Work on the strategy, mission, and goals hierarchy
3. Untested assumptions
Whenever you plan to change a product, or add a new feature or functionality, you make a lot of assumptions. For example, you assume that:
-
you know how to build it
-
a certain technical design approach is the right one
-
performance will be fast enough
-
the users know how to use it, or even notice the new feature when it is introduced
-
you are addressing an important problem for the users
Let’s use an example:
You are developing a new feature for your software product. You may assume that just by adding it to a frequently used menu, the users will notice the new menu item and curiously click it to try the feature out.
How could you test this assumption?
One way could be to add the menu item (linking to a “coming soon” page) to a limited release, and observe how many users actually click on it. With this data, you can decide if this is enough to educate users on the new feature.
Work items have many assumptions
There are tens of assumptions for any work item you are going to start working on. Most of these assumptions will not result in problems, especially if the team really knows the users, market, product, and technology they are building. Some assumptions are also not that critical, so even if they’re wrong, they’re easy to fix.
Assumptions differ
Problems also arise when different people assume different things. One developer may assume that a feature should behave a certain way, while the tester or the Product Manager assumes a different functionality. This is the main reason why user stories and backlog refinement are so important. Discussions during the backlog refinement sessions should be able to reveal the different assumptions.
Leap of faith assumptions
The most dangerous assumptions are the ones that completely undermine the feature that is being developed. These can be called “leap of faith” assumptions. Your biggest risk is that these assumptions are not identified early on in the idea development process.
How to fight untested assumptions
Assumptions should be uncovered, prioritized, and tested. You don’t need to test them all, because most of them are not that risky. What is most important is that your development organization does all it can to identify the risky assumptions and perform tests on them early enough.
Start testing early
Start testing assumptions while the work is still on the roadmap. At this point, it is the responsibility of the Product Manager. Identify the biggest uncertainties and assumptions, whether they are about desirability, usability, or technical. Then perform tests to see if the work should progress further down the backlog funnel.
These early tests hopefully validate your assumptions, which means you will have fewer things that are unclear when the work transitions from the roadmap to the backlog.
Scan the backlog regularly for untested assumptions
As the work rises through the backlog toward the top, the team should keep an eye on assumptions in it.
One effective way to scan your backlog for items with untested assumptions that are too big, is the “Scan and Plan” method, which I introduce in this blog post. In Scan and Plan, the team browses through the backlog from bottom to top, identifying items that might need studies or tests. I recommend that you do this monthly.
Do a final check during backlog refinement
Your last opportunity to do assumption testing is when the work item has risen to the top of the backlog and enters the final backlog refinement stage.
Most teams do regular backlog refinement sessions, ensuring they have about one sprint’s worth of work at the top of the backlog that is “ready to be started”. In these sessions, you go through discussions, questions, clarifications, and acceptance criteria for each item. This is the final place to identify assumptions for testing.
You then usually have a few days from a backlog refinement session to a Scrum Sprint Planning session. This might be enough time to perform a test on an assumption.
Final words
Now you know who your three main enemies are, that stand in the way of you getting the full benefit of all that great work you put into your DevOps tools and practices. And you also have some weapons to fight back.
It’s not a traditional war, and you are not going to win through “shock-and-awe”. It takes time, focus, and dedication. But in the end, victory is ever so sweet.
Published: Dec 27, 2022
