There are many software development methodologies; which one is the best? I believe there is only one answer to this question; the method that best fits your customer and your company. The method you select should be decided on a per project basis. There are basically two categories of software development methodologies Agile and Plan- Driven.

The Agile Home Ground

• Agile, knowledgeable, collocated, collaborative developers

• Empowered customers

• Reliance on tacit interpersonal knowledge

• Largely emergent requirements, rapid change

• Refactoring inexpensive

• Smaller teams, products

• Premium on rapid value

The Plan-Driven Home Ground

• Plan-oriented developers; mix of skills

• Mix of customer capability levels

• Reliance on explicit documented knowledge

• Requirements defined early; largely stable

• Refactoring expensive

• Larger teams, products

• Premium on high-assurance

As a general practice, The Plan-Driven approach is our first choice when we start a project, it allows us to work with our customer at the beginning of a project to developed a specific scope of work and to charge a fixed fee for that work. We typically regard this as a best practice because it allows us to minimize the uncertainty and therefore manage some of the risk prior to starting the project. However, our corporate culture does allow us flexibility in the right situation. If the customer is early in their development phase, and therefore doesn’t have a clearly defined requirements document, then our best option is to work with the customer and develop the specification as the product progresses through the design phase.

My last three projects were “Cycle Testers” for automotive electronic modules. The “Cycle Tester” was capable of loading, exercising and monitoring multiple modules simultaneously, during durability testing. All three projects had the following challenges: no clearly defined customer for the module, incomplete firmware for the module, incomplete test requirements and aggressive timelines. When your customer is developing their product in parallel with the development of the testers it would be foolhardy to take a Plan-Driven approach. An Agile approach does not mean you do not have a plan it simply is a more adaptive plan vs. a more predictive plan.

The Agile Manifesto states:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

One of the challenges of using an Agile development plan is quoting a job that’s scope is not clearly known by the customer. One option is to assign a fixed cost to those things that are known, and negotiate what is a scope change and what isn’t. The problem is this contradicts the agile manifest to collaborate over negotiate. I believe the answer is to quote the project as a T&M (Time & Materials). If the hardware and build portion of the project is clearly defined then provide a fixed cost quote for that portion of the job.

One of the criticism of the Agile approach, and T&M’s, is they can be used as a means to bleed money from customers through lack of defining a deliverable. My response to that is, there has to be a trust between the customer and the client or the project is doomed. I believe it is our job to demonstrate to potential customers through our actions and past performances that we are worthy of their trust. It starts with the sales person, but it is everyone’s responsibility. The truth is if you are dealing with a company that’s goal is to bleed customers they are going to bleed you no matter what type of development process or P.O. you have agreed to. IMHO two of the most important attributes to look for when selecting a business partner is competency and honesty. If you can form this type of a relationship with your customers then everyone can focus on what is important, delivering a good product; not negotiating scope changes.

I believe the Agile method lends itself very nicely to LabVIEW and NI hardware platforms. Agile is about spending more time coding and less time documenting. When LabVIEW coding is done properly it inherently provides a certain level of documentation. There is also a premium on speed; I would certainly argue there is no faster programming environment then LabVIEW. Also, flexibility and adaptability are both attributes of LabVIEW and Agile. Furthermore the NI hardware platforms and drivers also possess the attributes an Agile methodology covets.

To learn more about the Agile project development method, download our white paper "How to Purchase a Test System without a Requirements Document."