Posted By Phillip Cave
Software Development Engineer
[UPDATE from J.T. (7/30/12) – Phil has now become a blogger on the site and I’ve moved this post to his page]
Last year a small part of the Windows Embedded team began using Agile software practices to improve their quality and productivity. Their experience was so successful that over the last 6 months, the entire Windows Embedded organization has been moving away from the traditional waterfall development process and moving toward an Agile model. It hasn’t been without its bumps along the way, but I’ve really enjoyed the change in mindset and approach within the team.
In this post, we hear from Principal Program Manager Phillip Cave, who has spent years practicing Agile and acting as a consultant for those trying to transition to Agile. When Phil’s not moving folks toward Scrum, Kanban, or other Lean methodologies, he enjoys sharing stories at conferences such as Agile West. Phil has consulted at Microsoft and many other organizations large and small for the past 8 years. He has a passion for helping others see the pragmatic application of Lean thinking and recognizes that successful transformations are carried out by teams that see the opportunity and embrace change. When not following his passion to help teams, Phil enjoys the beauty of the Pacific Northwest with a variety of activity from rowing crew to hiking the back country.
This is just the first of a series of blog posts on Agile. For each of the headings below, Phil will spend some more time in the future fleshing them out and giving us more detail.
Company transformations take time and energy. People are asked to move from one location to another intellectually. Moving is not always easy for some. Some love to move, to explore, to try new things, the author of this blog entry falls into that camp; others not so much and still more others are ambivalent.
This is the (short) story of the transformation taking place in the Windows Embedded group within Microsoft. The journey began as all journeys do; someone spoke up about not being satisfied with the status quo in the delivery of product solutions. Our ability to respond to the changing market place and the changing landscape in technology towards devices makes us think of how we deliver business value quickly. People with experience in the transformation heard that voice and thus the transformation was born. A consultant with experience was hired and combined with the internal team members the transformation took root.
The transformation approach within Windows Embedded took one of the product teams, Windows Embedded Device Manager (WEDM) on the initial journey. This pilot product team of four feature crews had already started with requirements so we reset the team just before they began execution.
Transformations need to be about creating momentum and positive outcomes. I am sharing this story below from one of the DEV team members on this initial pilot team.
…My experience was so completely different from any other software releases that I’ve been a part of at Microsoft over the last nine years (seven ship-it awards) that I thought it worth conveying this story. What was remarkable about our M1 release wasn’t so much what it was like, but what it wasn’t like. Our last day of M1 was just like every other day of M1. An outside observer wouldn’t have known that we had reached a major milestone at all. What was missing was the death march to the end and the last minute show stopper bugs that also kill morale. The impossibly huge pile of unresolved bugs that usually accompanies the completion of a milestone, and also provides a pessimistic measure of quality, was also missing. … The best part of the whole experience is that at the end of the milestone we were DONE! Not, “we are done, but there’s a whole bunch of stuff we didn’t get to do.” Or, “it’s done but we will have to address the quality issues in the SP.” Or my favorite, “it’s done but I hope the customer doesn’t use it too hard.” No for us the product we delivered in the first milestone is done, done and done. We will not need to revisit it in the next milestone, which when we complete that will just as done as M1 is.
What this experience story speaks to is a simple approach that takes a lot of dedication and team work from the execution teams. Success with any transformation is seen with the team members following some simple principles that take a lot of work to practice (please note that it is the teams that make this successful):
- Define small customer based experiences (user stories)
- Make all these visible within the execution process in which they are delivered
- Manage the work in process of those stories
Define small experiences
The first principle has a profound implication on flipping our approach from technology layers to business value slices of functionality. Instead of creating a very large batch of user stories and treating them as if they are exactly the same, defining these customer experiences requires communicating in terms of the business and customer terms and value; and then delivering those slices of business functionality incrementally.
Make all work visible
The second principle creates an environment of team based accountability and allows us to tangibly see our work in order to:
- Expose risk
- Manage and communicate dependencies
- Creates a unique team psychology of responsibility because they can see the work
Manage work in process
The third principle empowers the team to make decision about their work and to communicate what is working and not working within the delivery model. Manage the work in process allows us to understand and take action. Some of that understanding is seen in:
- Creating flow of the user stores to incrementally deliver value(more will be communicated on this in a future blog)
- Manage process blockages and team capabilities
- Manage expectations on what value is currently in process and how long it takes to deliver at a business value level
Windows Embedded is continuing on this journey with the remaining product teams. The approach to transform the reaming organization will use the same principles. The key however is to recognize that the how we apply these very good principles must change based on the dynamic of the people in these product teams…and that is the key. Recognize the differences in the teams and approach them where they are in applying the principles in a way that they will be successful in their application.
It’s the Agile West conference this week. Be sure to check it out and learn more about Agile from experts all over the industry, including Phil who is giving a talk on Thursday.