Windows Embedded Home
Windows Embedded 8 Family
Windows Embedded 7 Family
Other Windows Embedded Products
Posted By J.T. Kimbell Program Manager
Over the last two weeks you’ve had the chance to hear from our three Explorer interns and learn about them and their experiences. Now, you get to see what Meg, Colleen, and Andrew were working on all summer.
Our first day of work, over a free lunch in the beautiful Advanta campus cafe, we are given the instruction to create a Windows Store app that runs on an embedded device that showcases the capabilities and features of Windows Embedded 8. It was made very clear to us from the start that the sky is the limit and because we were given so few constraints, our Explorer pod really had the chance to reach our creative potential. However, In order to focus our creative flow, we decided to distribute a survey about technology to our friends and family. We targeted our peers with the mentality being that this younger demographic consists of the future home owners and potential users of our device. We wanted to learn what these users expect, need, and desire from technology.
After analyzing our data, and much brainstorming and collaboration, we gathered the following insights:
Comments Windows Embedded Standard
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.
Posted By J.T. KimbellProgram Manager
We continue our series of posts from Windows Embedded interns with the first of our 3 Explorer Interns that I had the privilege of coaching this summer. What’s an Explorer Intern? These interns don’t spend their whole summer in one of the three Software Development positions, but rather rotate between all of them, getting a taste for each. They’ll get the chance to come back next summer as a regular intern in the role of their choice. Below, Meg Quintero will tell you about her summer here in Seattle. To learn more about her project, check back next week for a post authored by all three Explorers.
Oh hai! My name is Meg, and I am one of the three Explorer interns on the Windows Embedded team. I am a rising junior at Harvard College concentrating in Computer Science and am contemplating a minor in Anthropology to further explore human interaction with technology. I am most recently from Havre, Montana, however, Cambridge has become more of my home. Back at Harvard, I am a soprano in the Harvard LowKeys, a contemporary co-ed a capella group, and have been singing for as long as I can remember. I enjoy biking, rollerblading, running, and pretty much anything that allows me to be outside. I am a big fan of the Red Sox and was able to attend a Red Sox vs. Mariners game and rep my team. I have been enjoying all that the Puget Sound area has to offer including incredible theater (“Rent”, “Les Miserables”, and “Turandot” were phenomenal), great shopping (Pike Place FTW), and waterfront a plenty. I also felt as if I died and went to heaven when I was handed a Samsung 9 Series Ultrabook at the Microsoft Intern Signature Event after hearing one of my favorite bands (Young The Giant) live at Gas Works Park.
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: