Want to hear a joke? What do you call a process that has multiple complex steps, requires detailed explanation and dogmatic adherence to rigid tenets defined by expensive consultants? Agile. Or at least, that’s the way it feels in 2017. If you aren’t using story points, spending hours building a backlog, reviewing burndown charts and using appropriate terminology, you’re “doing it wrong.”
The entire thing makes me feel exhausted and locked into a process that doesn’t feel very agile. The authors of the original Agile Manifesto never intended for it to feel so restrictive. In fact, not too long ago one of those authors revisited the whole thing. He suggested a return to the basics and a simple workflow that involved just four steps.
- Find out where you are
- Take a small step towards your goal
- Adjust your understanding based on what you learned
- Repeat
And “When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.” As the expression goes, everything else is just details.
A Disciplined Approach to Iteration
This doesn’t mean working with agility is without discipline—quite the opposite. You need to be extra dedicated when you examine your past progress in order to improve. It also requires that everyone on the team be willing to admit when they are wrong, which is a tough sell.
Discipline is especially important to have as you add more projects, as it can be easy to fall back into a particular system or methodology as work intensifies. However, while systems can be good, they are by their very nature generalized. The same one may not work for every project.
Let’s use meeting cadence as an example. When we start a project, we tend to have standup meetings every day. This is a standard standup meeting: Each team member tells the team what they worked on, what they plan to work on and if they have any blocks.
However, as our team members become more comfortable with each other, these discussions begin to happen in chat or in person during the day. It became apparent that the standups were becoming a rehash of what was already happening. We realized this and cut the meetings back to three times a week, then two. The nature of the meetings also changed as they became more about overcoming blocking issues and handling potential blockers.
In this scenario, continuing to follow standard scrum principles would have meant an unnecessary interruption in the team’s day, and everyone would have been bored. But reviewing our processes with an agile mindset made the decision to change easy. Best of all, if the change to the meeting had been wrong, we could have easily reverted to our daily standups. That’s the benefit of having an agile mindset vs. adhering to an agile process.
Now, we don’t do a formal review of our processes; there just isn’t enough time for that. We do, however, give our team the autonomy to question processes. And it was this that enabled us to realize we were repeating ourselves when a team member brought it into question. And that’s a key part of an agile mindset: empowering your team to make this kind of recommendation, and then listening to them and acting on it.
Building on the agile cornerstone allows you to iterate in other areas too, not just meeting schedules. Is your estimation constantly failing? Change it. Try to improve it, just a little bit, and go from there.
Remember, if you try to throw a complex version of an agile methodology at a team, it will take longer to implement than it would to start simple and iterate. As John Gall said, “A complex system that works is invariably found to have evolved from a simple system that worked.”
Gaining Team Buy-In
Getting team buy-in to this change in mindset can be difficult at first. People tend to like systems, even if they’re cumbersome. Overcoming the “that’s the way we’ve always done it” hurdle can be challenging. It requires management to understand their team and how each person works. That kind of trust can take time to earn.
Since developers tend to view things through a coding lens, consider explaining your processes in their terms: We refactored our meeting process and reaped benefits similar to the benefits you reaped from refactoring a codebase. If a developer doesn’t get excited about the prospect of refactoring the entire process, then you might have a different problem on your hands. That kind of iteration benefits the team and the project.
In larger organizations, it also can be difficult to get executives and clients to agree to work more loosely than they are accustomed to. And when the pressure is on, chances are they will try to revert to what they are most comfortable doing, which often involves poor collaboration and a “just-get-it-done” mentality. This can lead to burnout. It is up to you as the service provider to guide them on the proper path.
Fortunately, if you are improving, your productivity will increase. If future change is easier, it will be faster. When clients see that outcome, they will trust you more. It then becomes a virtuous circle, but must still be continued.
When The Agile Manifesto was written, it was a shot across the bows of all kinds of software projects. However, it was written to describe systems, not to prescribe a single system for all cases. If you fall into that pattern, you won’t reach your peak performance.
