Agile is an approach to project management that favors responding to change over careful planning. Agile is not a methodology but a set of principles (as defined in the Agile Manifesto in 2001) that suggests how we should approach project management.
There are two ways you can manage software development projects:
- Waterfall: plan everything in advance, then build according to the plan for the next whole year
- Agile: plan what you'll build in the next few weeks and see how it goes from there
How to know whether you're agile? Just because you're using Kanban boards, Lean, or Scrum doesn't automatically mean you're agile. To really be agile, you have to share the agile values, as defined in Agile Manifesto.
Project Management Methodologies and Frameworks
Agile Manifesto
In 2001, 17 software developers met in Utah to discuss their processes that were different from the usual waterfall project management approach. Together, they defined the concept of agile software development in the Agile Manifesto. Today, when we say that some approaches are agile, it means they follow the value and principles from Agile Manifesto.
The group recognized that there's no one-size-fits-all approach, so Agile Manifesto doesn't prescribe how to run projects. Instead, it defines the mindset on how to best manage software projects.
The most important part of the Agile Manifesto is The 4 values. They are the heart of what it means to be agile.
Agile values help you focus on what's important. For example, one of the values is "working software over comprehensive documentation". It doesn't mean that documentation is bad - it means that if you have to choose whether to spend your time writing a detailed user story or fixing a bug, you should choose the latter.
Individuals and interactions over processes and tools
Knowledge workers prefer autonomy. So in software development, it's more important to let people solve problems by collaborating than forcing them to follow a procedure for the sake of satisfying some dusty policy.
Every company needs a workflow and processes (especially after they've grown to a certain size), but you must know why a rule is in place and when you should break it. For example, when daily standups stop being useful, don't force them just because some popular agile methodology says you must have them.
The way you know when a process doesn't work is when people can't collaborate efficiently anymore. People are the engine behind every project. If they can't interact because of hierarchy or a lengthy/complex protocol, they have to spend more time managing tools and processes than doing their job.
Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right. It’s not that rare to hear a junior leader defend a bad outcome with something like, “Well, we followed the process.” A more experienced leader will use it as an opportunity to investigate and improve the process. The process is not the thing. It’s always worth asking, do we own the process or does the process own us? - Jeff Bezos
There’s something really wrong with our definition of what a ‘completed project’ is. If it means ‘Did Chris get all his project tasks done?’ then it was a success. But if we wanted the project in production that fulfilled the business goals, without setting the entire business on fire, we should call it a total failure. - The Phoenix Project: A Novel About IT, DevOps, And Helping Your Business Win
Working software over comprehensive documentation
In traditional project management, phases happen in sequence, and if you mess up the first phase (requirement gathering and documentation), every other phase will suffer. That's why waterfall needs comprehensive documentation. But on an agile project, we expect things to change.
Do you really want to spend your whole time updating the documentation? What matters the most is having a working product that real users can test. If you had to choose between fixing a bug and writing a report on it, fixing it is the best use of your time.
This doesn't mean that you should forsake documentation. Developers fall into this trap often and write terse one-line user stories, which creates trouble for QA and maintainers because they can't figure out the proper user acceptance criteria.
The perfect documentation should be "Just Barely Good Enough". Too much and it goes to waste or can't be trusted because it's out of sync with code; Too little and it's difficult to maintain and get new team members up to speed.
When writing documentation, you should ask yourself what you would want to know if you joined the team tomorrow and document based on that. If you have trouble with documentation, grab a copy of Living Documentation by Cyrille Martraire.
Customer collaboration over contract negotiation
Contracts create a culture where change isn't an option. Agile creates a culture where change is expected. But how do you manage change? By collaborating with customers.
Agile presupposes that you have unlimited access to your customers and that you can always sit down with them and talk about the backlog. Developers are natural problem solvers, but they need access to the customer so they can better understand what the real problem is and adjust their delivery.
Contracts are useful, but they have a nasty side effect: people tend to care more about delivering the project within time and budget than fulfilling the real business goal. Further, when the team falls behind schedule, they are pressured to get things done which results in frustration, panic, and lower quality.
Also, when you sign a contract early in the lifecycle, you're guesstimating, and more often than not, you're wrong. But you still try to hit the milestone even though they have nothing to do with real needs.
That's why agile favors customer communication and collaboration and delivering work in small increments, one sprint and review at a time. This lets scope work as you gather more information and discover what you're not aware of.
Responding to change over following a plan
The more time you spend on planning, the more you resist changes lest your efforts go to waste. But the goal is not to deliver the project according to the program (within time and budget) - the real goal is to satisfy some business goal, and if it means completely changing your plan and products, then so must be it.
It's more important to build what you really need than to blindly follow an obsolete plan. Developers may hate it when their code becomes invalidated, but clients hate it even more when they don't get the product they need.
That's why agile favors shorter lead time and sprints and encourages and helps teams to chop things up into smaller deliverables so they won't have to redo large chunks of work. This means that you are never done with requirements gathering and design phases, but you continually revisit them throughout the lifecycle.
Elements of agile project management
A culture where change is expected
The Agile framework isn't about using a Kanban board, having daily standups, sprints, or anything similar (those are elements of specific agile methodologies). Agile, at its core, is a mindset where everyone, from employees to clients, expects iterative change. You can't promise your client everything at once or a firm deadline because both you and the client are aware that's unrealistic. But you can promise them that you'll give them something that can be used.
Incremental development
Each sprint builds on previous work, making the product better gradually. Also, you don't wait for completed work to pile up before releasing it all at once - you release it as soon as it's finished. An iteration might not add enough features to warrant a marketing campaign, but that doesn't matter because the ultimate goal of agile project management is to give customers value.
Frequent release
Because software is developed incrementally, you can have shorter cycles, where at the end of the sprint, you ship new features/updates. This way, customers can get a value as soon as possible and validate it. If the work doesn't satisfy their needs, you can learn that before you spend more time on development.
Short feedback loop
Because releases are continuous and more frequent, you can get feedback faster. And because you can get feedback faster, you can change the product more quickly and give value.
High level of client involvement
In order to reap the full benefits of a short feedback loop and frequent releases, you need a high level of client involvement. You need to talk to your client after each cycle and see how they use the software and if they derive value from it.
Sometimes the client is not available to give you feedback. Some agile methodologies (like Scrum) solve this problem by having a special role on the team called Product Owner. This person serves as a customer representative and acts on behalf of the customer. If a developer has any questions, they ask the product owner instead of the customer. The product owner also reviews progress and re-evaluates priorities at the end of each sprint.
