Co-Founder Taliferro
Introduction
I was talking with a friend about agile development and how Procedure can sometimes slow you down. We were talking about this other friend who's been working in an agile environment for years now, and he just couldn't figure out why things weren't moving as fast as they used to. He was frustrated because he felt like his team wasn't getting anything done anymore. Still, I pointed out that it's called agile development for a reason—and that reason is flexibility.
Flexibility
Agile development is about flexibility—getting out of the way and letting the developers do their thing. However, there are some things you might want to consider when looking over your agile methodology with an eye toward improvement.
Agile development is a term that gets thrown around quite a bit. It's not uncommon to hear someone describe themselves as an "agile team" or to see a company proudly boast that they're practicing "agile." But what does it mean, exactly?
Simply put, agile development refers to the philosophy of being flexible and adaptable in response to new information or changing conditions. It's a mindset that promotes iterative planning, implementation, and review cycles and emphasizes collaboration over top-down control. This can be applied within small teams or entire organizations; but at the end of the day, it boils down to:
- Agility: The ability of something (such as an organization) to respond quickly and effectively when faced with change
- Adaptability: The power of an entity (like an organization) to adapt itself continuously by taking advantage of opportunities presented by its environment
You need to be willing and able to develop quickly, change direction at a moment's notice, and get out of the way of your developers and let them work and do their thing.
Agile is a methodology, not a process
The word "methodology" comes from ancient Greek and means "a way of doing things." So when you're talking about Agile, you're talking about how to get things done efficiently—which means changing direction at a moment's notice or even running sideways out of someone's way if they need to work fast on something else. This isn't always easy for people who are used to following steps and ensuring every box gets checked before moving on. But in Agile, there are no boxes; there are only outcomes that we all agree upon and commit to achieving together as a team (hence the term "teamwork").
But other people don't just have to 'let the developers do their thing'
Agile development is a team effort. This means that many other people on your Agile team don't just have to 'let the developers do their thing.' These folks are responsible for planning, scrum master duties, and more. In addition, if you're working in an enterprise environment, you may find that there is a separate Operations team who does not always align with your development process or goals.
The best way to get an agile team moving quickly is to let them do their thing without getting in the way. The worst thing you can do is interfere with them and cause friction between you and your developers.
Agile software development is about teams working closely together on a project. It's about communicating regularly, sharing knowledge and expertise, building trust with each other, and approaching problems from different angles.
It's not about checking up on people constantly or micromanaging every process step. Agile teams are self-organizing—they shouldn't need someone else directing them at every turn because they're a team built on collaboration and trust.
You might want to consider many different things when looking over your agile methodology with an eye toward improvement. What steps in your process add value, and which ones could be removed? Are there any steps that could be combined? Is there a way to make the process more efficient?
If you're doing something that doesn't add value to the process, it's probably time to reconsider it. Is this Procedure or practice adding value or just taking up time? Changing things up may be a good idea if they no longer benefit your team or company.
Ask yourself whether there is any reason that this step is necessary or if it's just there because some corporate bigwig decided they wanted it implemented without knowing why they were asking for it.
Ask yourself how long each of these steps takes and whether or not each step is essential.
Also, ask yourself if the steps are being completed as efficiently as possible by everyone involved - including developers and QA testers - or if any actions are redundant since multiple people are doing the same thing at different times of day (or week).
If the answer is yes, try to reduce time spent on this step by finding alternatives, such as shortcuts and hacks, to get around them.
Perhaps most importantly, ask yourself whether the time you spend on this step or process could be better spent elsewhere
The end goal of Agile is to make sure that you are working on the most important things. This means that you need to be able to focus on the most critical parts of your project and not get bogged down in the little things.
It's easy for teams to fall into a trap where they become too focused on the process rather than the purpose, which will ultimately slow down your development and hurt morale. Instead, remember: don't let the small stuff get in the way of bigger-picture goals.
Your developers will thank you for clearing away obstacles to their agility
You'll be happier, the developers will be happier, and the business will be happier. Sometimes you may move faster and get more work done.
You may also find that your reputation as a leader is enhanced as well as your ability to lead a team through change.
Conclusion
So, there you have it. If you can remove the procedural obstacles standing in your way, you'll free up the time and resources to be more agile.
Tyrone Showers