1-888-310-4540 (main) / 1-888-707-6150 (support) info@spkaa.com
Select Page

What Are The Key Agile and Lean Software Development Practices?

Published by SPK Blog Post
on August 27, 2014

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:

  1. 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.
  2. 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.
  3. 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:

Latest White Papers

Atlassian Cloud: Understanding Zero Trust Security

Atlassian Cloud: Understanding Zero Trust Security

Where To Start & Why It Matters What is the Atlassian Cloud Zero Trust Security model? Well, for decades, enterprise security controls were built to protect a large, single perimeter around a corporation. Often described as castle-and-moat security, This approach...

Related Resources

Top 6 Ways To Improve Your DevOps Journey

Top 6 Ways To Improve Your DevOps Journey

Knowing how to improve DevOps can be challenging. But, creating an integrated DevOps toolchain can set organizations apart from the rest. This is because having a well-defined business DevOps journey can reduce errors, improve collaboration and drastically increase...

Use Nessus To Harden Your Cybersecurity

Use Nessus To Harden Your Cybersecurity

Cybersecurity should be baked into the onset of IT and product development processes. Additionally, treating cybersecurity as an afterthought opens your organization up to vulnerabilities and risk. Therefore hardening your IT product cybersecurity with a tool like...

2022: The Year So Far Tech Review

2022: The Year So Far Tech Review

There’s been a lot of innovation, software and product releases in the past six months alone. So, we are rounding up the best tech review and engineering releases for the first half of 2022. The tech forecast for 2022 was heavily influenced by how the world adjusted...