Agile Foundations for Developers
A few years ago, I gave a webinar talk on fundamental Agile concepts for developers new to environments leveraging Agile methods. This blog post is for anyone looking for such information. Every developer has probably come across some, if not all, of the terms, shared in this blog post.
The History of Agile
Software development methods have existed since computer programming, and software development emerged. 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 understanding designs and requirements and gaining frequent feedback. The models formularized in the 1990s included rapid application development, Scrum, extreme programming, and feature-driven development.
Then in 2001, 17 software developers met to discuss these lightweight development methods and named them 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 what we know today as Agile.
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 believed 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:
- Customer satisfaction by early and continuous delivery of valuable software.
- Welcome changing requirements, even in late development.
- Deliver working software frequently (weeks rather than months).
- Close, daily cooperation between business people and developers.
- Projects are built around motivated individuals who should be trusted.
- A face-to-face conversation is the best form of communication (co-location — though, in COVID times, a Zoom will do!).
- Working software is the primary measure of progress.
- Sustainable development, able to maintain a constant pace.
- Continuous attention to technical excellence and good design.
- Simplicity — the art of maximizing the amount of work not done — is essential.
- Best architectures, requirements, and designs emerge from self-organizing teams.
- Regularly, the team reflects on how to become more effective and adjusts accordingly.
Agile started from an ideology. In practice, this looks very different across different workspaces.
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 blockers and following up with 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 framework consists of 8 activities centered around the concept of a sprint which is an interval of time. A 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, and a version of the application is released at the end of the 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 items to complete.
In a Scrum-based setting, success is measured through the deliverables. So most teams that understand and use this framework are developing new solutions or features. The team self-organizes and manages the work delivered 1–4 weeks at a time through sprints.
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 as a card and moved across columns until marked as complete work. Some teams will set standards or guidelines for creating, updating, describing, and moving work tickets across the Kanban board columns.
The goal of Kanban is to optimize the workflow within a team. This is usually recommended for teams that support other teams through a continuous/ongoing flow of requests and work.
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 leverage roles, teams, and practices to scale Agile across an organization. SAFe combines Agile and Lean principles to scale software development and delivery across various enterprise software roles and functions.
I recommend that individuals read into this on their own time, if necessary. Most organizations that use SAFe / Scaled Agile are large enterprises consisting of engineering organizations with the headcount available to fill the roles outlined by the method.
Other Developer Methodologies
Other Agile development frameworks include extreme programming (XP), feature-driven, 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.
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 ensures that all work in a product backlog is relevant. User stories create minimal working requirements to achieve a particular outcome or action for a user or persona you’ve defined. They are written in the following form:
“As a …, I want to …, so that I can …”
To create more autonomy and for team members to take on work requests, the team must ensure that your work is properly defined and well understood. User stories are one way of ensuring that requests are well-defined.
If anything in a work request is ambiguous, utilize your meetings or conversations with team leads to gain clarity.
Leverage Retrospectives
A great way to create opportunities for improvement and success is through a post-mortem exercise. Several different retrospective formats include 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 in project management involves forcing changes rather than enabling individuals and vice versa.
To reduce costs and accelerate output, you should consider automating and improving your processes. To improve the quality of your deliverables, consider enabling or discussing the topic with the team.
Ensuring that your 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 (people vs process-centric).
In Summary
To enjoy and work with Agile methodologies on your team, you should understand the work, fundamental values, and processes your team owns. This blog post shared what you need to know about Agile to give you a foundation to work off of in your workplace.
