JV: You have experience working in regulated environments. How do you use in these regulated environments?
CS: I worked with a company that was doing FAA work. They want to talk about a regulated crew of guys.
Of course, we couldn't deliver the documentation without a Big Bang approach, but we started to invite them to our bi-weekly sprint review sessions, and they liked that. We started to give them documentation two weeks at a time, and while they couldn't review it and approve it all, they could look at it and get caught up so that at the end, after several months of working on the project, they were able to understand what we were up to and not get a 600-page regulatory document and have to read it from scratch.
They were merging their understanding of it, too, so we were coming up with potentially releasable products every two weeks. That doesn't mean "released." That means as doggone close as we can get.
JV: Potentially released.
CS: As close as we could get to the edge of that cliff or as the regulatory to get them in there to talk to us. It was still using plan, do, inspect, adapt to inspect the product we were developing and to give some planning to the poor souls in the FAA.
JV: Speaking of those tight regulations, how about dealing with agile in a healthcare environment? That's obviously a big regulatory field. Can you explain a little bit about how that fits in with healthcare?
CS: Let's not talk about the government debacle that's going on right now, but with other regulatory environments, I can see this being used in firmware. I can see this being used in life-critical systems, too, especially in-life critical systems.
JV: Can you elaborate a little bit more into that?
CS: You don't want to develop the software based on something that is only conjecture at the beginning. You're designing the software, sure enough, but what if you run into problems with the software or with the hardware interface or the way that it's working? Do you want to then keep going down that path? I don't know. I think you need to be able to change, based on what you're learning.
I'm not saying don't have a plan. That'd be foolish. Anybody in agile that says you don't have a plan is selling snake oil, but having that plan at the fidelity that you possibly can at this point, that's the way to do it.
With regulatory environments, highly regulatory, there's a lot of risk. A lot of risk; is it going to work right? Am I going in the right direction? Even more so with those environments. You want to look at what you're doing. You want to adapt where you're going. You want to inspect what you're up to. You want to test it frequently. Those are all things that fall into the agile environment. You don't want to test it at the end.
JV: How's it been working with some government agencies with agile? How are they taking to any of the techniques?
CS: To be honest, I haven't worked with a lot of government regulatory environments in the last couple of years, so I don't think I can answer that one very well.
JV: Okay. That's fair enough. Let's talk a little bit about the past year and the continuing growth of agile. What have you noticed as far as the rise of agile since you first started doing your first implementations, the big trends you saw?
CS: I'll tell you what I'd like to talk about over the next coming year. There's a lot of interest in enterprise-level Scrum, enterprise-level agile. That's a tough nugget to crack.