Embedded Agility – Make All Work Visible – Part 1

  • Article

Posted By Phillip Cave
Software 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:

  1. Define small customer based experiences (user stories)
  2. Make all these experiences visible within the execution process in which they are delivered
  3. Manage the work in process of those experiences

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:

  • Infrastructure – meta-work. (work about our work)
  • Discovery – work? (work about discovering our work)
  • Implementation – work! (do it)

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:

  • Create automated build
  • Setup customer feedback Sharepoint
  • Create high-level API architecture document

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:

  • New product development
  • Implement working prototype for Netflix on connected car device (what?! .. it could happen…just sayin’)
  • New or changing interfaces
  • Discover how to hide the startup experience of Windows 8 on our devices
  • Lack of domain knowledge
  • Discover how windows 8 implemented “marketplace”

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.

  • As a <person>, I want <some experience> so that <I may receive value from this experience>
  • As a raving fan of current movies, I would like my phone to automatically alert me when a new movie of my favorite genre is in theaters

Next time I will write on visibility.