I rolled out the new 2-day “Flow 101” workshop last week to 24 folks working at a financial services company near Austin. Notable in a couple of ways: 1) Two VP’s attended and 2) Three attendees from three different teams (the team of three), worked together to design a board to visualize the workflow across five different teams.

Usually, if a VP shows up at all, it’s only to introduce me before heading off to their triple booked calendar. That two VP’s took the time to participate in the workshop exercises with their teams signaled their desire and support for change. It’s much easier (if not essential) for people to improve flow knowing that leadership has their back. This author defines flow as “work pulled through a system smoothly and predictably.”

Usually, individual teams stay in their own groups and design only their teams work board. That people from three different teams collaborated on the exercises signaled a level of maturity of how important is to make the end-to-end workflow visible. It’s easier to see the bottlenecks in the system and achieve smoother flow when handoffs between different teams are visible. Improving flow requires a mindset shift. A shift that DevOps is influencing to view work flowing across the whole system (making flow time measurable) versus a narrow focus on small siloed teams.

During an exercise early on day one, the “team of three” identified four problems from the business perspective.

1. Not fast enough
2. Don’t know status
3. Unknown problems impact delivery
4. Low throughput

This led to the desire for this group to create a board that would allow them to capture the actual speed (flow time) of the work and visualize the status of their work – including handoffs of the work between the five teams (Maintenance team, Client implementation team (new clients), Core systems team, SQA team, and UAT (a business team). The team of three included representatives from: DEV, SQA and Maintenance. When it comes to improving the “Not fast enough” problem, one must discover how long things actually take to do — end-to-end.

Instead of creating three separate team boards, the team of three included work from five different teams on one board. This will make work status visible (including handoffs) and put them in a good position to measure their flow time (the elapsed time work takes to move from beginning to end), that would otherwise be invisible due to the siloed nature of the teams.

The “Ready” columns serve as wait states for between teams. Work sitting in “Ready SQA” is the handoff between DEV and SQA. Work sitting in “Ready for Prod” is the handoff between UAT and Implement. I’m curious to learn what the criteria is for moving work from “Review” to “User test”. The colorful cards on the board represent the different project work-in-progress.

This approach should help them address the “Not fast enough” problem as they will be able to measure the flow time from when DEV is first assigned the work to when the business value delivered to external customers, including any wait time due to handoffs between teams. They’ll have visibility on an important section of their value stream.

Because people should be involved in the design of the board that manages their work, I asked the team of three what their strategy was for getting buy-in from the other two teams. Their plan is to set up a prototype physical board of their initial design and invite the others to review it.  They plan to train other team members on the process. They expect to have some wins and believe the others will want to join the fun.

I’m excited to hear how it goes and to see pics of their “big” board during our workshop follow-up call. More in a few weeks!