Embedded Agility - Define Small Customer Experiences
Posted By Phillip Cave
Software Development Engineer
[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.
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:
- Define small customer based experiences (user stories)
- Make all these experiences visible within the execution process in which they are delivered
- Manage the work in process of those experiences
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.
It is these experiences (user stories) that have value and that may be tracked. It may be easier to think of these user stories as tangible physical things (metaphorically speaking they are just that). Think of these user stories as objects if that helps. The Agile world represents these user stories as index cards or a sticky note (this will be discussed in a follow-up blog).
The picture above shows two models of thinking. One focuses on the technology layers and a large batch of experiences, the other focuses on the experiences to deliver in small batches. The ultimate small batch is a batch size of one; one user story at a time. Both models require action to be taken upon the object. The question is how much and how frequently may we take action upon the object and how many objects at a given time must we take action upon. I will explain this, but first some examples of a small user experience.
Think of a travel website. A possible hierarchy of stories could be:
- I want to book my own business travel
- I want to book my hotel
- I want to book my airline travel
- I want to book a oneway trip
- I want to book a roundtrip
- I want to pick my seat
- I want to pay for my trip
- I want to pay using PayPal
- I want to pay using my AmEx
- I want to pay using my Visa
The lowest level is the small experience of which I am thinking. That small experience of itself may not be able to be released in isolation. The ability to pick a seat for instance at a RELEASE level is meaningless, however at an implementation level it holds a lot of value. The value is recognized when we can exercise our software design and get feedback that our system is working properly as well as solicit feedback from our customer(s) to ensure the experience is what they have in mind.
The Auto team building out end user experiences could have a small experience defined as:
“As a frequent user of routing in my electric vehicle, I would like a list of charging stations at my destination…”
The Industry Mobile Device team building out platform capabilities may have a small experience defined as:
“As an ISV developer I need the ability to query a device log entry by device and timestamp …”
If our goal is to deliver valuable experiences (and it is) then why do we make some experiences wait for other experiences to get feedback? Sometimes we have dependencies, sometimes we do not. The point is we make things wait, often unnecessarily so. Examine the picture again below. The systems model on the left we think it is more efficient or valuable to perform activities against a large set of customer experiences. Our focus in this thinking is on the action (or activity) instead of the object (customer experience) itself. The systems model on the right we think it is more efficient or valuable to deliver the object (customer experience) and use frequent actions (or activity) in shorter cycles to deliver those customer experiences.
I am using a simple activity model to illustrate the two systems. These are good activities to do. The question as I posed earlier is how much and how frequently must we do these activities? An Agile model based on Lean thinking teaches us that the activity is good; it is our thinking around the batch size to perform that activity that is in error.
Certainly there are costs and benefits associated with activities. Often we forget or do not think about the opportunity costs and benefits associated with the object itself. Our error is in thinking we have to do ALL the activity on ALL of the objects to be “efficient”. Shifting our thinking to the object (the user experience) and away from the action (the activity) on that object gives us options. It allows us to evaluate and break our work down based on user experiences (the feature set) and deliver the “right” set of experiences over time (think small and frequent deliveries). Thinking in terms of user experiences aligns our thinking to how our customers think. Thinking in terms of customer experiences allows us to better manage expectations around our deliveries. Delivering in terms of customer experiences allows us to generate quick feedback loops on those experiences to manage expectations. Feedback is valuable. Defining and delivering our software based on small customer experiences gives us feedback and gives us the opportunity to generate goodwill and value more frequently.
Our goal is to deliver value to our customers. Our customers find value in experiences and capabilities. Our goal then is to define and deliver our work in such a way that allows us to gather feedback on those customer experiences quickly and efficiently. Defining and delivering small customer focused experiences allows us to accomplish this. This first but crucial step in thinking about our work is the first step in creating an environment where we may achieve business agility.