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
Simplicity. Why do we, in general, get so hung up on getting stuff done?
There are a few things that I wish everyone could experience. One of them is driving on the autobahn in a Porsche 911 at over 200km/hour (or, if you are like my colleague Dave Kelley, an Audi R8). If that wish came true, then I would not be stuck behind slow drivers in the fast lane. Just because the speed limit “suggests” 65 or 75 does not mean I want to be behind you wishing you would stop hogging the far-left passing lane. (The key word is PASSING, and I mean pass within the next hundred feet, NOT miles; pass and move over, don’t police me. Thus, I love the autobahn. Germans know how to drive.)
Another wish is for all people in the software world to experience living and succeeding at a product company startup.
Comments Windows Embedded Standard
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.
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.
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
Last month I provided an overview of Agile software development in Windows Embedded and set the table for some great follow-up posts. In this post I dive deeper into defining work and the value of making it visible.
Last time I wrote on defining small customer experiences. This post discusses what to do with all those experiences we define. This is our “work” to do. Our ability to deliver on that work is greatly enhanced when we understand and see it.
I am breaking this blog into two portions. I first need to describe the “work” we need to make visible. The second portion of this will discuss visibility and activities. Typically we only think of scenarios and user based stories. In software projects “work” may be defined within three areas: