I had a good exchange with a friend and colleague of mine that I thought would be interesting to share. We discuss our respective philosophies about writing good requirements and how that conflicts/interacts with a real-world Agile development process.
Steve:
Hey Jeff, I skimmed thru your Joe Hage talk this morning. I listened to Michelle Lott talk about documentation for FDA as it relates to design controls. We learned early on… that the design input phase of a project does not work well for Agile or SCRUM. The best way to write software inputs is to get someone who knows the product (to be developed) and has written input documents before and let them lead the effort and get feedback as needed. The document writing just doesn’t lend itself to a SCRUM process.
Jeff:
Hey Steve, thanks for listening! I agree and I hope it didn’t come across otherwise. Overall, I think there are a lot of different conceptions about what Agile is, and everyone seems to have a different definition. This is a topic I’ll be exploring deeply in my own writing.
Overall, the Agile philosophy is that you want to get feedback as quickly as possible, and incorporate feedback into the next iteration. You can do this on a very granular time scale (weeks for sprints) and/or on a program-level time scale (get to market with a stripped down v1, get feedback from clinical use, release a v2, etc.).
My philosophy on the design inputs & requirements phase is like this:
1) Iteratively prototype extensively before even starting a formal design process, so you know what you are going to build.
2) Ruthlessly prioritize high-level requirements and determine the true minimum set that you can ship to market as a v1.
3) For those v1 requirements, flesh them out rigorously and in detail. This is where the tight feedback loop between requirements and system design/architecture occurs. Recognize the difference between requirements that are TBD because you don’t have enough information, and requirements that are TBD because you are procrastinating.
4) Even with fleshed out v1 requirements, you will inevitably change requirements during the development process. Your life-cycle management tooling must be as streamlined as possible to support evolving requirements and test cases.
Maybe this seems controversial, maybe it doesn’t. I’ve just seen lots of instances where people are making mistakes in each of those 4 points.
Steve:
I agree with number 1, but as you know this doesn’t always happen. Number 2 is great and should be followed by every team. Unfortunately, a lot of companies don’t want to launch with a minimally viable product or software version and I would be the first one to admit that this is crazy. There should always be a software development plan that includes versions of software after product launch. Often, the marketing team pushes to have “everything” in the first product. This is understandable from their point of view, as they are on the front line at launch and want to ensure the device is accepted in the market.
Totally agree with number 3 and some of the TBDs directly relate to how far the prototype development went. This is another area of concern: not enough work done on a prototype vs. too much work done on the prototype. The first means you aren’t ready to start development. The second could mean that you are working on gen 2 before design controls even get started.
Totally agree with number 4 and this goes more to what you mentioned on the video, not only changes in requirements, but additional requirements (more of the issue). I remember talking to [a former mutual colleague]. The additional requirements were driving her crazy. Usually the client says, well you know that these types of instruments (diagnostic, therapeutic, etc.) all have X, Y and Z – and so you should expect that all of these requirements would eventually be added! This happens despite a well defined V.1.
Jeff:
Nice to hear that we are mostly in violent agreement. ;-)
Be safe out there, and happy developing.