Agile has become a big buzz word recently in the project management world. In this post, I'll try to clarify where some of the lines are being blurred between terms like Agile and Scrum, and what some of these terms actually mean.
Keep in mind while reading this that I am primarly trained in Scrum, so my descriptions of other Agile methodologies are only decently informed. :)
What is Agile Project Management?
From the ever-present wikipedia:
Agile project management is an iterative and incremental method of managing the design and build activities for engineering, information technology, and new product or service development projects in a highly flexible and interactive manner, for example agile software development.
The primary words to take into account here are iterative, incremental, highly flexible, and interactive.
Unlike traditional Waterfall approaches to project management, Agile seeks to build products from the perspective that not all requirements can be fully scoped at the beginning of a project, no matter how fastidious the discovery and documentation. And that better products come from being tested and revised while they're being built.
With Agile, we don't make a plan and follow it to the letter from start to finish; we allow the products we're building to morph into better products along the way.
The Agile Manifesto
The first step towards figuring out Agile software development is to become familiar with the Agile Manifesto. It was written in 2001 by a group of PMs and developers who were successfully experimenting with Agile approaches. Their successes lay in a few primary tenets:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Each type of Agile methodology, whether Scrum, LeanUX,or Kanban addresses these primary tenets in slightly different ways, but they should always remain core to an Agile strategy.
You can learn more about the Agile Manifesto at: http://agilemanifesto.org.
What are some examples of Agile methodologies?
Scrum is a system rooted in regular cycles of work called Sprints. Each Sprint has a fixed length of time, a set group of meetings (including the daily scrum, from which this methodology derives its name), and a defined set of work that the team has agreed upon. The work for each Sprint is taken from the top of a carefully prioritized Backlog of features to develop, which provides the majority of the documentation for the project in bite-sized chunks. Work is released early and often and revised as needed. For more about Scrum, you can watch my recent presentation on the basics of Scrum.
Like Scrum, Kanban for software development is based on working from a prioritized Backlog. Unlike Scrum, which sets predefined cycles in which small subsets of the work will be completed (Sprints), Kanban prevents team/process overload by limiting the number of items that can be worked at concurrently. Kanban keeps a constant flow of work in motion, ensuring that everyone is allocated just the right amount of work at any given time. This is called limiting Work in Progress or limiting WIP. Kanban also focuses on process and product iteration with structured feedback loops.
Lean software development
While Scrum comes with a lot of very specific team members, meetings, and mapping workflows, Lean is more of a group of principles and tools for building your own processes. These tools and tenants were derived out of manufacturing approaches developed by Toyota. Lean development can be summarized by seven principles:
- Eliminate waste: Any wasted time, unnecessary steps, manual testing, unused code, etc should be eliminated.
- Amplify learning: Speed up cycles and feedback loops by using automated testing, user testing, etc.
- Decide as late as possible: The further along you are in a project, the more you know. So decide later, when you know more.
- Deliver as fast as possible: The sooner you've delivered something, the sooner you can get real feedback into making it better.
- Empower the team: Find good people and let them do their job.
- Build integrity in: Make sure the code is clean, and everyone feels good about it, from developer to client.
- See the whole: Carefully define relationships between collaborating teams, and different software components
Extreme programming (XP) is rooted in frequent releases and short development cycles, interspersed with opportunities to adopt new customer requirements. The idea is to take the healthy aspects of software development and taking them to the extreme!
Some features of Extreme Programming include:
- programming in pairs or doing extensive code review
- unit testing of all code
- avoiding programming of features until they are actually needed
- a flat management structure
- simplicity and clarity in code
- expecting changes in the customer's requirements as time passes and the problem is better understood
Scrum, one Agile approach
There are lots of different methodologies (certainly more than I've listed here) that are considered a part of the Agile family and each addresses the Agile Manifesto in slightly different ways. Scrum is just one type of Agile software development in suite of many. I hope that helped to clarify things for folks.
And keep in mind: because the world is a complex and messy place, many of these methods get adopted in part and mixed and matched. Our team currently alternates between Scrum and something resembling Kanban.
What are you currently using and how is it working for you?