Agile and Lean Software Development approaches came into favor in the late nineties and beginning of the 21st Century in reaction to the many issues with traditional plan-driven, heavyweight software development processes. However, many of the practices embodied in Agile or Lean Software Development approaches are well established, and have been used since the earliest days of software development.
Heavyweight, plan-driven software development processes suffer from a number of weaknesses:
- They require the systems engineers or requirements analysts to fully understand all the intricacies and subtleties of the software they are defining at the beginning of the project, without the benefits of any feedback or risk mitigation. Such processes tend to produce inordinate amounts of documentation, without necessarily improving the quality of the software delivered, or increasing the predictability of software delivery.
- Heavyweight methodologies also tend to have significant inertia, which means they respond poorly to changes in the environment or to the requirements driving the software development.
- Plan-driven, sequentially phased development approaches are inherently risky, as the integration and testing of the complete system is left until the very end of the project. Subtle errors in requirements or design are often not uncovered until it is too late to address them effectively.
Agile and Lean Software Development Practices are intended to address the weaknesses of heavyweight, plan-driven software development methodologies, and they are based on sound engineering practices. If implemented properly, such practices will result in more disciplined, rigorous software development than traditional approaches deliver. The fundamental concept behind most of the practices, and the means for achieving the benefits of reduced risk, improved quality, and better response to changes is that of implementing and shortening feedback loops.
With traditional sequentially phased, plan-driven software development projects, they operate almost open-loop; working software is often only produced at the very end of the project, and engagement with the customers/stakeholders of the desired software application tends to occur primarily at the beginning of the project.
In contrast, at the heart of Agile and Lean Software Development approaches is the incremental and iterative development of working software. Incremental development provides the opportunity for short, high fidelity feedback loops with the customers and stakeholders. At regular intervals, new versions of working software are available for stakeholders to examine and interact with. Any ambiguities, errors or omissions in the requirements are quickly identified during the demonstrations and testing of these incremental releases. Iteration is a process for refining and correcting the software based on the feedback provided through the incremental releases. These incremental and iterative development practices are also referred to as “Inspect and Adapt” practices.
Incremental and iterative development practices require a clear, complete definition of “done” in order to deliver quality results for evaluation and feedback. By emphasizing that increments of functionality must be properly completed, meeting the standard defined for “done”, before moving on to new feature requests, Agile and Lean practices avoid the trap of building up unverified inventory, which is the main source of systemic risk in software development projects. The definition of “done” should be a holistic one, that takes into account the goal of each development cycle is the production of potentially deliverable working software – not just source code. “Working software” also means more than compiled and linked code; it should address what the final product must be — properly documented, tested and supportable software.
Agile and Lean Software Development approaches are based on a team-oriented approach to software development. There have been numerous studies that have shown that established, stable development teams typically outperform teams with high turnover, and that there is a significant cost to multi-tasking versus systematically addressing the highest priority task in a queue. Thus Agile and Lean Software Development approaches strongly discourage fire-fighting and yanking of experienced members from one team to help out on another.
During each development cycle, often referred to as a “Sprint”, each development team focuses on delivering the work they committed to at the planning meeting held at the beginning of the cycle. Changes to those commitments are avoided as much as possible; after all, given that the Sprint is typically 2 to 4 weeks long, the opportunity to re-prioritize tasks arises fairly quickly.
Agile project management is not an oxymoron; Agile and Lean approaches are not against planning — they dispute the benefits of blindly following a long-term plan. Given the desire to respond to change, and the fragility of a long-term, detailed project plan, Agile takes a “just-in-time”, Inspect and Adapt approach to project management. Long-term planning documents — such as project mandates or product roadmaps — are high-level, with just enough details to provide guidance for more detailed planning.
Detailed planning is done incrementally, with the goal being to provide a detailed, prioritized list of incremental work (often referred to as “User Stories” or “Stories”) sufficient for the next Sprint. Once a Sprint plan has been defined and committed to by the team, it is implemented without further changes, or it is cancelled if an emergency or major change makes delivering on that plan no longer feasible. Barring such emergencies or cataclysmic changes, the next opportunity to change the plan is the beginning of the next Sprint, which is why they are kept to short, consistent durations, and are typically 2 to 4 weeks in length.
In addition to the practices discussed so far, there are numerous technical practices such as peer programming (a form of just-in-time peer review), test-driven development, continuous build and test, agile modeling, and requirements elaboration through Story backlog grooming that are important to effectively implementing Agile or Lean Software Development approaches. However, it is more important to create environments where development teams are encouraged to learn and improve, where the focus is on flow and limiting the work in progress, and encouraging communication within the team and between the team and its stakeholders such that robust, tight feedback loops arise. I will address technical practices in a later blog article.
In regulated industries, such as Medical Devices, Automotive, or Aerospace, many regulators are unfamiliar with Agile or Lean Software Development approaches, and are more comfortable with traditional, plan-driven heavyweight software development methodologies. That does not mean that Agile or Lean cannot be applied in such environments; it just means the development organization must put more upfront effort into definition of their practices and providing a clear mapping of these practices to the regulatory constraints they must meet.
For example, in the Medical Device industry, at the beginning of 2013 the Association for the Advancement of Medical Instrumentation (AAMI) released Technical Information Report 45:2012, which provides guidance on applying Agile practices to the development of medical device software. Similarly, the US Air Force Software Technology Support Center has published numerous articles and case studies in its CrossTalk magazine addressing how Agile and Lean practices can be applied to avionics software development.
Next Steps:
- Contact SPK and Associates to see how we can help your organization with our ALM, PLM, and Engineering Tools Support services.
- Read our White Papers & Case Studies for examples of how SPK leverages technology to advance engineering and business for our clients.
