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.

a mobile device dilemma Part II

Since last December when I shared the small family crisis caused by the way the cellular industry has conspired to keep me off of Android a couple things have changed:

• AT&T has begun to offer some good Android phones. I would seriously consider the Captivate for my use.
• Rumors of Verizon taking on the iPhone persist. If that happened I could move the family over and my wife and daughter could stay on the iPhone while I could pick and choose from a wide variety of Android devices.

However, my decision continues to be complicated by the fluid nature of the service provider landscape. Now it is the emergence of higher bandwidth networks. For most of what I do on the mobile device a solid 3G connection gets the job done. But if I could get 2-10x the bandwidth via HSPA+ or LTE then should I wait until the right Provider/Device/Price comes along on one of those networks?
Because of the financial impact of disengaging my family from 3 two year contracts on AT&T my easiest option would be to stay with them and face a simpler choice:

1. Wait until this September when I am eligible for an upgrade discount and jump on the Captivate and use 3G
2. Wait until AT&T roles out HSPA+ in early 2011 and hope there is a nice Android device able to take advantage of that network.
3. Wait until AT&T roles out LTE in 2011-12 and hope there is a nice Android device (by then it will have a 2GHz processor and an mega-mega pixel camera) able to take advantage of that network.

Obviously these three choices represent the constant agony of the early adopter... whatever is in my hand is obsolete and the nice new shiny gadget is always over the horizon. BUT that feeling is tempered by my frugal side so that I tend to upgrade about every two years. I am tending towards option 2 with some caveats:

• Since AT&T has not announced any concrete steps or devices towards HSPA+ (unlike T-mobile) I am afraid early 2011 could easily become late 2011.
• With AT&T moving off of an unlimited data plan, will HSPA+ carry a double premium? First a higher $/byte charge then 3G, and second, my natural tendency to play with the technology and do video conferencing on the device until my first monthly bill comes in (Ouch!).

Decisions Decisions.
What would you do?

Agile Team Dynamics

Last night at the Agile RTP meeting we had Don Gray speak to us on Agile Team Dynamics.

The meeting was broken down to 5 teams with each team having approximately 10 people. One person was designated as the Product Owner. Each team was given a bag of supplies and an instruction sheet for the Product Owner to give requirements to the team. My team got a bag of colored paper, tape, and pipe cleaners.

We were told to construct something that was:

• Artistic
• Tall
• Sturdy

We were given 20 minutes for the exercise. The picture shows what we created.

Then Don asked each of use to take some post-its and write down what we had contributed to the exercise.

I think my set was:

• Contributed vision of "Eiffel Tower"
• Started rolling paper into tubes
• Worked in team of two specialists Roller + Taper to create legs
• Asked other team to give us balloons

Then Don told us about the Kantor Four Player Model.

During the exercise, each of the team members was contributing in one or more of the four interactions. Don asked us to classify each of our contributions. I had thought most of mine fell into the "move" category. In fact, among all the participants, the vast majority of actions were classified as either move or follow. A few Bystand and almost no Oppose.

Don mentioned that in an Agile team setup the Scrum Master should be a bystander, allowing a self managing team to do most of the Mover type activities. I made the observation that a classic problem with many agile teams is that the Scrum Master (often being an old project manager) can not help but try to take over and "move" the sprint along. Don agreed and gave some war stories from his own experience on how this can be a problem.

Other comments from the audience pointed out that the team dynamics in our 20 minute exercise did not realistically compare with a real project having team members familiar with each other and with the political / cultural context of the company surrounding them.

My main take away for the night was that in any healthy development teams these four players can each contribute something of value and that all team members should accept the presence of these roles in the team dynamics.

Meeting Fred Brooks

Last night I met Fred Brooks.

I was moderating a panel discussion of our local chapter of the IEEE Computer Society. It was about "Practical Software Development".

Afterwards, an older gentleman walked up to sign our registration sheet and apologized for joining late. I glanced down and the name was "Fred Brooks".

I had this flashback to 1977 when I was a young software developer. Two years out of school with a shiny new Masters in Computer Science. I was just starting to call myself a Software Engineer and I was in this meeting with about ten older, wiser, non-programming, engineers who did not understand why my software was on the critical path and why I had just announced a slip in schedule. The Project Manager ( a terrifyingly gruff Sargent type as I remember) suggested that we add a couple of other programmers to the team to help get me out of the ditch. I can remember holding up my copy of The Mythical Man Month and saying "I think that adding more people to a late project will only make it latter. Let me tell you why".

This was one of those pivotal moments in my career. The ideas in that book helped me earn the respect of the Electrical Engineers, Mechanical Engineers, Industrial Engineers, etc who surrounded me but did not understand my profession. Along with books like "Software Engineering Economics", and "Structured Analysis and System Specification", the "Mythical Man Month", became the core of my Software Engineering.

So, thanks Dr. Brooks.

a Sojourn in the Clouds

I have been learning IBM's Mashup Center, demoing to clients, and weaving it into my Web2.0 briefing as an emerging technology. I am able to do this in the Lotus Greenhouse as a free service from IBM. Recently IBM released version 2.0 of the product and after a product webinar I was ready to try the new/improved product. Alas, the greenhouse only had version 1 (that has just been remedied). Anxious to get going I fired notes off to people in IBM asking when I would get the new shiny version. I then stumbled on the fact that IBM had v2.0 available on Amazon's EC2 and if one was only using it for developer investigation (compared to a mashup for multiple users) then the product was FREE.

IBM provided a getting started video and pdf so off I went. I would listen to the video for a bit and then try to repeat the steps. There are a lot of things to do up in Amazon Web Services to get started and several freeware programs one needs to download in order to get things to work. I got stuck several times and finally resorted to reading the pdf line by line and carefully doing EXACTLY what was written. I never got my Ultra VNC to work but was able to use my Firefox browser to link directly to the Mashup Center Instance running on EC2.

For the configuration I had requested (Linux with 4GB storage) I was paying Amazon about $1.75 for each 24 hour period. I left it on for a few days while I developed and demoed for a client and was then able to terminate my instance.

If I did not have access to Lotus Greenhouse, and I was someone wanting to play around with a program like Mashup Center then using a infrastructure cloud is a good way to do it. And how do I like IBM's Mashup Center? Let me build up some more examples and then I will post a blog with my experiences.