How Do You Handle Non-Functional Work With Scrum in Embedded Systems?

Question

I have two issues with scrum in embedded systems. First, there are many tasks to do, especially in the early stages, which are not demonstrable. We started with a dev board, no OS, no display, no serial comms, etc. We didn't have our display for 6 sprints.

The first 4 sprints were:

• Getting the RTOS up and running
• Creating tasks Writing network and serial drivers
• Writing interrupt routines for buttons, comms, etc
• Writing the primary database classes and methods
• Writing a serial debug menu

Most of these tasks are not well suited for user stories. In fact, the only interface into the whole system was the serial debug menu, built in sprint 3 so there was nothing to demonstrate at the end of the sprints. Even the serial menu was meant for internal use and not an end user. Never the less, I still want to track and manage these development activities via scrum.

We ended up writing "user stories" phrases like, "As a developer...", which I'm not happy with but in using Target Process (www.targetprocess.com), there is no concept of a backlog item which is a task or chore.

Second, how do you handle releases and testing? It's a real pain for us because the testers don't have the hardware debuggers so we have to build flash versions of the code and burn them on their dev boards to test. The testers are not technically as sharp as the developers and often require a lot of support in getting things working in the early stages (resetting the board, connecting the serial comms, etc), or even in understanding the output.

Finally, regarding the definition of done, a sprint can't be complete until all stories are complete. All stories aren't complete until verified by the testers. There is no way to avoid "robbing" developer time to give to the testers. In other words, if the last 3 user stories in the sprint will take 5 days to test, they must be coded and unit tested 5 days before the end of the sprint. What's the developer supposed to do, stop working?

I'm being facetious but it is a real problem trying to conform to the rules. Now, I'm fine with bending the rules but the issue I have is, it screws up all my burndown metrics if I can't mark things done until their tested.

I'd love to hear how others have handled these situations.

Answer 1

You are using a methodology on a product that is not compatible IMHO.

In the way most people define agile, all of the work is negotiable based on changing priorities, re-order-able or replaceable.

In the way most people define waterfall is that the work is laid out in sequence ahead of time from a significant architecture effort at the beginning.

The task you list above seem very waterfall to me, they have to be in a certain order, and they are not negotiable.

I am not saying that you have to abide by anyone's view of any process, but at least for these tasks you seem to be in a non-agile project to me. Trying to bash that into an agile process is going to be a sloppy fit at best.

If the rest of the project is well suited to agile I wouldn't worry too much about the initial setup being a bad fit, but the fact that you mention RTOS and dev boards make me suspect the whole thing would be better off in something more like waterfall (a long sequence of immovable dependencies).

Answer 2

You use Scrum in very specific area and you violate supposed process on every step. Your question should probably be: Is there another agile methodology which will better fit to my environment? Simply it is very hard to help you doing better Scrum if your environment doesn't allow it. The problems I see in your description:

• No demonstrable tasks which can be considered as infrastructure tasks. If you need several sprints to do something which is not considered as business value then your user stories are probably badly defined. If you need to build a tool or anything else to be able to deliver business value then product can be divided into two parts / releases - building a tool and building a business value. In such case your user stories "As Developer ..." will be completely valid because tool is created for developers. The problem here is how to communicate this with customer because his involvement in the first release is zero. If there is no business value for customers how can they participate? How can product owner define business priority? I think that the main problem here is that this is not something that fits to Scrum. Scrum tries to deliver the most important business features first but you need two months to deliver the first. Scrum and whole agile embraces the change - what will happen if after delivering first features customer requires some change which goes back to through all your initial sprints?
• Testing. Another failure because team in Scrum is considered as group of cross functional members. It means that everybody does development and testing and because of that there are not situations described in your final point (or at least not 5 days long). It doesn't mean that there cannot be separate QA to do some more complex and sophisticated tests but team must provide already tested / verified feature. In your case it really looks like Scrum is not what you need. You need separately handled development and testing and passing features between them.

Answer 3

OK, so I know nothing about building embedded systems, but from what I can see there's nothing that would make Scrum inappropriate for such development. It's easy to get caught up with worrying about not really having user facing functionality so it's difficult to write "user stories" with having users. Except that user stories aren't really part of Scrum - they're often used with Scrum - but really just as a tool.

What is part of Scrum is the idea of delivering complete features that are fully tested and potentially implementable in a live environment each Sprint. When you're starting from scratch on day one of any kind of a project, the actual value of any kind of functionality you can deliver in Sprint 1 is pretty small. That's because every tiny thing needs tons and tons of infrastructure built to make it work. But the point is that you only build enough infrastructure to make each feature work. And then you build it out as you add more features.

The idea is that you specifically do NOT spend months and months building infrastructure that has no way of being detected from outside the system. Why? Because until you build the stuff that actually does stuff, you don't know exactly what the infrastructure needs to be. That's stuff you learn as you build the actual features of the system. If you build the infrastructure at the beginning, then you're building it when you know the least about the system.

If you're dead set on writing user stories, then remember that users don't have to be people. So you write stuff like, "As a CMOS interrupt handler I need to able to detect the status of the bingle whozzit stack modulation flag when the fluxotronic compressor signals a passive bypass undercharge". Absolutely do not write "As a developer..." user stories.