Posted By Phillip Cave
Software Development Engineer
The introduction to this series on Embedded Agility summarized the transition and ongoing transformation of Windows Embedded to a delivery model based on 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
We generally have enough work to do, so focus on finishing work in process before adding more work. The focus for releasing product is to complete user stories. Having a lot of stories started minimizes our effectiveness to complete them.
If this means having two team members working on one user story to complete it, then do that. Just because we have eight team members does not mean we start eight user stories. Think about applying our focus to finishing the work, not being busy. We can look very busy but get absolutely nothing done.
Often we think that we are efficiently utilizing team members by keeping them busy on their own user stories. When delivering product, the goal is to be in a ship ready state as soon as possible to recognize the pent up value associated with the user stories. We can be “efficient” with people and we can be efficient with the product release. Can we do both? What is more important? What should we do?
I can’t say this enough: focus on the flow of the work. Like all things there is a benefit and a cost to our activity. Often we may look at the “logical” view of being efficient with people but not look at the cost associated with having too much work in process. This discourse about efficiency is best served with another blog post.
Too much work in process slows the work down and creates “wait states” for lack of focus; too little work in process creates a wait state for team members. Balance is the key. I started this series with defining and visualizing our work. Visualization helps us find that balance in the flow of work.
Managing work in process then is about visualizing where our scenarios and stories are in their life cycle, correcting and adjusting the flow of that work to ensure we focus and deliver value quickly and not overload the team.
If we see that a bunch of stories are piling up in front of a specialty resource or QA or Content Publishing we can do something about it. The work is not done until it is all done. There is no “my work is done.” Yes, your major activity or contribution may have pushed the work along, but the entire scrum team is responsible for getting to “done, done” (a future blog entry).
Define the work (scenarios and user stories), make it visible, allow visibility to manage the constraints and capabilities of the team and make good decisions because we can see and manage the work in process to do our part in finishing things before starting new things.
Managing work in process then allows us to see where we are inefficient in getting things done and become more efficient at completing things.