Overcoming Software Impediments Using Obstacle Boards

Life is full of obstacles. Irrespective of whether the feat belongs to our school, work or home life, there’s bound to be a few blockers along the way. If every desire or achievement came easily, life would be rather dull and unfulfilling. While we can’t always get what we want, jumping a few hurdles builds us up better than having everything handed to us on a silver platter.

Software engineers regularly overcome hurdles in the building of new products.

Software development is no different from life. Regardless of the process and technologies utilised, teams will encounter issues. My personal view is that remediation of these blockers makes building software one of the most challenging and fulfilling pursuits. There is nothing more satisfying than solving an issue that has been plaguing your progress. However, in order to achieve that dizzying high, we must first identify and then remove the obstruction.

Back in 2019, the buildout of a new product required some experimentation in how we managed impediments. The team was struggling with unfinished work. This was due to parallel efforts to compare the new product to an existing system to validate its accuracy. It was this specific issue that inspired us to experiment with using an Obstacle Board to visualise and track problems.

While I’ve found many useful resources describing what Obstacle Boards are, and how to create them in particular tools, people’s experiences of using them seem to be less forthcoming. In this article, I ponder the successes and challenges of adopting our first Obstacle Board. I will discuss how we integrated the board into our practice, and provide some useful tips on how you can apply the lessons we learned into your own implementation.

What Is an Obstacle Board?

The first question you may be asking yourself is: what is an Obstacle Board? I have certainly found that almost everyone has some knowledge of storyboards for visualising the state of items under development. Particularly if you come from a Scrum or Kanban background, the below storyboard example may be familiar.

I’ve found that the same Agile communities are often less familiar with Obstacle Boards, including myself at one point in time. To get started, do check out the below resources from others. I found each of these particularly useful for getting started.

Obstacle, Begone! – Aaron Sanders, This Agile Guy

Obstacle Boards in Agile? – Judicael Paquet, My Agile Partner

Visualise Problems With a Board – Johanna Rothman, Create Your Successful Agile Project

Quite simply, it’s a twist on the usual storyboard that the majority of Scrum and Kanban teams use. An example is presented below.

As you can see, just like the above storyboard, we have swimlanes to show the state of a given impediment. Our example has a simple three-stage process, however there is no reason you couldn’t add further transitions if they make sense to your own work practices. Items progress from left to right as they are eliminated. You also have the notion of ownership, where the team member owning the resolution of the blocker can be assigned a given obstacle. A sample workflow that we used with our own board is presented below to help illustrate how the swimlanes can work along with ownership and integration with storyboards.

The above mechanism isn’t restricted to workflow management tools such as Jira or Trello. While we used Jira in our own case, there is no reason you can’t have fun using a physical board with post-its within your own office environment if preferred. Irrespective of whether it is physical or virtual, an Obstacle Board provides visibility to the state of any impediments to your current work.

What Is an Obstacle?

The next question on everyone’s lips is normally what is an obstacle? This is an interesting idea in itself as engineers perceive a blocker to be an issue that means they are not able to make any progress on an item. Snags that slow them down are not considered to be impediments, as they are still advancing towards their goal. Indeed, Ben Linders covers this in his book on impediment management by pointing out that impediments that slow you down are harder to identify than those that force you to perform an emergency stop.

A common understanding of what constitutes a blocker also needs to be agreed upon when adopting Obstacle Boards. Furthermore, it needs to help you identify those tricky-to-spot slowing impediments before they become bigger and force you to halt completely.

Use Case

Let me tell you the story of how we came to use our first Obstacle Board. The team I was part of was responsible for building out a new system intended to replace a system that had been live for many years. In addition to the usual Scrum master, product owner and developer roles, we also had support from three business analysts who would perform daily validation checks comparing the old and new system. Given this was a financial product, you can imagine ensuring the population is accurate was imperative to the successful adoption of the product by the client base.

The specific problem that the team was encountering was that they were consistently struggling with unfinished work items at the end of every sprint. It was becoming a regular pattern to discuss these concerns during retrospectives. However, when probed further, the team acknowledged that unplanned work was derailing development efforts on the stories we committed to deliver within the sprint. The main cause of the slowdown stemmed from the checks between the old and new system. Whenever a discrepancy was found, the business analysts would request help from engineers to identify what was driving a given difference. And given the age and complexity of the original system, coupled with the inexperience of engineers in working with the old system, this often took considerable time.

Given the importance of system accuracy, it was clear we needed to track the impediments more effectively. Initial tracking measures attempted by the business analysts included Excel spreadsheets and email threads. However, these mechanisms failed for a couple of reasons.

Firstly, tracking of the state of common themes emerging from multiple investigations became challenging. The Excel sheet revisions being sent out daily resulted in many duplicate items being created when the same issue was encountered. These duplicates proved difficult to identify and close, especially if the same root cause contributed to different examples raised on different days.

Secondly, investigation progress was all but invisible as we could not identify when issues were being investigated, and by whom. Engineers don’t monitor their email constantly to reply to update requests. If they did, I would certainly expect a reduced productivity rate as they’ll spend less time engrossed in their favourite IDE, and more time updating these impediments in e-mail or Excel instead. We may work in a financial institution, but engineers don’t spend all day in Excel!

As these investigations did not explicitly relate to new features requested by stakeholders, the subsequent investigation efforts that developers were expelling, and the time it took given their inexperience, came under the definition of a blocker rather than a story. This made them impediments to team progress. We wanted to specifically track the state of accuracy just as we would with the state of stories. Therefore, we decided to try using an Obstacle Board to visualise these impediments. On reflection, they could have been tracked by adapting our existing storyboard to include obstacles, as suggested by Judicael Paquet in Obstacle Board in Agile?. In all honesty, we didn’t consider this approach at the time. Despite not considering using a combined board, a separate board was thought to solve the initial problem of tracking the state of accuracy in the platform.

Before adding an Obstacle Board to our process, it was important to provide education to both developers, business analysts and the product owner. Not only is this required to explain the concept, it can help justify why it should be introduced, and facilitate discussion on if and how the team would like to use this technique. The resources provided above were vital in educating not only myself, but the other squad members and stakeholders too.

Measuring Effectiveness

Once this squad agreed to use the Obstacle Board for tracking these data mismatch investigations, we set the parameters of the experiment. We restricted our definition of an impediment to just these investigations due to the high focus on accuracy by key stakeholders. Since the team was still working on stories in parallel, we also defined the proportion of sprint capacity that we would use to address these obstacles. This was achieved by allocating a portion of points per sprint. This was adjusted over time as we learned more about our rhythm, but it didn’t typically go above 40% of our committed velocity.

Effectiveness was to be measured by tracking the number of obstacles raised per week, along with the number resolved. This was relatively easy to extract from Jira as the tool tracks created and resolution dates for each item.

My hypothesis was that the number of obstacles raised would deplete over time, and that the team would be able to resolve the same number. Looking at these results in the below graph, it is clear to see that we indeed are raising less obstacles over time, partially down to the large initial spike when we inserted known impediments to the board. I was happy to see the portion of one month where no new obstacles were raised. Yet the developers didn’t resolve all items in the large initial spike. They did resolve items as others were raised after the fact. Nevertheless, by not continuing to investigate issues in the period between, they affected the resolution rate greatly.

The same data extracted from Jira could also be used to calculate the resolution time. Some key statistics gathered for the duration of the experiment are presented in the below table. Note that small obstacles can have a quick turnover time in a matter of hours, as per our minimum duration. However, without collective diligence they can remain open for some time, as we can see from the other statistics.

Another metric under evaluation was collective burndown. As the aim of the Obstacle Board was to visualise impediments to story development, and allow them to be eliminated, one would hope that we would complete a larger portion of our committed story points. As depicted in the below sample visualisation, we have pushed closer to completing all stories in the sprint.

It is clear from the longer vertical transitions that stories were taking longer to progress to a completed state. I expect that this is most likely down to us continuing to undertake parallel work in the form of these development obstacles. The switch between investigations and story development could be interrupting developer flow on both work types. Furthermore, although we have allocated a portion of capacity to try and help us finish our committed story work as well, I believe by looking at the created and resolved chart presented above that perhaps we should have started with a higher allocation of capacity to work on addressing our impediments.

From a more qualitative standpoint, the board has proven to be a success. Both the product owner and business analysts commented that the state of investigations is more transparent. By explicitly assigning an investigation to themselves and moving an impediment to the in-progress state, just like any development task, developers are easily communicating to all stakeholders that a given obstacle is being addressed. Furthermore, if clarifications are required, the same item can be assigned back to a business analyst or the product owner to receive further details. 

Another added bonus that we found was that blockers can be easily converted into stories where development is required. Impediments could also be linked together in the event that pitfalls originated from the same root cause. This was down to our decision to house the Obstacle Board in the same tool as our Scrum storyboard. With obstacle and story items being present on the same Jira project, we could change the item type from Obstacle to Story to allow it to transition onto the product backlog with little effort. Furthermore, as details of the investigation and the developer findings were documented on the ticket, all that information was carried with the story and could assist with the writing of acceptance criteria and even planning and task identification efforts.

Developers are also reaping the benefits as they are better able to manage these investigations with other tasks. Over time, as they spent more time on the old system codebase, they have obtained useful knowledge in how the old system works. This helped them to generate a form of muscle memory that later resulted in them being able to identify recurrences of the same issue, therefore reducing the amount of time spent on addressing these blockers.

Reflections

The initial accomplishments reaped in the use of our first Obstacle Board were great. However, over time we learned that maintaining the same approach was quite challenging. This particular team actually stopped using the board 3 ½ months after starting the experiment. Reflecting on this stoppage, I would definitely consider changing a few aspects of how we used the board at that time to help it better integrate itself as a permanent feature of our practice, and to educate others hoping to follow in our footsteps.

Firstly, while we could see from the previous burndown illustration that the proportion of completed to committed stories is veering towards 100%, we didn’t reach that point within the experiment timeframe. The most likely reason for this was that we didn’t get that initial work balance of stories to obstacles right. Just like teams will use their prior sprint velocity, or perhaps an average in their sprint planning activities, so too should we have tried to better track the time taken on obstacles to adjust that ratio.

Secondly, while in this experiment we fixed the definition of an obstacle to be these data validation issues, this proved to impact the longevity of the board usage. As any team grows and develops over time, what causes them to slow down evolves. If you do not revisit the causes of what slows you down regularly, you may not think of those new blockers as obstacles. The first squad stopped using the board when they no longer had to perform investigations into the old and new tool because their definition of an obstacle was fixed to only those items. Just like any definition of ready or done that the team may leverage, they should also regularly revisit their definition of impediments too to ensure new items are also tracked on the Obstacle Board.

Board overload was a concern raised by some other teams when we attempted to expand adoption to other teams within the same area. One IT manager professed the desire to have one board to rule them all. In our use case, having impediments separated from stories was touted as a great way to track the state of accuracy in the system we were building out. Initially, upon receiving this feedback I was reluctant to try merging obstacles and stories together. I thought that coveting a single precious board was far too limiting given our experience. Different audiences want a different view of the state, be it precise development steps or a more high-level “is it ready yet”. 

For audiences wanting a single view of the world, there is no reason impediments and stories can’t live on one board in harmony. The same idea was raised by Judicael Paquet in his piece Obstacle Board in Agile?, which was discussed earlier. Although his point is specifically in reference to Kanban boards, I suggest that the idea is also applicable to Scrum practice. Since this initial experiment, I have moved to a new team that has found tracking major impediments as obstacles on the same board to be helpful for calling attention to issues. So I’m now convinced that having one board to rule them all can be the right solution in some cases.

Another recommendation that I would suggest going forward is including usage of any Obstacle Board or general impediment strategy in your team norms. I’ve heard team norms go by many different names, such as working agreements and team charters. I assume there are other names as well. However, if this term is new to you, it is a set of common principles that the team collectively agrees to work by. Regardless of whether you are working together in the same office, or scattered remotely across the world, it is important to outline how you want to work together. Stating you intend to use an Obstacle Board, and your evolving definition of an obstacle is a good start. However, many of the reflections I’ve outlined here would also be welcome additions.

Conclusions

I have yet to encounter a team that never encountered any issues while building out new software. Obstacle Boards are a mechanism that provides visibility of the issues teams face as they progress. They can be used to foster open communication of issues, provide a psychologically safe space in which to raise these problems, and help teams collaborate to eliminate obstacles together.

It’s important to note that blanket enforcement across all squads should not be the goal.  Mandating tools and techniques removes the flexibility and team empowerment that Agile adoption is meant to provide us. Use Obstacle Boards when they can provide a benefit. Do not adopt them as the silver bullet to solve all issues. Like any technique used in Agile practice, it should grow organically as teams learn and grow.

About the Author

Carly Richmond is a lead software engineer and Scrum master at Morgan Stanley. When she is not working on building financial systems, she contributes her thoughts on agility, UI, UX and technology in general. She also loves cooking, photography, and drinking copious amounts of tea.