Being Agile vs. doing Agile: What's the difference?
Doing Agile and being Agile, compared
The difference between being Agile and doing Agile is akin to the difference between simply believing in the values and principles espoused by the Agile manifesto, and actually putting those beliefs into practice.
Being Agile as an IT professional means your actions and behaviors are guided and shaped by the four values and 12 principles stated in the 2001 Manifesto for Agile Software Development (aka The Agile Manifesto). According to the Manifesto, an Agile developer prioritizes:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
These are the four fundamental Agile values.
Being Agile as a programmer
Being Agile goes beyond chanting a 20-year old, four-stanza mantra. It also means that you seek answers in the Manifesto when software delivery problems arise.
For example, if a client changes their requirements midway through the development process, if you are being Agile, you accommodate them, because the Agile Manifesto says that developers should “welcome changing requirements, even late in development.”
“Agile processes harness change for the customer’s competitive advantage.”
The Agile Manifesto
When technical debt accumulates and processes become needlessly complicated, developers who are being Agile push for simplicity. The Manifesto states that “simplicity, the art of maximizing the amount of work not done, is essential.”
And if the customer seems unsatisfied with the progress being made, a developer who is being Agile will look for new ways to get updates in front of the customer. Being Agile means that you truly believe that the “highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Doing Agile as a developer
But there’s a difference between being Agile and doing Agile.
Doing Agile means you work on a “self-organizing team” made up of “motivated individuals” whom you trust to “get the job done.” These people and groups utilize a methodology whose principles are consistent with the Manifesto. Scrum and Kanban are two such examples.
“The best architectures, requirements, and designs emerge from self-organizing teams.”
– The Agile Manifesto
Doing Agile also means you do iterative development, plan sprints, manage the project’s feature backlog and limit the amount of work in progress. All of these activities support Agile project management.
Continuous delivery with Agile
Agile’s highest priority is the continuous delivery of software to the client.
Teams that are doing Agile will utilize modern DevOps tools that simplify the continuous integration and delivery process. That means teams build software delivery pipelines that leverage GitHub, Jenkins, Docker, Kubernetes and the cloud.
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
– The Agile Manifesto
When organizations combine these tools, development teams can more efficiently get new features into the hands of product owners and interested stakeholders. That means faster feedback, more transparency into the development process and an opportunity to change course if the built software doesn’t match the client’s needs or expectations.
The difference between being and doing Agile
The key difference between being Agile and doing Agile is that being Agile means you believe in the values and principles set forth in the Agile Manifesto, while doing Agile necessitates the use of modern tools, technologies and methodologies to create continuous delivery pipelines that respect Agile virtues.
If you are doing Agile without being Agile, your project is likely to fail.
Doing Agile without being Agile
For Agile software development to be a success, it’s not enough for participants to simply do Agile. The organization itself must also be Agile.
That may seem self-evident, but many software development projects fail when a team adopts an Agile methodology without a simultaneous adoption of an Agile mindset throughout the business.
Many organizations that pursue an Agile transformation begin with the development teams. The business expects developers to respond to change, continuously deliver software and self-organize, without other departments and management levels doing the same.
Examples of doing but not being Agile
Here are some examples of how stakeholders who are not being Agile limit a software development team’s ability to do Agile:
- Managers who are more comfortable with the Waterfall method refuse to allow software development to begin without a sign-off on the analysis and design stage.
- Department heads refuse to accept changes to the originally stated requirements because it might impact project timelines.
- The customer liaison refuses to engage the client in software reviews until the product is complete and ready for deployment
All of these actions run counter to the principles of the Agile manifesto, and the practices of Agile methodologies such as Scrum, Kanban and SAFe.
Organizations may say they are Agile but in fact they are doing some unproven combination of Scrum and Waterfall. This approach typically fails.
Agile can’t simply be thrust upon a development team without an Agile transformation taking place in other parts of the organization. You can’t do Agile properly without also being Agile.
Five steps to being and doing agile successfully
For those who believe being Agile and doing Agile properly is worthwhile, follow these five steps:
- Have all members of your team read the Agile Manifesto
- Seek ways to solve problems by applying Agile principles and Scrum values
- Make the continuous delivery of software to the client your team’s highest priority
- Adopt an Agile methodology like Scrum or Kanban
- Push for an Agile transformation throughout your company
Being Agile while doing Agile is the best way to develop modern software.
Abide by the Agile Manifesto and stay true to your chosen software development methodology, and the successfully delivery of software to satisfied customers will be the result.