Sometimes work is easily visible. It’s pretty easy to see progress on a backyard garden or when remodeling a bathroom. When it comes to software development, work can be much more opaque. Add to that a scaling team, and you’re creating a recipe for misalignment, miscommunication, and poor morale. Here are three problems I’ve been able to solve by making work more visible.
Problem 1: Who Owns What?
As the size of your team increases, so do the number of roles and the number of people within a role. This isn’t a bad thing. A larger team necessitates more coordination and planning capacity to get work teed up for development, and the system is growing so fast that a simple team structure cannot stand.
But, as you begin adding new roles and putting multiple people into similar roles, you’ll start to hear statements like “I’m not sure who I should chat with about feature X” or “I’d like to work on area A, but I’m not sure if anyone else is already working on that.”
This is a sign that you need to make more work visible.
For developers, this is why a backlog exists. A well-defined, prioritized backlog should easily radiate what is important to work on next, what others are working on, and what other people have completed in the past.
If you’re finding that team members in other roles, such as design, are struggling to understand what to work on next, create a design backlog and maintain it just as you would a development backlog. Make sure priorities are easily understandable and that designers can pick up new tasks easily.
Problem 2: Constantly Changing Priorities
The dream client is a client that understands that priorities change, but they only push those changes onto the team when they are certain they want to change directions (for now).
However, we don’t often live in dream world. Sometimes clients shift priorities often, introducing noise into the process.
When this happens, if your work is not visible, it is very easy to succumb to this chaos. Accepting it enables others to do it even more often. It becomes a vicious cycle, and you start to see milestones slip, incomplete functionalities, and a loss of team morale.
If your work is visible, you can tool yourself to defend your team from the chaos. You can do this while still providing the client the opportunity to change priorities.
One way I make work visible here is through a milestone scope burn-up chart. This visual is simple. It shows how much work the team is projected to complete by the end of the milestone and how much work exists. When priorities shift, scope changes. If your team has a burn-up chart, you can use it in a conversation with your client to discuss what functionality trades should happen to hit the milestone.
Problem 3: What’s the team working on?
Even when your team is in total alignment about who is doing what, what the priorities are, and the broader vision, sometimes the client is not.
The tools used to make work visible to the team may be difficult for stakeholders, non-technical people, or just busy people on the peripherals to make sense of.
An under-informed client has symptoms such as:
- constantly asking about current work and priorities
- micro-managing the team
- over-promising deliverables to others
If a client is under-informed, making your work visible in a way that works for them is important.
One way I do this is by sending weekly project postcards. These postcards are simple and include work accomplished this week, goals for the following week, milestone progress, and a budget summary. It’s visually appealing, easy to digest, and easy to disseminate to others.
When I’m presented with any of the situations above, one of the first questions I ask myself is what can I do to make the work more visible. What are some other problems you’re able to solve by making work visible?