Just what is Agile anyway?
I feel that I am often guilty of making an assumption that Agile is the best approach to software development in general. Recently I’ve been considering if it really is the best approach for a lot of teams, how it fails and why it fails. If, when it does fail, that was a failing of the team to implement it correctly or if it’s more than that, if perhaps Agile wasn’t the right tool for the job in the first place. When it fails, which it does sometimes, the argument often seems to come down to “Agile doesn’t work (at least not for everyone)” versus “you’re just doing it wrong”.
The first thing to consider here seems to be how we define the term “Agile” with relation to software development. When trying to define Agile I always am brought back to the Agile Manifesto, after all, if this can’t be held up as a definition of Agile then what can? There’s surprisingly little in here, it makes no mention for instance of story points, stand up, sprints or many of the other ceremonies and ideas commonly associated with Agile Development. What it does have is some simple guidance around collaboration, working iteratively, and prioritising getting working software out the door over getting bogged down in “the plan”. Sounds great, what could possibly go wrong?
A more realistic definition?
The Agile landscape can be confusing. People often use Agile and Scrum interchangeably as though if you are doing Agile development you are, by definition, doing Scrum. A quick glance back at the Agile Manifesto shows us that this isn’t really true and that there’s a whole load of stuff that comes with Scrum that is simply not needed in order to be “Agile” by that definition. That said there is, on the other hand, a general acknowledgement I think that most teams are doing a variation of Scrum, Lean or Kanban styles of Agile. So if we are talking about what is and isn’t Agile, then there is an argument to say it’s more helpful to acknowledge this is what people tend to mean when they use the term, over sticking rigidly to the manifesto definition. But that’s not even the end of the story, it’s also true to say no two Agile teams will be exactly the same and that each team will have its own take on Agile, often based on one of those three popular variations mentioned above. Indeed, one of the main philosophies of Agile is being adaptive to change and to just do what works over following a plan. Easy then to see how all this can be somewhat bewildering when trying to pin down what we mean by Agile Development or get started implementing it.
Where to start?
This I think leads into where teams can start to struggle implementing Agile. If you are looking to start using Agile Development, it can be very hard to know where to begin. This can be especially true when you or your team has little experience with Agile to begin with. The Agile Manifesto isn’t much help here of course, four short statements prioritising one thing over another isn’t much of a guide to getting a project off the ground (nor is it meant to be). This is where Scrum can come in, Scrum has a handy guide, there are certified Scrum Masters to help out and it’s widely used in industry. It’s easy then to see why it’s a popular starting point if you’re looking to create a new Agile team without much prior experience.
Scrum is fairly prescriptive, it builds on the Agile manifesto and goes further, laying out a set of roles and events to apply in day to day development. This might work well for you and your team but then again it might not. If you are not prepared to move away from what’s written in the guide if it isn’t working for your team, then there’s a good chance it won’t succeed for you long term. On the other hand, if you don’t have some guide to follow but just some high level ideals to guide process, it can be hard to get started when you don’t have much prior experience to lean on.
The problems with sticking to the plan
What’s important then when starting off with Agile? Why do projects struggle and why is there so much confusion and argument about how to get it right? I think the hard truth here is that following any given strict plan almost certainly won’t work well for your team long term, even if it works initially. The Scrum guide is just that, a guide, rather than a strict how-to. A healthy Agile team is going to take a little time to find its groove. There’s no easy way of telling what process you should adopt upfront; rather, you will need to just pick a starting point, probably based on something like Scrum or what you have experienced in other teams but then allow the team to mould the process by trying new things and dropping things that are not working. Don’t be tempted to ring fence particular things from being changed either. For example, maybe you strongly feel that stand-up is important but if the team votes to drop it or change the format you should at the very least be open to trying working without it for an iteration or two and see if things improve. The less the team has the ability to change things the harder it will be for them to find their groove and create a process which works well for them. It’s also important to remember that as the team and the project changes, so too will the processes need to. So even if you have found a great way of working for the time being it will probably need to evolve over time as the project and team members change.
It doesn’t matter how you start off or even where your team is right now. If you’re setting things in stone you’re lining yourself up to fail. Agile teams regularly reflect on where they are and make changes in what they’re doing and how they work to match that. This aspect of Agile is far more important in my opinion than the ability to absorb changes to requirements at any stage in a project. The team needs to regularly be looking at the processes and ceremonies they have and asking what the value is for each one. If it’s helping you deliver quality software or if it’s using up time. What would happen if you try something new or even just stopped doing a thing? Changes in process can be a bit disruptive but if you drop let’s say, stand-up for a week for example, the project is unlikely to fall apart, and if it does you probably have bigger issues. If things get better you don’t go back, if it’s worse you just put it back and try something else. The important thing is that it’s the core team who makes those calls, not managers, Product Owners or others outside the core team. The team needs to be empowered to make calls and actively take on ownership of how they deliver software.
The importance of self organising teams
It stands to reason that Project Managers will be heavily involved in setting up new projects, teams and processes, that is after all their domain. What I think is important though is that once the team is up and running that process is then handed over to the team. I believe self organising teams is one of the most important factors in a successful Agile team. It allows a team to be truly Agile in the sense that they can adjust and reshape their ways of working as the project evolves. It also embodies trust, i.e. when management trusts a team to be self organising, they get the most out of that team and the team develops a feeling of ownership and pride in their work and processes. It encourages the team to not only point out what isn’t working but to be proactive in imagining what improvements could be made and how things could be better. That’s not to say there is no requirement for a Project Manager; rather, the core team’s ways of working and ceremonies should be owned and managed by the core team.
Agile and teamwork
If we take a look at the Agile Manifesto again it is, like I said earlier, just some general advice on what to focus on when developing software. I believe that the Agile Manifesto and Agile development in general has strong ties to teamwork, good Agile teams are good teams in general and Agile is a key part of facilitating that teamwork. In my opinion great teams have the following properties: strong communication coupled with a clear hierarchical structure which utilises delegation to promote and facilitate independent, creative thought and initiative. Let’s break that down a little bit, if we look at the items on the left of the Agile Manifesto, two of the four (“Individuals and interactions” and “Customer collaboration”) are around communication, along with some of the principles. A lot of the common ceremonies we associate with Agile are built around the idea of facilitating better communication both within the core team and with others, such as stand-up and sprint demo.
It’s important in any team that someone is in charge of the final decision on things, able to drive things forward, keep an eye on the bigger picture and resolve stalemates. This may be a different person for different issues in larger teams but that person needs to exist. Self organising teams is not about removal of that leadership but instead about delegation of responsibility for the day to day process of the team to the team itself. It encourages independent creative thought and a sense of shared ownership of process by the team. When a developer picks up an item of work they are expected, to a greater or lesser extent, to own that piece of work. Giving a developer autonomy in how they implement the work and drive it forward to completion encourages a sense of ownership and pride in that task. As a result, a developer is more likely to bring their creativity and initiative to bear in implementation and to ensure it’s of high quality and tested. This, coupled with an environment where they are encouraged to lean on the rest of the team for help and use the team Lead to unblock problems where there is no clear path forward, enables people to do their best work. In the same way, we should be providing the team as a whole with the autonomy to develop their own processes in an environment where they can lean on each other and look to a Project Manager to help guide and unblock process related issues where there is uncertainty. This ultimately will enable them to bring their collective creativity and pride to the development processes as well as individual tickets, producing the best results.
Why Agile can fail
Why does Agile fail then? Probably for a multitude of reasons, but I suspect that, ultimately, one of the main reasons is a failure to adapt processes, i.e a failure of the team to change their ways of working appropriately to suit the current circumstances. This may manifest in various ways, such as teams sticking religiously to processes and ceremonies that are not adding value or worse, actively detrimental to progress and morale. It may be that teams are too cautious about trying new things and new approaches or that they are actively blocked from doing so through not having true ownership of those processes. They may be struggling to identify the things that are causing issues due to a lack of regular reflection or because people do not feel empowered to point out where the pain points are. Whatever the reasons, in the end the result will be the same, the development process will falter and team morale will suffer. If the ceremonies and processes that are commonly associated with Agile are seen to be part of the problem, it’s easy to see how Agile as a whole could be given the blame when things go wrong. Another potential pitfall can be attempting to either scale up one teams successful implementation of Agile to multiple teams or else, create a standardised Agile approach which is mandated to all teams. Either way, creating a uniformed Agile approach again, prevents the team from being able to modify their own processes. In this scenario, as before, Agile maybe seen as the underlying issue when problems arise when in fact it is this “prescribed Agile” approach which is preventing the team from adapting and responding to change.
Is Agile always the best approach?
Is Agile the right fit for every project? No, probably not. However, if the question is “can Agile be applied successfully to most software development projects?” I think yes, in my opinion that still holds true, all things considered. The super important caveat here however is that I believe this is true only for a given definition of Agile. That definition being the high level Agile Manifesto definition we talked about earlier, i.e being Agile in the sense of aligning the team’s ways of working with the Agile Manifesto and principles. I think that the Agile Manifesto and the twelve Principles behind it remain good solid advice for software development and that the majority of projects can benefit from working in an collaborative, iterative manner, utilising self organising teams who regularly reflect on their ways of working and adjust to suit the current circumstances. I do not think that Kanban, Scrum or any other given frameworks will always be the best approach for most projects, nor do I think that any single rigid process will work well for a team indefinitely. Teams change shape, size and goals regularly and a successful Agile team needs to have both the will and the power to adapt with those changes.
