“Agile” has become a buzzword over the years and has even made it into marketing content. Every business wants to be more agile and efficient, so they design agile development process to empower teams.
Software development teams that follow the Agile philosophy are expected to deliver more value rapidly and regularly. But it really comes down to reducing the cost of change and the uncertainty associated with it.
This opportunity to empower teams doesn’t have to be limited to technology teams as the same principles can be put in practice in a variety of scenarios.
The original Agile Manifesto was written 16 years ago and features 12 principles. Out of these, there are four comprehensive principles:
- Work on software over comprehensive documentation
- Interactions and individuals over tools and processes
- Respond to change over following a plan
- Collaboration with customers over contract negotiation
When you try to put these principles into practice, the following question is usually coming up: Is the team being agile or doing agile?
While differences may seem subtle, they are actually enormous. It’s important to clearly define the two before you try to implement the agile way.
Being Agile
Being Agile is more about who we are. So it has to do with our consciousness, organizational culture, and the team’s mindset. Being Agile is also about how we perceive ourselves, how we relate to each other, what we value, and how we behave.
When the team is “being agile,” we are really looking at it from a psychological point of view. If everyone in the team is on the same page and mentally healthy, it can only mean more efficiency and effective delivery.
While “doing” is more about getting things done, “being” is more of an abstract idea. It has nothing to do with applying a process to make changes, it’s more about reinvention.
Doing Agile
Doing Agile is focused on practices, iterations, user stories, and much more. There are some significant benefits in doing things the agile way because it’s all about getting the work done in a systematic manner.
You may want to read: My recipe for successful offshore Agile team management.
When you’re doing agile, you’re usually looking to solve an immediate problem. But to do this effectively, you have to first understand the culture and then build systems to sustain and support long-term agility (so “being” creeps into the “doing” side of things).
Some view “doing” as nothing more than checking the box once you have completed something that was required. “Being,” on the other hand, forces you to understand why you’re being agile. It gives you a purpose and motivates you because you understand what it all leads to.
When the whole development team is motivated with purpose, you have the potential to achieve great things. It will also save you the time and money that’s often wasted on uncertainty.
Since the Agile Manifesto was released, many talented developers found a way to build better software “under the assumption of change.” It’s important to have a clear grasp of what it means when the manifesto talks about doing things “under the assumption of change.”
Agile is all about reducing the cost of change and uncertainty, so if there’s little uncertainty and little to change, this approach will be completely wrong for your development team. Instead, an optimized system that helps you enhance reproducibility and reliability will be more suitable.
Although there are some that loath the agile philosophy, it’s still a good idea as it addresses the psychological and physical aspects of efficiently managing a software development team. Programmers like things to be well-defined, so telling someone to just “be agile” won’t work.
A clear connection must be made between the principles in the manifesto and your expectations. As a result, the success of the agile method will ultimately come down to the role played by the management or leadership within the team and the organization as a whole.
Agile principles are now losing their value because they have been applied incorrectly by a way too many organizations. The primary reason behind failed implementation is a lack of understanding.
When it’s understood and implemented correctly, you can eliminate all the nonsense that happens in the name of project management and consistently deliver something great.
