Many government programs are looking to go Agile, but there are so many Agile Frameworks and terms floating around out there, that it’s hard to make sense of it all.
Article By: Tim Schwamb, Colorado Operations Lead
Scrum, Kanban, Lean, DevSecOps, XP…Which one is best? Where do I start?
That feeling of being overwhelmed reminds me of looking for a shelter system for backpacking. A couple of years ago, I was looking for a backpacking shelter, and I quickly felt overwhelmed: Do I want a tent, or a tarp, or a mid, or maybe a hammock. Or…wait…what’s a mid?? And what material is best? Sil-nylon? Cuben Fiber? How do I decide? I felt like my head was about to explode! Finally, I found a “backpacking shelters for dummies” that put it in language I could understand and make the necessary tradeoffs.
So, let’s try that with Agile. Let’s break down each term so you can make sense of it all.
Lean is what started this whole movement. Agile development was born out of Lean thinking applied to manufacturing processes. While many of those same concepts of delivering value, reducing delays, innovation, and relentless improvement still apply, developing software is fundamentally different from manufacturing. Car manufacturers keep turning out the same car over and over which makes improving the product and the assembly line easier. Chances are, however, that we’ve never developed this software or computer system before. While the same principles apply, Lean is more about instilling a mindset of relentless improvement and built-in quality, with leaders developing and empowering the workers in the trenches to innovate, evolve, and take appropriate risks without guilt.
XP was developed to produce and deliver software quickly while still ensuring high quality. It incorporated many of the same practices utilized within the Agile development community, such as Test-Driven Development, coding standards, and pair programming, to improve the quality of software delivered. XP also set the foundation for Agile development through designs that required no more architecture than necessary, as well as automated testing and continuous integration to maintain the flow of value through the system. XP is still considered the bedrock of Agile software development today, but it’s really just a set of sound software development practices rather than a development process. Consequently, XP doesn’t scale to large software systems or complex hardware-software systems that require multiple teams.
Kanban is all about flow. Teams use Kanban boards, like the one below, to visualize the flow of development work, transitioning from backlog to completion through different states. Unlike Scrum teams, where teams commit to the amount of work they are going to do in a fixed period of time, Kanban teams pull work from the backlog as they have the capacity to complete it. Kanban tends to work best for a team with an ongoing workload that is not correlated to feature development, such as a maintenance team or a systems team responsible for the continuous delivery pipeline.
Scrum is perhaps the most well-known and widely used Agile development methodology. It coined the term DevOps, where developers interact daily with the customer to ensure that what is being asked for is understood, built, and delivered. It also introduced the development sprint, where teams plan and commit to delivering a few capabilities in bite-sized chunks in a short cycle – usually two weeks. The Scrum Master facilitates and manages the sprint to ensure the team stays focused and removes impediments that may be hindering progress. At the end of the sprint, the team reflects on improvements to practices and processes. Then the entire cycle starts over again, continuing indefinitely at a sustainable pace. The overarching goal is to deliver a working system to the customer with additional capability at the end of every sprint. -Scrum, especially paired with XP practices for software development, is generally the best and most user-friendly Agile development process — that is, until the system under development grows larger than one team of five to eleven can handle. At that point, you need a way to scale those Scrum practices to coordinate development across multiple teams.
Several years after Scrum introduced the concept of DevOps, combining developers and customer representatives, many companies rightly realized that cybersecurity has to be baked into those practices from the beginning. This idea also aligns nicely with the Lean principle of built-in quality, leading to creation of the term, DevSecOps. It’s extremely important to realize that DevSecOps isn’t a process but a culture change. It doesn’t make sense to say DevSecOps is your Agile development framework. That would be like some asking, “Which manufacturing process do you use?” and you respond with, “Quality car manufacturing.” At its core, DevSecOps is nothing more than an explicit recognition that development, cybersecurity, and the customer must work together continuously to deliver a secure, quality product in the shortest sustainable lead time.
If you’re working on a system that’s more complex than one development team of five-to-eleven people can handle, you need a way to scale your Agile processes to ensure the teams can adequately address things like interfaces and dependencies between features. None of the aforementioned Agile processes do that out of the box. The Scaled Agile Framework (SAFe®) was built for just this purpose and is the most commonly used framework in the federal government for Agile development at scale. SAFe is a flexible framework that blends many of the principles, processes and practices from Lean, XP, Scrum, Kanban, and DevSecOps with some additional principles and practices to facilitate synchronization of dependencies across multiple teams working together on a complex system.
SAFe even provides principles for extending Lean-Agile thinking beyond just development — to the whole enterprise. Extending these concepts to the portfolio level provides an agile method to link organizational strategy to investment decisions. Then trade offs can be made among programs even when priorities or conditions change faster than the POM cycle can react. Using SAFe’s Lean Portfolio Management, Lean Budgeting, and Agile Contracting principles, as well as government and industry best practices that work within the legal acquisition framework, even greater cost savings and faster product delivery can be achieved.
It really comes down to what your needs are. If you’re a systems team maintaining the continuous delivery pipeline, Kanban might be best. If you’re a single team developing a small application, Scrum is probably best. If you have a mid-sized or larger software system, a system that includes hardware, or want to blend the best of the Agile practices, SAFe is probably best.
No matter which might be best for you, hiring a coach to help with your transformation is one of the best decisions you can make. Your coach will walk you through the up-front planning and initial launch, tailoring processes to your unique program and helping you avoid some common pitfalls during that critical period where everyone is waiting to see if you succeed.
Oh, and if you were wondering, I finally decided I needed one of each backpacking shelter, because I needed a hammock for the forest in warm weather, a tent for the winter, and a tarp for the desert.