Backlogs vs. requirements: agility meets formality

When we started using Scrum and SAFe, we had to decide what to do with our formal documents. In medical device development, we have to create quite a few documents for each release, ranging from requirements specifications and risk management summaries to test documentation and manufacturing instructions. In FDA parlance, these documents are known as the Design History File (DHF) and Device Master Record (DMR), and they need to be formally approved and properly archived.

Could we have made our documentation more agile? It is possible to interpret your agile artifacts as DHF documents and turn some of your agile practices into formal processes. For instance, we could use our user stories as part of our design input documentation or treat them as change requests. AAMI TIR45:2012 describes ways to combine agility with formality in medical device software development.

We chose a different path: Our backlogs are informal wishlists that can be changed without formal approval. They are used as input for traditional requirements that are then formally verified and validated. Our agile practices are also informal, as we want to be able to experiment with new practices easily. This is not our final stage, as we see many opportunities for streamlining our development processes, but formality is not the best way to get started.

If you use agile development in a regulated environment, how do you manage your formal documents and processes?

Three increments later

We are now in the middle of our fourth program increment, and it is already hard to remember the old way of project planning and tracking. SAFe mission accomplished? No! As I wrote earlier, this is just the beginning of our agile journey. We are still learning how to limit our WIP more effectively, and it will take time and effort to move to truly incremental development. Incremental planning is easier to achieve.

In our business, a verification and validation period for the finished product is a must, but how to make this final V&V more lightweight without compromising product quality and safety? AAMI TIR45 provides some answers for software, but less has been written about agility in system and hardware development for medical devices.

Are we on the right track with SAFe? We have now asked our people three times if they would recommend the new way of working to a friend or colleague. So far, the answers have been more positive after each increment. I’ll let you guess the scale.

First release planning event

The corner of a program board. Every team has its own
row, and columns are for sprints. The post-it notes show
the features that the team is working on, while red
strings indicate dependencies.

The trains have left the station! Our two release trains arranged their first release planning event this week. It was a major event, arranged simultaneously in two countries, where teams from most of our functions (R&D, Customer Services, Q&R, Marketing etc.) planned their program increment together. It could have become a gigantic mess, but fortunately we had experienced coaches helping us, so the event went pretty well.

Some lessons learned:

• It may not be easy to involve all functions in your agile transformation, but at least in our case the usefulness of the plan would have been questionable if it had been limited to R&D.
• Try to get everyone to the same location, or do your best to help the remote teams stay on track with the planning. I am still looking for the best tools for remote participation; any suggestions?
• Your first program board is a great eye-opener. If your plan is too complex and fragile with many dependencies between the teams, the board will look like the web of a caffeinated spider.
• Two coaches and one full-time facilitator besides the release train engineer is not overkill for your first event.
• A standard-length release planning event (1½–2 days) can get exhausting for the participants. You can shorten it if all teams create their draft plans in advance; the event can then focus on dependencies, risks and required changes.