News Stay informed about the latest enterprise technology news and product updates.

Converting embedded software teams to an Agile methodology with Nancy Van Schooenderwoert

Read this interview to learn what "embedded Agile" looks like, how it's done, and how teams can convert effectively from traditional means.

When a real-time system fails, airplane wings fail to flap, hearts stop beating, automobile transmissions don't shift, and people can die. Since these systems are essential to the proper functioning of everyday machines, it's no great surprise that embedded software project developers have resisted the transition to Agile methods. At the same time, there is a fair amount of evidence that traditional methods aren't so great either. For years, we have had a general consensus for a need for new methods; something to bridge the gap.

Enter Nancy Van Schooenderwoert, principal consultant at Lean-Agile Partners. Taking her (then) twenty-five years of experience in the embedded software space, Nancy went independent in 2004, specializing in how to adopt Agile methods in this complex, challenging space.

Seven years later, Nancy has learned (and, in some cases, created) new techniques to help manage and operate embedded Agile teams and coached teams while refining those methods.

Nancy will be presenting "A Virtual Tour of an Embedded Agile Team" at the Agile Development Practices Conference in June 2011.

SSQ: I was particularly struck by your title -- "A 'virtual tour' of an embedded Agile Team." What do you mean by that? What would the format be?

Nancy Van Schooenderwoert: I give lots of tours of the team room for one client. I did so many of these -- almost daily for a few weeks -- that it got into a nice pattern. In 30 minutes or less I was able to give visitors quite a good grasp of what Agile process is all about because they were seeing the key artifacts "live." It helped that the content they were seeing was focused on work familiar to them. The team's project manager was taking many pictures throughout the iteration. It occurred to me that I'd like to be able to give this tour "virtually" to anyone who's curious what it's like for a team starting Lean-Agile process in their first iteration building a safety-critical product. The client was willing to let me use the photos to create a presentation that I could offer as a virtual tour.

SSQ: In the abstract for the talk, you mention that "plain vanilla" Agile practices leave a "gap." What does that gap look like, and, if I might ask, what practices do you add to fill the gap?

Van Schooenderwoert: Here is one of the gaps that seems to bother just about everybody:

Many embedded developers believe Agile methods are not for them because they cannot see how chunks of user functionality can be split small enough to fit within iterations of a few weeks. Imagine building a new type of cell phone from scratch; a lot of software and hardware have to happen before you can even get dial tone. And nobody's going to pay you if that's all it does. So it's a long way to that first bit of customer value.

To address this, I talk about having layers of customers rather than only the external customer. For instance, your project's mechanical engineers might be the customer for a story that sets up an over-temperature software control loop. The end-customer wouldn't be able to evaluate that, but because it's still a "slice of the cake" architecturally speaking, you can define a clean acceptance criteria for the story. The first thing to try for is still to aim for end-customer value. The only reason to go for next-best is if the story with "end-customer value" is too big for you to keep it under control.

Other gaps concern the longer term estimates that embedded teams need, at least for enough buy-in to start using Agile methods in some situations. Still another gap is the need for a more sophisticated "iteration zero" idea to drive down risks.

SSQ: Talk to me about Agile conversion. What was the state of the team before going to Agile? What practice did you implement first, which did you implement second?

Van Schooenderwoert: I no longer even think of the practices as being separate. Every team has some capacity for getting x amount of work done for a given time period. Whether they can state that capacity or not, they have some capacity right this minute no matter what work methods they're using. I get them to discover what that capacity is, and then start reflecting on what factors influence it, and from there it's all about continuous improvement guided by facts everyone can see.

A core problem in software development has been that we don't have any widely accepted, easy-to-use measure for the size of software. So I start them on building that measuring stick in the form of story points.

SSQ: That makes sense. Can I ask, did the team change the way it worked over time? Did the developers adopt any specific technical practices like test-driven development or pair programming?

Van Schooenderwoert: In the first several iterations they were exploring upgraded hardware for the next generation of a product, and also working in tandem with another team that had developed a re-usable software framework. The team was an early "customer" of the framework. As for TDD and pairing, I first aim to get the team to have genuine control over how they do their work (managers should neither impose nor prohibit TDD or pairing), and have a way to make decisions as a team that all will support. They got those foundations in place and were starting to experiment with ways to use TDD.

SSQ: Did you see any strong comments at the end of those first few retrospectives? What kinds of changes did the technical staff make?

Van Schooenderwoert: Oh, definitely. In their first iteration, the planning method gave them confidence that they could deliver all the promised stories. One of the team members was called away for a couple days to address an emergency on another project, that couldn't be handled by anyone else. That was a big impact for a two-week iteration. They didn't quite complete all the stories. Some accepted it as outside their control while some (on the team) saw it as a real failure. Managers saw that they could better set the team up for success if they could arrange things so that they would not have to pull anyone off the Agile team.

To the company's credit, no one outside the team was saying they failed. It was clear that although some mistakes were made, the team would have delivered all the functionality if they hadn't lost a member for two days. One person commented to me that if all had been achieved 100% then observers in neighboring groups would have been less impressed -- they would have concluded that the estimates were padded. Since a problem happened and there was transparency about it in spite of all the visibility, observers outside the team were intrigued. In the next iteration the team recovered their pace.

In a later retrospective, when they did a "five whys" exercise on the issues they identified, it traced to tool problems, framework bugs (or incompleteness), and policy choices such as staying with an older tool version. It was surprising how many paths traced to seemingly cost-saving moves like not upgrading to current tool versions. Too much "cost control" is very expensive.

SSQ: Thank you for participating. Where can a reader go to learn more about you and your work?

Van Schooenderwoert: Thanks for the good questions!  I have several articles on my website at and I'm working on a book "Lean Agile Methods for Safety Critical Applications." I've also done several podcasts with Bob Payne which are here I'm on twitter as @vanschoo.


Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.