≡ Menu

037 VISP Applying The Agile Software Development Principles


John SextroWe've all heard of the Agile Software development methodology; but how many of us are actually using these principles while developing LabVIEW code? My guest, John Sextro is an Agile coach and an expert in the field of Agile Software development. Listen to this episode of the VI Shots podcast where I ask John about the Manifesto for Agile Software Development, and we walk through the 12 principles behind the Agile manifesto. This conversation is just the beginning of an exploration of this topic. I'm planning on having John back on in the future to discuss Scrum, which is the leading agile development methodology.

Agile Skier

I believe LabVIEW is by-design, a language that can thrive within an Agile development environment. You can quickly get software working and data displayed on a UI within a short time frame. I'd like to hear your feedback on this topic. Do use Agile? If not, then why not? Post you concerns and questions in the comments below and John will visit this post to answer your questions.

The Agile Manifesto

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.

12 Principles behind the Agile Manifesto:

  1. Our highest priority is to satisfy the customer through early and continuous deliver of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Links to content mentioned in this podcast episode:

Hey, this is Michael Aivaliotis! Thanks for reading my post, listening to the podcast or watching the video on this page. When I’m not posting content on this site, I help companies develop automation powered by LabVIEW. If you want to find out how I can help you succeed with your next LabVIEW project – Contact Me.

  • FabiolaDelaCueva

    Excellent interview. Thanks for doing such a good introduction to what the Agile Software Development Process is all about. I have met with several LabVIEW teams that are trying to implement these principles, I will make sure to send them here, so they can learn more about it.

    It is harder to apply for projects where there is only one LabVIEW Developer, but there are still pieces of this process that can be applied.


  • Very interesting session. Somehow the words have more meaning having someone explain them rather than just reading them.
    Im curious, what role do you see a software architect having in this. Traditionlly they would define the architecture but now there is no one architecture definition so what would their role entail in agile?

    • James, there is still a lot of room in the agile process for architecture. Having said that, we like to start with a basic high level architecture and then evolve the architecture as things emerge. Software is a very malleable medium and we should take advantage of the malleability to continuously refine and improve the design and architecture of the system as requirements and constraints emerge and as we learn more about what is needed. Architects play a key role in helping guide that evolution. Neal Ford has a great presentation on Emergent Design at http://vimeo.com/16955608

    • Steve Watts

      You won’t be nearly agile enough without some sort of architecture in place James, our template allows us to deliver working code very quickly and start getting that all important feedback. I like the emphasis on Simple, although my simple is very very simple.

  • Steve Watts

    Excellent interview again, I wholeheartedly agree that Agile fits nicely with LabVIEW. I do have a one area that I have issue with though. We work primarily on fixed price projects, and even if you are hourly paid you will be working to a fixed budget. With this in mind how do you cope with a customer that no longer wants a Word Processor and now wants a spreadsheet (to take the example given in the podcast). More importantly how do you price it?

    Also with regards point 9 “Continuous attention to technical excellence and good design enhances agility.”. Having been on a few lean manufacturing projects I’ve seen the easy things given most time and the most difficult left behind.

    • Steve, this is a great question.

      Fixed bid projects are tough no matter who you are and no matter how you approach it. The problem with the phased delivery methods, such as waterfall, is that you and the customer will not realize that the word processor that they asked for is not the spreadsheet that they really need, until the final phase of the project when you deliver the software to the customer. You will blissfully endeavor to produce the greatest word processor ever and when you give them the newest, greatest word processor it will be a complete failure because all this time they really needed a spreadsheet. But until the customer has a chance to use working software they are unable to experience this “moment of learning” about what they really need.

      This same exact thing will occur on an agile project, except that the “moment of learning” occurs much earlier in an agile project. This gives you and your customer a chance to recover. This early opportunity to learn could be the difference between a successful project with an additional 15% cost and a complete failure with 100% loss.

      You will often hear agile practitioners talk about “failing fast” and this is what they mean.

      • Steve Watts

        I always thought this was one of the great advantages of LabVIEW, it is inclusive and not involving the customer is actually harder to do. We tend to push the risks to the front of the project, delivering a UI (of sorts) very early in the project. This allows the discussion to really begin. We sometimes separate this work out (badly termed as a feasibility study) and use it to home in on the scope of the project.

  • Richard Thomas

    I’ve listened to this three times now, it’s a great podcast. I can recognise a lot of what I actually do mirrored in some of the Agile mandates, such as frequent working releases to the customer. I’ve previously assumed this was a weakness in myself, that I’m unable to deliver the final solution in one shot right at the end of the project, but now I see that in actuality I’ve been following practices akin to Agile. Being able to understand the positives in such an approach makes this very appealing.

    I’d like to be able to follow more Agile practices, but I see two issues:
    1. Embracing changes makes fixed price quoting impossible, and businesses always wish to know in advance exactly what they’re getting. I suspect the Agile technique is a hard sell, which leads into:
    2. The customer will need to buy into the Agile technique, which means convincing them of something that might sound too insubstantial.

    If one can find the ideal customer with deep pockets and overflowing with trust, then Agile would be great. But how often do those kinds of customers come along? I think outside of the world of Facebook development, for the mortals of the world who work on sub $100k developments, we’ll struggle to find opportunities to put Agile development into practice.

    I’m putting a User Group presentation together based on this material. Thanks to VI Shots and Michael for his continuous efforts with the podcasts, and to John for sharing his knowledge in this episode.

  • Christopher Relf

    One of the best VIShots podcasts to date – it’s refreshing to hear a podcast about Agile SWDP with a guest who actually knows what he’s talking about :)

    The only thing I’d add is that models can, and should, fit inside other models. Just because you use the Vee model at one level, that doesn’t mean you can’t use Agile at a lower level. Or at a higher level. Whatever works best for you, your organization, and your customer. I’ve heard too many “oh, we can’t use Agile principles, we’re in a regulated domain”, when, at the regulator-specific level Vee makes sense, but at development and sub-development levels Agile works wonderfully!

  • Pingback: ภาพที่สื่อถึงทีมของเรา | TikkyChai()

  • Jeremy Knight

    I know this is an old post, but…There is a huge deficit in LabVIEW being useful when it comes to Test Driven Development. Basically its Unit Testing capability is limited to the NI Unit Test Framework, or JKI’s VI Tester. Both require you to produce the code or the architectural input output layout before you can write any test code.