≡ Menu

037 VISP Applying The Agile Software Development Principles

Play

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:

About the author: Michael Aivaliotis has been working in the test and measurement industry since 1993 with LabVIEW 3.0. He started his career as a test engineer and quickly fell in love with the graphical programming paradigm that LabVIEW provided. Since then, he’s worked on or developed an incredible number of complex test systems in electronics, semiconductor, automotive, telecom, biomedical and other industries. He’s an Certified LabVIEW Architect and a Certified LabVIEW Instructor. He also has the distinction of being among a select few LabVIEW Champions. In 2002, he created the LAVA Forums which have now become the largest independent online LabVIEW community. Email 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.

    Thanks,
    Fab

  • http://www.jamesmcnally.co.uk James McNally

    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?

    • http://agileevidence.com John Sextro

      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.

    • http://agileevidence.com John Sextro

      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.