NI has a well defined development process to release software and hardware products. Developers are exposed to some things and not to others. For example, most developers don’t really get exposed to pre-release meetings and product planning meetings that serve as checkpoints as a product goes through different stages and is ready to be manufactured (CD’s or DVD’s in the case of software as well as web downloads).
Today in our team meeting we discussed the iterative process we’ve been using. I wrote a little on this topic a few weeks ago in the context of the LabVIEW Project feature released in LabVIEW 8.0
Note: By team I’m not referring to the entire LabVIEW group. I’m referring to a specific team working on features focused on improving how people deploy their distributed applications.
The current development process is “based on” Scrum which is a flavor of the Agile process. We’re pragmatic in our approach to development and really look at any process with an attitude of how it works best for us. One of the developers in the team tried to convey that some process really is necessary even thought the initial reaction we sometimes get when we hear the “P” word is borderline hatred. A free for all doesn’t work and he said something along the lines of that we should think of process as being “the difference between doing whatever you want and making rules that we all agree are useful to follow”. I thought that was a nice way of putting it. Now, one of my roles is that of a project manager so some level of process for me is needed just to stay sane but it is always the intent and goal of any process that is the most important thing. If those goals aren’t being met the process isn’t working (for whatever reason).
One of the reasons we’re using a Scrum and iterative development approach is that there are elements of what we’re exploring that aren’t well defined from a requirements or design standpoint and require exploration. We could go off and write a detailed spec after a number of meetings, then create a design and implement it, test it and release. Most people would say that really you go through this cycle a few times for many features. What we’ve been doing is a little different than a detailed specification up front.
We’ve defined a number of high level areas and functional requirements. For each iteration we, really our Program Manager “Jen”, select the set of things from our list we want to tackle. Here’s an image of a PowerPoint representation of what was whiteboarded in real time to describe this during our meeting for some people at a remote office.
For early iterations we’ve created more what you could call demo scripts based on primary use cases. These are vertical slices that to work correctly require integration between the different system components. The output of those iterations has been a greater understanding of our needs, integration and validation of the systems components, and code that is more or less “prototype quality”.
After an iteration areas we then feel are now understood are treated differently. These get detailed specifications, designs and the implementation is expected to not be “prototype quality” but getting close to an alpha stage or feature complete. For areas that are still unresolved we try and continue in a prototyping mode since we need more work to get rid of the “not quite wrapped our heads around this” feeling.
As we’re now further in development we have a mix of subsystems in different states. Some are in what I’ll call “prototype and exploration” and others are in “defined and implementing”. The mix over time has changed and continues to change, being more heavily weighted to “defined and implementing” as we progress.
I’m a fan of this type of iterative approach because it recognizes that there are some unknowns and risks to any project and puts into place a process to uncover those unknowns and risks in an ongoing fashion. I’ll try and have some more follow-up posts on this topics since it has been a discussion area of late in my team.