Documentation
Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.
We get many questions about the differences between DevOps and Agile. How are they related? Is one better than the other? For many organizations undergoing digital or Agile transformations, all the changes may seem confusing, ineffective, and incorrect. This blog post will provide some foundational knowledge about Agile, where it came from, what it entails, and how it relates to DevOps.
Since the start of computer programming and software development, there have always been software development methods. Eventually, these methods and styles lent way for software development project management. By the 1970s, these methods were formalized into models that other engineering teams could leverage to plan, manage, and regulate software application development. The waterfall model was one model that broke down all the phases of a software development project into a series of linear phases—each phase corresponding to a specific set of tasks and work.
Eventually, more lightweight models emerged, favoring shorter cycles for implementing designs and requirements and more frequent feedback and verification. The models formularized in the 1990s included rapid application development, the unified process, dynamic systems development method, Scrum, extreme programming, and feature-driven development. In 2001, seventeen software developers met to discuss these lightweight development methods, collectively known as Agile software development models. In this meeting, the group formed the Manifesto for Agile Software Development, spearheading the advancement and practices of Agile into the 2000s. Eventually, the Agile alliance created the Agile Glossary, an open-source resource for how we know about Agile, including its practices and terms today.
Aside from the Agile Glossary, there are other resources and research around achieving Agile fluency and for succeeding with an Agile transformation.
To best achieve agility, consider your team’s skills, your organization structure, and your organizational culture. Whatever your role on the team is, you want to choose one or two zones to support. According to the Agile Fluency Project, there are four zones with key behaviors and responsibly: focusing, delivering, strengthening, and optimizing. The goal is to approach and learn new behaviors that will incrementally lead to software development agility.
The Agile Manifesto and its seventeen signees shared four main values:
They also hold the firm belief that more importance should be put on the values on the left than on the right. Scott Ambler, a software engineer, clarified:
Alongside these values were 12 principles stated in the Agile Manifesto:
These values and principles are foundational for all Agile work models.
Now that we know more about adopting Agile from a mindset, values, and principles perspective, let’s discuss popular Agile frameworks alongside the tooling available to facilitate these practices.
Scrum is a lightweight, Agile framework that allows teams to develop and deliver their projects and products. A Scrum includes a Product Owner, Scrum Master, and Scrum team members. The Product Owner owns the why and what of the project. The Scrum Master facilitates the group activities, addressing any blockers and following up with any action items or needed discussions. The role of Scrum Master can rotate amongst the Scrum team members because ideally, anyone in the Scrum team can facilitate any Scrum activities. Finally, the Scrum team members deliver and implement the work needed to accomplish the team’s goals. They own how quickly and how often work is completed.
The three roles in Scrum are Product Owner, Scrum Master, and Scrum team members.
The framework consists of 8 activities centered around the concept of a sprint. A sprint is an interval of time. The Scrum team utilizes a backlog of work to determine which items are feasible for completion during the sprint. After agreeing to deliver the set amount of work during the sprint, no changes are made to the items set out.
At the start of a project, many teams will agree to a sprint length, be it one or two weeks. A version of the application is released at the end of each sprint. A sprint may be broken down into a daily sprint, ensuring project progress. After a sprint, there is a work demo presentation and a retrospective to capture any pain points or improvements for the next sprint. The process restarts when teams look at the product backlog and determine the next set of items to complete.
Kanban is an Agile framework for visualizing teamwork, limiting work in progress, and ensuring a continuous value flow. Work is entered into a Kanban board in the form of a card and moved across columns until marked as complete work. Some teams will set standards or guidelines to how cards are created, updated, described, and moved across the Kanban board columns.
The goal of Kanban is to optimize the flow of work within a team.
Scaled Agile Framework, or SAFe, is a framework that joins together lean and Agile principles. A SAFe works well with larger organizations as different functions support work planned program increments (PI). SAFe provides all the resources and training materials needed to implement the SAFe framework.
The framework also shares how to best leverage roles, teams, and practices to scale Agile across an organization.
There are many different Agile development frameworks, including extreme programming (XP), feature-driven development, and lean software development. In StackOverflow’s Annual 2019 Developer Survey, professional developers reported a mixture of frameworks, including Scrum and Kanban, and even the practice of pair programming.
What your team uses may involve variations of the described Agile frameworks. Going back to Agile principles, it’s important to gradually improve and modify the way we work as a team to improve project flow and succeed.
Now that we know more about Agile frameworks, let’s discuss important Agile practices that can accelerate your improvement rate when delivering work in a software development team.
Writing user stories into your cards or tasks of work is a technique that ensures all work in a product backlog is of relevant value to a particular user or persona relevant to your project. User stories create minimal working requirements to achieve a particular outcome or action. They are written in the following form:
“As a …, I want to …, so that I can …”
To create more autonomy and for anyone in a team to take on work requests, it’s important to ensure that your work is properly defined and well understood by the team. User stories are one way of ensuring that requests are well defined.
A great way to create opportunities for improvement and success is through a post-mortem exercise. There are a few different retrospective formats like a sailboat, four squares, and four Ls. Below is a screenshot of a retrospective and the action items derived from the team’s feedback.
Use the time set out to capture any action items that can come from the feedback. A common practice is to assign ownership to the action items or tasks and follow up in the next week.
A common pitfall for improving your agile fluency is to confuse process improvements with the needs to improve or enable a team of people. In a Scrum-based setting, success is measured through the deliverables. It makes sense to apply this framework when developing new solutions or features. The team self-organizes and manages the work that is delivered 1-4 weeks at a time through sprints.
With a lean mindset, success is measured by how we reduce costs and accelerate output. That’s why lean practices should only apply to existing repeatable processes. Lean also applies on a company-wide scale and management takes into consideration worker opinions, but the approach is typically top-down. DevOps actually borrows many lean processes and practices from its origins in industrial manufacturing.
Ensuring that your individual contributors and teams have the autonomy to deliver their work will allow you to improve your agility. Part of giving this autonomy to your teams is to recognize the key goals for every role on the team and determine if work is meant to be Scrum-based or lean-based.
Succeeding with agility is about getting to your software development team's optimal mindset, principles, and processes. There is more than one Agile framework, implementation, and understanding of what it takes to work with agility. Coming to a consensus that optimizes your project will give you the most success for rapid software development and delivery. This blog post shared what you need to know about Agile. If you’d like to further improve your software delivery, I recommend reading our CI/CD guide for DevOps teams and trying Harness, a software delivery platform, for free today.
Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.