Windows Embedded Home
Windows Embedded 8 Family
Windows Embedded 7 Family
Other Windows Embedded Products
ABOUT THE BLOGGER
Phillip Cave is an SDE on the Windows Embedded Automotive team. Phillip joined Windows Embedded in 2011 as a Lean/Agile consultant to begin guiding Windows Embedded on the transformation to a Lean/Agile delivery model.
Before joining Windows Embedded as an FTE in January 2012, Phillip consulted with many groups throughout Microsoft to show them how to implement Lean and Agile delivery models. Prior to consulting at Microsoft, Phillip has been fortunate to have been actively involved in applying Lean thinking to software and systems delivery within his 22 years in the software industry. He has enjoyed many roles over that time as a software engineer, project manager and executive. His career has taken him to large companies such as Electronic Data Systems and Verizon Wireless to product startups where he learned how to ship product quickly. Phillip took his variety of experiences and has been providing business and process consulting for organizations within Microsoft as well as other companies since 2007.
Phillip holds a bachelor’s degree in information systems from the University of Washington. Originally from Massachusetts, Phillip enjoys the climate and vast outdoor opportunities of the Seattle area that include hiking, rowing crew and skiing.
Posted By Phillip CaveSoftware Development Engineer
This week the extended developer (SDE) leadership team in Windows Embedded had a lively discussion around “agile” and how to foster a collaborative team effort. I followed up with the extended leadership team to help them understand some of the nuances of the transformation we are making.
The discussion was kicked off asking how we may focus working as a unit to ship product. A misunderstanding arose about specialist vs. generalist team members, how to review contribution, and an overall misconception about being flexible in an agile environment. What follows was my response to the team.
Yes, foster domain/technology specialists. Of course we should foster expertise around key areas of our product so that we may create technical leadership. Think of the system while doing so. Ensure we have redundant knowledge so that we do not constrain ourselves when delivering product.
Yes we have an HR review model to evaluate team members. However, an HR review system or rather our interpretation of an HR review system should not dictate how we deliver product.
Based on our discussion what I heard was that we are going to be evaluated based on the good things we deliver. This is as it should be. Our contribution to delivering product and the leadership on delivering product is all that matters.
Comments Windows Embedded Standard
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:
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.
Comments Intelligent Systems
[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 month Phil Cave provided us with an overview of Agile software development in Windows Embedded and set the table for some great follow-up posts. In this post Phil dives deeper into defining small customer based experiences. In my opinion, he did so masterfully and I hope you find it as insightful as I did.
This blog post begins a deeper dive into the topic of defining small experiences. This 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 to define value as they would experience it; and then delivering those slices of business functionality incrementally.
Our business partners and customers focus on the experience of the device they are using. Yes, they expect a certain acceptable performance of the device as part of that experience and that performance is in relation to the experience of using features. The road to business agility begins with understanding what is of value and what is not. This includes the software features we deliver as well as the system in which we deliver those software features. Our customers understand this and communicate this way.
We deliver experiences. We deliver capabilities to fulfill experiences. Windows Embedded creates and delivers software that does both. The Auto team directly creates user experiences when delivering the Sync product to Ford. The Cassini and Compact teams create platforms upon which others may develop experiences. The creation of those platforms provides experiences (or ability to create experiences) to our partners who use the platforms.
Examine the picture below to see a visual representation of the experiences and capabilities of which I write. The Agile world of execution labels these experiences as “user stories”. The systems model on the left represents building out our software in one large batch of experiences. The systems model on the right represents building out our software by incrementally delivering smaller batches of experiences.
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 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:
Now that we have defined our work and discussed making it visible, let’s dive into managing all that work in process.
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.