Agile Foundations for Developers

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.

The History Behind Agile: The Agile Manifesto

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.

Achieving Agile Fluency

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 Principles

The Agile Manifesto and its seventeen signees shared four main values:

• Individuals and interactions over processes and tools 
• Working software over comprehensive documentation 
• Customer collaboration over contract negotiation 
• Responding to change over following a plan 

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:

• Tools and processes are important, but it is more important to have competent people working together effectively. 
• Good documentation is useful in helping people to understand how the software is built and how to use it. Still, the main point of development is to create software, not documentation. 
• A contract is important but is no substitute for working closely with customers to discover what they need. 
• A project plan is important, but it must not be too rigid to accommodate changes in technology or the environment, stakeholders’ priorities, and people’s understanding of the problem and its solution.

Alongside these values were 12 principles stated in the Agile Manifesto:

1. Customer satisfaction by early and continuous delivery of valuable software.
2. Welcome changing requirements, even in late development.
3. Deliver working software frequently (weeks rather than months).
4. Close, daily cooperation between business people and developers.
5. Projects are built around motivated individuals who should be trusted.
6. A face-to-face conversation is the best form of communication (co-location - though, in COVID times, a Zoom will do!).
7. Working software is the primary measure of progress.
8. Sustainable development, able to maintain a constant pace.
9. Continuous attention to technical excellence and good design.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. Best architectures, requirements, and designs emerge from self-organizing teams.
12. Regularly, the team reflects on how to become more effective and adjusts accordingly.

These values and principles are foundational for all Agile work models.

Agile Frameworks

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

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

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 (SAFe)

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.

Other Developer Methodologies

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.

Succeeding with Agile Practices

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 Well-Understood Work Requests and Requirements

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.

Leverage Retrospectives

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.

Understanding the Differences Between People and Process

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. 

Software Development Agility is About Teamwork 

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.