Get Started with Agile
After completing this unit, you’ll be able to:
- Summarize the benefits of agile project management over traditional waterfall planning methodologies.
- Describe the role product owners and development teams play in prioritizing and selecting which items to work on.
- Discuss the mechanisms agile programs use to organize, run, and structure work in an iterative way.
We at Salesforce and Atlassian are excited to collaborate on this agile development trail. We share a strong commitment to creating successful companies, and we recognize the critical role that agile development methodologies play in ensuring this success.
Agile project management is an iterative approach to managing software development projects that focuses on continuous releases and incorporating customer feedback with every iteration.
Early adopters of agile development were small, self-contained teams working on small, self-contained projects. They proved the agile model can work, to the joy and betterment of software makers around the world. More recently, larger organizations are scaling agile beyond single teams or projects and seeking ways to apply it to whole programs.
Let’s start with the basics—like what makes agile different.
Traditional project management styles, like waterfall, build in phases. The graphic illustrates a standard waterfall project. This style of product development folds everything into a single, big-bang, high-risk release. Once a project passes one phase, it’s painful to revisit it because teams are always pressing forward to the next stage.
Traditional project management styles often create critical paths, where the project can’t move forward until a blocking issue is resolved. To add insult to injury, the end customer can’t interact with the product until it’s fully complete. Thus, important issues in the product’s design and code go undiscovered until release.
Let’s contrast that with an agile pattern, which takes an iterative approach to development with regular feedback intervals. These iterations enable the team to be diverted to (and productive in) another area of the project while a blocking issue is resolved.
This, in turn, gives the team constant opportunities to build, deliver, learn, and adjust. Market changes don’t catch you flat-footed, and teams are prepared to adapt quickly to new requirements.
An even greater benefit is shared skill sets among the software team. The team’s overlapping skill sets add flexibility to the work in all parts of the team’s code base. This way, work and time aren’t wasted if the project direction changes.
When a program transitions from traditional project management to agile, the team and the stakeholders must embrace two important concepts:
- Product owners prioritize work: The product owner’s focus is to optimize the value of the development team’s output. The development team relies on the product owner prioritizing the most important work first.
- Development teams select work: The development team can only accept work as it has capacity for it. The product owner doesn’t push work to the team or commit them to arbitrary deadlines. The development team pulls work from the program’s backlog as it can accept new work.
Let’s explore the mechanisms agile programs use to organize, run, and structure work in an iterative way.
A roadmap outlines how a product or solution develops over time. Roadmaps are composed of initiatives, which are large areas of functionality, and include timelines that communicate when a feature is available. As the program develops, it’s accepted that the roadmap will change—sometimes subtly, sometimes broadly. The goal is to keep the roadmap focused on current market conditions and long-term goals.
To learn more about agile roadmaps, check out this article by Atlassian on building an agile roadmap with tools like JIRA software and Confluence.
Each initiative in the roadmap breaks down into a set of requirements. Agile requirements are lightweight descriptions of required functionality, rather than the 100-page documents associated with traditional projects. They evolve over time and capitalize on the team’s shared understanding of the customer and the desired product. Agile requirements remain lean while everyone on the team develops a shared understanding via ongoing conversation and collaboration. Only when implementation is about to begin are they fleshed out with full details.
The backlog sets the priorities for the agile program. The team includes all work items in the backlog: new features, bugs, enhancements, technical or architectural tasks, and so on. The product owner prioritizes the work on the backlog for the engineering team. The development team then uses the prioritized backlog as its single source of truth for what work needs to be done.
Agile Delivery Vehicles
Agile can be implemented using various frameworks (like Scrum and Kanban) to deliver software. Scrum teams use sprints to guide development, and Kanban teams often work without fixed work intervals. Both frameworks, however, use large delivery vehicles like epics and versions to structure development for a synchronized release cadence out to production.
What’s the difference between epics, stories, versions, and sprints? Check out this tutorial by Atlassian to learn how to structure your work in tools like JIRA Software.
Agile teams thrive on metrics. Work in progress (WIP) limits keep the team, and the business, focused on delivering the highest priority work. Graphs like burndown and control charts help the team predict their delivery cadence, and continuous flow diagrams help identify bottlenecks. These metrics and artifacts keep everyone focused on the big goals and boost confidence in the team’s ability to deliver future work.
Keep reading in our “Agile for programs” section for deeper dives into each of these topics.
An agile program cannot function without a high level of trust among team members. It requires candor to have difficult conversations regarding what’s right for the program and the product. Because conversations happen at regular intervals, ideas and concerns are regularly expressed. That means team members also have to be confident in each other’s ability (and willingness) to execute on the decisions made during those conversations.
In summary, agile development is a structured and iterative approach to making software. It gives you the ability to respond to change without going off the rails. And that’s good news for any program.
In the next unit we cover how to build your agile teams and how they work together to continuously create quality products.