Windows Embedded Home
Windows Embedded 8 Family
Windows Embedded 7 Family
Other Windows Embedded Products
Posted By Phillip CaveSoftware Development Engineer
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.
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:
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:
An Agile delivery model calls our work “user stories” or “stories” for short. Think of the above as types of stories.
So there are the product experiences to deliver and there are also activities we have to do in order to deliver those experiences. I will write about activities in a future blog.
Infrastructure stories are the things we often need to do around or about our work. Think of them perhaps as “meta-stories” or “meta-work”; work that we must do in order to accomplish our goals. In Lean thinking this is our setup activity; activity or things we must do in order to accomplish our goal of delivering customer experiences.
We would like to minimize infrastructure stories. We want to make this work as efficient as possible. Creating a standard work approach (think checklists, managing lead time, and entrance/exit criteria) helps us make this as efficient as possible.
Some examples of infrastructure stories are:
Discovery stories are the stories we create when we don’t know exactly what to do. We know we want or need to do something but we are uncertain how something works or how to approach it. In my old Xtreme Programming days we would call this a spike or discovery time; while at a startup delivering a new product with a new technology stack we would spend a limited amount of time (time box) learning and deciding on an approach. The outcome or result of working on discover stories is a decision. We are either going to do nothing or do something. That something is either decide to spend a little more time discovering or documenting the next steps on narrowing our discovery or ideally create an implementation story. The goal for discovery stories is to create an actionable next step. Doing nothing is just as viable as doing something. The point is, limit the amount of time spent in discovering. As an engineer, I could spend weeks just playing around in the code, it really is a lot of fun; the goal is to be structured AND goal oriented.
Typically we create discovery stories around interfaces. When we do not know how a particular API works or we need to discover the behavior of something.
Some examples of why we would create discovery stories are:
Implementation stories are the typical ones all Agile literature discusses. These are the ones we communicate when we are creating an interface or user experience.
Next time I will write on visibility.