Agile for Embedded Part I

I have used a number of development techniques in my career and, most recently, have taken up Agile Development as a means of rapidly building systems. However, Agile's heritage is in the development of web sites and I am currently interested in the development of embedded systems. The differences between these two require some modifications to the basic Agile techniques. I plan to publish a series of posts that describe the changes I would use.
This post is concerned with User Stories.
A User Story is a simple way of capturing the requirements of a system. It has many similarities to the Use Case as defined in UML. Both define requirements based on a consistent outside-in perspective from a User to the System.

The User Story is a single sentence in the form
As a [user role] , I can [feature] ,so that [benefit] .
Instead of the generic "user", the user role tries to identify different classes of users with different requirements. User is too generic. But Tom, Sally, Harry are too specific. When we see that Tom and Sally are customers and Harry is the administrator then the roles of Customer and Administrator emerge with separate interfaces, transactions, and requirements.
The feature  is what I want to accomplish with the system as the User Role.
And benefit; is why I want to use that feature. What value do I get from the story.

Suppose we are building Amazon.com. Then we might see user stories like:

As a Customer, I can search for something, so that I find the item I am looking for.
As a Customer, I can select an item from a results list to get more details, so I can decide if I want to buy it.
As a Merchant, I can register my business as an Amazon storefront, so I can sell my products.

So the catch with an embedded system is that the rich interaction with Users is not always present. In a "headless" system with no user interface, the embedded system depends on sensors to modify its behavior and will often send outputs to actuators. Let us imagine a thermostat as the system. I may have a simple user interface so that the homeowner can:

As a homeowner, I can change the mode of the HVAC between Off, Heat, and Cool, so that the house is maintained at the temperature I want.
As a homeowner, I can change the temperature limits, so that the house is maintained at the temperature I want.

A simple context diagram for the thermostat is shown below

The "Commands" shown on the diagram are for mode control and temp control, and map cleanly to the two user stories. But what about the "Display"? Unlike a web site where the user takes an explicit action of clicking on a link to see a new page, the display on a thermostat is always there. Or is it? That is what the Battery is doing on a diagram. Remember what the display looks like without the battery inserted? Blank. Insert the battery and the display comes on (usually showing default information) and stays on until the battery runs out of power. One could imagine a user story like

As the homeowner, I can insert a battery, so my thermostat will turn on and maintain my house temperature.

But what about the Thermocouple that provides the "Current Temp"? We use that to compare to the Mode and Set Point so that the Thermostat can tell the HVAC to turn on or turn off.

There is no natural user story involving the homeowner and the thermocouple.

My idea is to add event modeling as defined by Paul Ward and Stephen Mellor. An event is something that occurs at some point in time in the environment of a system and, for which the system should have a response.
This could also apply to the users but I think the user story format is fine for that. Below is a table that captures some of the events for this system

Battery inserted
Battery runs low
HVAC begins heating
HVAC begins cooling
HVAC stops heating
HVAC stops cooling
Temperature fluctuates

When the battery is inserted and when the battery runs low can both be determined by measuring the voltage.
We are not interested in the current voltage at anytime just these two events.

The diagram below shows the modes of the HVAC

This is a basic state diagram. If the behavior of our system will be different depending on what mode (i.e. state) it is in then using such a diagram helps separate the behavior and to better understand what would trigger the system to change states. For example the event of HVAC begins heating could occur when the system is Off. It should not occur when the HVAC is already cooling. Many events are important because they help us organize these modalities.

Finally, the Current Temperature that fluctuates is a special kind of event. The temperature always exists and has a value that the system wants to measure to determine if it should be heating or cooling and it wants to display the current temperature to the homeowner.

Events (like user stories) are intentionally abstract. As the response to the event is being analyzed one must answer how we will determine that the event has occurred. We must focus on the system boundary and look at the interfaces. Sometimes these interfaces are constrained. For example, suppose the HVAC manufacturers have gotten together and decided on a specific interface standard for status/controls. They might dictate the HVAC Status would be conveyed by a twisted pair wire with +5 volts indicating Heating, -5 volts indicating Cooling, and 0 volts indicating Off. So our thermostat could monitor the voltage and detect when the four events occurred.

So lets put this together in a user story / event table as shown below.

Conclusions
By adding events to user stories, I have introduced a means to capture requirements for embedded systems that do not have significant behavior at the human interface. This is consistent with the general approach of agile development because:

• The event/response/benefit complexity is similar to the user story and can be treated in a similar fashion in SCRUM
• The events have an outside-in perspective similar to the user story. This avoids "the system shall" type of requirement.

Stay tuned for Part II (Can Hardware be designed from User Stories / Events?)

Jeff Sutherland's Pearls

Last week I attend an Agile RTP meetup hosted at the offices of Relevance Software . I heard Jeff Sutherland speak about the "Five Problems solved for PatientKeeper". If you are into Agile then for me to repeat what he said would be redundant, and if you are new to Agile then you probably need some basic education before jumping into his talk.

However, I captured the following pithy quotations from Jeff:




1. "World domination always gets people excited". When the PatientKeeper management team was forming the company, they needed a vision of what PatientKeeper would be when grown-up. Jeff speculated that Bill Gates had a vision of owning the PC desktop. Sooo... the PatientKeeper team decided to own the mobile devices used by clinical professionals. They wanted to create a framework that would be considered the gold standard for third party medical application developers.

2. "If it is impossible show me the impediment list". Attributed to the CEO who took over PatientKeeper in 2003 and wanted the code deployed to hospitals after each Sprint. When told that the installation time was a bottleneck to this tempo, he formed the "Live by Five" program, which brought in PatientKeeper expert services to work with the hospital IT staff to make sure the installation took place by 5:00 the day of install.

3. "If Lean is all about removing waste, then SCRUM is all about removing impediments". Jeff likes to teach Lean Manufacturing to executives trying to adopt agile development because he believes that they can relate to the examples from the world of manufacturing.

4. "Is the Tango a methodology? Neither is agile". Someone in the audience asked Jeff to compare the light-weight "method" of agile with a bureaucratically heavy approach like CMMI. Using the analogy to the Tango, Jeff said that like that dance, the Agilista does not plan so much but responds to the circumstances of the project.

Learning from Mistakes

I attended a brown bag conference call hosted by the Industrial Research Institute on the topic of "Learn from New Product Failures". Our speaker was Jim Hlavacek, one of the authors of the paper by that name published in Research-Technology-Management. They have had experience in reviewing failed projects at manufacturing companies based on techniques used in the medical profession. In many teaching hospitals, when there is an adverse patient outcome to treatment, the clinical team undergoes a Mortality and Morbidity Conference, where the course of treatment is reviewed by an objective team and mistakes identified.

Hlavacek reported experiences at companies like Intuit, Toyota, and 3M where a regular process of review is built into the engineering/marketing culture.

Under Hlavacek's approch the Failed Product Review (FPR) would consist of the following:

Background

Name of the failed venture

Dates project began and was terminated or shelved

New Venture leader and cross-functional team members

Objective and qualified principal investigators

Inputs

Face-to-face interviews with people who were particpants on the project

Face-to-face interviews with OEM and end-use customers who were involved

Face-to-face interviews with distributors/dealers and/or key suppliers

Obtain all e-mails, business plans, documents, trials, and project presentations

Methodology

Develop timelines and milestones of critical events or decisions

Doucment the unfavorable outcomes with data

Develop fishbone diagrams for the project and processes

Develop root-cause analysis of the fishbone diagrams

Recommendations

What went well for the project

What went wrong for the project
Lessions learned and corrective actions

This approach to learning from mistakes reminded me of some similar approaches I am familiar with. Those of you with a military background may have participated in an After Action Review. This is used primarily during training exercises to understand what happened, evaluate everyones performance, and discuss what could be done better. From the USArmy manual comes a similar outline for an AAR:

Introduction and rules

Review of objectives and intent

Training objectives

Commanders mission/intent

OPFOR commander's mission/intent

Relevant doctrine, tactics, techniques, and procedures

Summary of recent events (what happened)

Discussion of key issues

Chronological order of events

Battlefield operating system

Key events/themes/issues

Discussion of optional issues

Soldier/Leader skills

Tasks to sustain/improve

Statistics

Others

Discussion of force protection (safety)

Closing Comments

The final example is from my experience as a Certified Scrum Master. Under SCRUM a small team produces a product release using a succession of short time boxed miniprojects called Sprints. Sprints typically take anywhere from 2-4 weeks for the team to produce a functional version of the product. After every Sprint the team gets together for a Restrospective Meeting. In this meeting the team discusses the following:

What worked well last Sprint that we should continue doing?

The practices that worked well during the previous Sprint should be identified and continued in the coming Sprint.

What didn’t work well last Sprint that we should stop doing?

The team or customers should identify practices that worked against the team during the last Sprint and focus on stopping those things during the next Sprint.

What should we start doing?

The team identifies practices that should be implemented during the coming Sprint that will help them work better together.

Out of this discussion comes a list of actions that the Scrum Master captures and and is responsible for implementing during the next Sprint.

So lets compare/contrast these three approaches:

1. The FPR is conducted when things go wrong. The AAR and Retrospective occur for all outcomes.
2. Both the FPR and AAR require the participation of one or more objective reviewers. The Retrospective depends on the team and, sometimes, invited guests.
3. The FPR and AAR both use detailed analysis to find root causes. The Retrospectice is more adhoc.
4. The AAR assumes that particpants will change behavior based on issues being surfaced, the FPR has a deliverable of lessons learned but no clear followup for change, and the Retrospective has a set of actions with the Scrum Master responsible for seeing they are implemented immediately.

In my opinion, the key to making any of these techniques work is to have a culture of trust surounding the proceedings where everyone understands that people make mistakes and that for the majority of participants mistakes that are surfaced will not be used to punish them. I say majority, because if the same individual is constantly exposed as making repeated mistakes and not correcting behavior then it may result in termination.

Over my career, I have participated in and led a lot of project/product reviews. Almost always, people are defensive and guarded about what happened. To set the right tone in establishing a review program executives should lead by example, being willing to have their actions reviewed and also demonstrating with their subordinates that mistakes they make are not used to influence annual appraisals.

Innovation

I have been working with a client that is improving an existing innovation program. Based on my prior work at IBM (where innovation has been a mantra for several years) and in my work on the Web2.0 phenomena I suggested that adding an external focus to the program would be a good thing. 

Examples are:

Procter & Gamble Connect+Develop

Kraft Foods Innovate with Kraft

IBM Innovation Jam

All of these have some differences but the common philosophy is that customers, suppliers, and business partners can contribute significantly to new ideas.

PLUS depending on how one manages the program the participants can feel they are "partnering" and helping to change the direction your company is taking.

Some of the challenges that must be addressed include:

Intellectual Property - P&G and Kraft encourage patent protection for the participant so that a straight forward licensing agreement can be negotiated. IBM keeps the ideas very general and uses the input more to set marketing focus.

Competitive Advantage - How much early development of products can be exposed without losing something to a competitor? Because P&G deals with specific ideas it prefers to keep the interactions 1 on 1. A participant can only see the problems P&G needs solutions for and only the ideas that he/she has submitted. IBM allows everyone to see ideas submitted but keeps the conversation at a high level.  I believe that an effective program should have tiered levels of participation. A general public forum and then an invitation only small group to take an idea further. The small group would be covered by a joint venture agreement.

Searching for Diamonds - A lot of ideas have to be evaluated in order to find the few that will be worthwhile developing into a product. Either a dedicated team of evaluators must be set up OR the community can vote for the best ideas. 

The trend is towards using the Internet to open the kimono and share innovation with a broad community.

The Perils of Prototyping

I just finished a first version of a presentation/paper on the trade offs between light weight methods and heavy methods. The light weight method is based on using an object oriented language, CRC card type discover process, and a large number of iterations between discover, build, validate. The heavy method is based on my experience with Clean room. I have not monitored enough Agile/Scrum/XP projects to capture the metrics specifically for those but it will likely fall fairly close to the OO experiences. In my Scrum Master training one of the jobs the Scrum Master performed was to insulate the smallish (4-7 developers) team from the customers. The Product Owner is the only regular contact the team has with the rest of the organization. As you can see in the paper (Go to my website and look in the papers section) my assertion is that prototypic development (and i will bet Agile as well) fails because of too many customers and developers participating in the release.

Business Inteligence

Tonight, I attended my local chapter of the Association of IT Professionals. This is a swell bunch of men and women who meet once a month to network and attend a dinner talk. This month's topic was Business Intelligence presented by Rick Styll from SAS. He is the product manager for the SAS BI portfolio. Rick covered a broad introduction to BI, the parts that struck me were the market convergence and some of his thoughts on what is coming over the horizon. As far as the convergence, he mentioned that Gartner had warned SAS a while back that there was going to be a consolidation in the market but that he had been surprised by how rapidly it had occurred. He stratified the players into four tiers:
Mega players - SAP, Oracle, Microsoft, IBM
Pure plays - SAS
Niche plays - Actuate



Some of the future trends.
Web2.0 - SAS is building a release that uses Ajax and they think a flash inerface is coming over the horizon for them.
Mobile BI - Rick says customers like the idea of a dashboard on thier Blackberry, but he does not see the use cases. In his experience, most people using SAS BI are operations types using desktops.
Visualization GUIs - new graphical formats and use of motion to present BI results.