Read any article regarding agile software development, and you will find that the importance of sharing information is emphasized in most cases. SAFe (Scaled Agile Framework) has transparency as one of its core values, with many of the practices and ceremonies hand-crafted to promote and facilitate it.
In reality however, it is easy to prioritize other tasks which are interpreted as more pressing in the moment, and not spend enough time on sharing information or making it available in an easily consumable way. You simply get caught up in your more important day-to-day tasks. Before you know it 3 weeks have passed, key decisions have been made, and key people have not been notified. Suddenly parts of the team are working based on obsolete assumptions.
What to do about it?
- On team level, visualize your plan in a physical location, and share your team’s plan and current progress at every opportunity
No matter how good digital tools have become for tracking work in progress and visualizing Kanban boards, nothing is better than having a physical display of your plan and progress for all to behold. It can become a landmark and a talking point at the office, lead to spontaneous discussions which can potentially solve problems and even make it easier to spot potential bottlenecks.
Update the board regularly, use it as support for discussions as much as possible, and share its contents in every appropriate forum. In this way, stakeholders will have a detailed picture of what features will be ready and when, become aware of potential delays at the first possible opportunity, and help to prevent potential bottlenecks which they discover.
Potential artifacts to display physically could include:
- A summary of the key objectives to be achieved in the coming weeks, with a visual representation of current progress (eg. a progress bar) beside each (acts as a reminder of why you’re doing what your doing)
- A summary of what features/stories will be ready and when, with key dependencies highlighted (eg. SAFe program board (see here), alternatively a high level plan of the upcoming few sprints)
- The backlog, showing candidate features and stories which could potentially be pulled into a sprint in the near future; gives transparency regarding what is prioritized next
- On program level, be sure to involve teams in key decisions and communicate outcomes at the first opportunity
Equally as important as ensuring that information spreads within the team and outwards, is sharing information from management and stakeholders with the team. It’s a two way street. You as a manager may be convinced that you are making a logical decision for the company’s best, but if the team aren’t kept informed or involved along the way, from their perspective, it will likely assimilate to a cow falling from the sky; literally out of the blue. You will probably be on the back foot from the start, with the team in defense-mode. It will then be difficult to implement the decision in the best possible way.
Simple ways to combat this could include:
- Taking an active part in planning sessions, and sharing the business context at every possible opportunity
- Making notes from decision forums available to the team, and inviting team members to those forums when relevant. Discuss and reason around decisions afterwards
- Co-locate with the teams where possible to allow for impromptu discussions
- Consult knowledge-workers and involve them in your dilemmas
- Lay the foundation for a culture which welcomes failure and forgives mistakes
Getting the first two points right will get you a long way, however, without a culture which celebrates failure, you’ll likely only hear what people want you to hear, ie. what’s going well. You only need to scan your Instagram feed with its once-in-a-lifetime mountain treks, chilled beach hangouts with cocktails, and impossible physical feats to know that it's human nature. It’s important therefore to continually work at this, so that people are equally inclined to share what went wrong. If not on Instagram, at least in the workplace!
This is of course easier said than done, however things will inevitably go wrong and people will make mistakes. A popular approach to making the subject of failure more approachable, is so-called “Failure Fridays”. This could be a get together over a coffee and a cake, where war-stories of failure are shared between colleagues. Or it could even be that you book a time on a Friday to get the team together, intentionally break your software and all work together to find the issue and solve it. These practices can help to normalize failure, so that when it happens for real, it’s just another Friday.
As I’m sure you are aware, there are no quick fixes. This is something which needs to be worked on continually and reviewed regularly to optimize your ways of working. I hope that this post has given some insights into how you can get started and helped highlight the importance of transparency for the agile organization.
If you’d like to discuss this, or agility in general in more detail over a coffee, then feel free to contact me below. It would be great to hear your thoughts!
