Posted By Phillip Cave
Software Development Engineer
Last time I presented the first part of this post. In this post I dive deeper into making work visible and discuss the pragmatic application of it.
The introduction to this series on “Embedded Agility” summarized the transition and ongoing transformation of Windows Embedded to a delivery model based in Lean thinking. That first post outlined 3 basic tenets:
- Define small customer based experiences (user stories)
- Make all these experiences visible within the execution process in which they are delivered
- Manage the work in process of those experiences
Now that we have our worked defined (infrastructure, discovery, implementation), our goal is to make it all visible.
There is an amazing psychology around visualizing and making our work tangible. I will go into small detail about how our senses (sight and touch) play a part in this. Suffice it to say when we make our work visible we tend to take on a different level of responsibility for it and our decision making is affected by it in a positive way.
Our world is composed of “bits”. The experience we deliver to customers is the culmination of the assembly of a lot of bits. Our customers do not care about the bits, they care about the experience. Our customers do not care about our roles of who works on those bits; they care about getting the experience in a timely fashion. Our business relies on us to complete our bits quickly in order to realize the cash flow and tangible value associated with those bits.
Similarly our work does not care who works on it, it just cares about getting done (yes I am personifying our “work”, on purpose, read on). Our work does not care about your title, it just cares that it gets completed with quality.
We see and work with lines of code, our customers and business see what our lines of code can enable – experiences. When we tie our bits to experiences we communicate in a common language. We call this collection of bits into a common experience as a “user story”.
It is these user stories we make visible. User stories become our work product on our “assembly line”.
When any team member of Ford walks into the production line for the Edge, they witness a continuous moving line of raw material into a tangible, consumable product. When Ford visits Windows Embedded they see people at desks typing away furiously or at a test bench reviewing product functionality. Good activity to be sure but our Ford visitor would have no idea what we are working on, how we are making progress and if we have an issue against making progress.
We have options when visualizing our work. Here in Windows Embedded we cover the walls with our user stories to focus our attention on the most important things and monitor our work.. We do this to focus on our work in process and rally around completing our most important stories before starting new ones.
Making our work tangible and visible creates an environment of team accountability and urgency. We literally transform our “bits” into an object we interact with from a customer perspective.
My current work with the Windows Embedded Automotive phone team allows the entire team to see the outstanding items remaining before we are ship-ready. We can track and discuss our user experiences around pairing and connecting a phone to the Sync device and rally around items as a team. Making the work visible creates an appropriate sense of urgency and priority around our work.
A final note (in this blog) about making work visible: create visibility around the globe. Windows Embedded teams use an internal tool (and soon the next version of TFS) to visualize our work with distributed teams. This tool here at Microsoft integrates with Team Foundation Server to track our work items.
One strategy I have used very successfully is to replicate the scrum boards across the globe with distributed teams regardless if I have a tool at my disposal.
I used a tool like the above and a daily coordination meeting to keep the physical boards in sync across the globe. You might ask why I go through this effort. I do so for the same reasons; to foster the psychology around visualizing our work with the entire team.
Visualizing our work has value in many ways:
- It mimics what our partners at Ford see every day
- It creates a common language based on user experiences
- It shows work in progress that allows us to focus and raise issues quickly
- It creates trust with our partners and our distributed teams
Next time I will finish this series with a look at managing work in process.