Agile has taken the world by storm… but many of us are left scratching our heads about whether it will suit our team. To help weigh it up here are some of the pros and cons of Scrum and Agile practices.
The Minimal Manager
Agile has been the latest flavour of project management practice for the last 10 to 15 years. Developed out of the need to handle ever-changing requirements in a fast-paced digital world, Agile practices have become widely adopted in managing projects across the globe. We are also watching the development of Agile into more than just software and digital projects with Agile in ITSM becoming more of a focus.
Despite the big push towards more practical tool kits for project management, there remains a large number of naysayers who won’t make the jump. Agile like any framework isn’t perfect and requires adaptation and it’s own challenges (see the article https://thelostmanager.com/2019/09/03/why-agile-doesnt-work/). Although it ultimately will take work to find out what exactly is going to work for you here are some of the pros and cons of Agile that might help you in deciding if you are going to give it a try.
The 5 Pros of Agile
1. Encourages Frequent Communication
I’ve seen it with my own eyes. People hide behind instant messengers, office partitions and unconnected headsets just to escape the frightening thought of discussing their work with their colleagues.
Although it’s a stereotype, I would have to say that most technically gifted personalities can at times struggle to communicate effectively.
Some of the structure and common practices encouraged by Agile such as daily stand-ups, sprint planning and sprint retrospectives do help encourage communication and also make it okay for everyone to have a voice. Often the “production” team who do the work don’t get the chance to have a voice and with Agile, they have the majority of the voice as oppose to traditional methods whereby it’s more likely a directive from the requirement setters, a.k.a the product owner.
2. Team Ownership
As a manager, one of the hardest things to do is getting the team to take ownership. Another key strength to Agile practices, is that the team are encouraged to take ownership. Through the estimation and planning practices it is no longer a directive of who will take on what parts. rather self-proclaimed ownership to share the tasks in the backlog and break them down to pieces of shared ownership.
Not only do the team speak up about who does what, but they also provide their estimates and timelines to it and make a commitment to what they complete by when. If you are using sprints then a sprint review covers what was and wasn’t completed and why and then enables the team to voice, collectively, what they need to do to improve. With Kanban, there is crowding to resolve issues and so there is nowhere to hide if something isn’t moving.
The honus of completion and improvement are now on the team and the team members rather than on the manager
3. Achievable Goals
The scope and scale of a project are often where projects get off on completely the wrong foot. When people blow out the scope of what they are trying to achieve they can over-complicate starting and making progress with trying to achieve things which have less importance.
An extreme example to compare could be trying to build a website. Rather than getting a page with plain text running and a rough layout, if you fully design the whole page and then get bogged down into how a person will act securely with the page from day 1, you could find that this discussion stretches on until your there on day 20 talking about security best practice prior to even getting that design together. The issue with getting bogged down in irrelevant detail is that once you start to build the page you may realise that security best practice may need to change according to how you progress. The fact that you may need to jump through all of those hoops of approval may cause you to simply lose momentum.
Having a task broken down into something small and achievable has a great effect of feeling the satisfaction of achieving and then moving on to the next item. It also allows a quicker review of what you were thinking faster.
4. You plan more than other methods
I always remember when the world shifted from Waterfall methodologies to Agile practices the biggest rant from traditionalist was that it was crazy to start anything without thorough planning.
If you’ve read my other articles my view aligns with most Agile advocates, although I am still open to whatever works, that Waterfall planning almost always ends with failure in the long run.
The truth is that Agile forces you to do just enough in-time planning to start but also forces you to plan more frequently… at least in regular sprint periods if not daily.
With Agile you adjust backlog priorities as new findings arrive and the team are constantly talking about the new priority list. If the product owner can see an evolving development they also shift their requirements to the most important items for a minimal viable product so that the plan adjusts to what is most apt.
5. Fail faster to succeed
Agile’s greatest benefit for my mind is that it allows teams to fail faster. If we can fail fast we can learn and adapt quickly. Agile allows you to learn quickly by attempting and adapting through short successes or failures. With long drawn out pieces of work, there is no way of knowing if something will work.
Breaking down tasks into something more achievable we are also able to learn quickly what isn’t achievable. If we work in a 2-week sprint and that work leads nowhere the most we have wasted is 2 weeks. The danger in longer running projects, where resources are dispersed and not aligned within a team with a common 2-week goal is that the work can potentially stretch on for long periods and we could find out that failure point over a much longer elapsed period.
Failing fast is a great way to learn what will work and Agile practices support this.
The 5 Con’s of Agile
1. It can be ironically very rigid
If you are a stickler for doing things by the book then some would argue that Agile is perfect for you. You can transition from rigid ways of thinking in other practices to rigid ways of thinking within the Agile world. I’ve been a lot of places where Agile practices are turned into stringent methodologies and frameworks. Ceremonies that added no value were enforced, pointing systems that don’t quite work were insisted upon and eventually everyone lost motivation.
Sometimes it can be hard to break away from what Agile textbooks, coaches and guidelines prescribe because it feels like the process will break easily. That said Agile is meant to be exactly that, flexible. Agile is actually a set of beliefs and principles rather than prescribed rituals. But I’ve seen these rituals sometimes beaten into people and like most processes they are done for the sake of doing them.
If you get too far into the rigidity of practising elements that don’t work Agile could start to fail or cause some serious delays and impacts to your projects.
2. Needs training and time to work
Agile requires some level of training and experience to work within a company and within teams. If there isn’t some level of training delivered around Agile, even if it is only to a portion of the team, and you try to implement it, grasping the concepts can be quite difficult.
Remembering that change of any kind can be challenging, the introduction of a new system for an entire team or company isn’t necessarily going to be easy. Equipping the teams using Agile with the knowledge of how it works, the benefits of the principles is the key to making Agile work. It’s important that the training is not focused only on the teams but also the product owners/managers and the business owners if they drive any requirements for development teams.
Even after the training, trial and error and time to adapt will be important for everyone. Persist in making it work and making the right changes where you need to make it work. Introducing Agile may initially provide more teething issues, but sometimes you need to take a step backward to move forward.
3. It requires buy-in
Related to the training and time to work, the adoption of Agile is the key to making it work. You could argue that for any method you need the buy-in from everyone to make it work.
This generally means that this adoption and support should start from the top. If the leadership isn’t behind making the system work then it won’t trickle down and be supported throughout the business. So the key is getting buy-in across the whole company on as many levels as you can.
Buy-in is all about getting people to support the process, demand the correct behaviours around backlog items, protecting sprints, planning, retrospectives and stand-ups. If there isn’t the right support throughout the structure of the business just like anything you will run into roadblocks and the process will be blamed over the people.
4. Agile isn’t perfect
It may surprise people to hear it, but believe it or not, nothing in this world is perfect. Agile has a lot of drawbacks.
If the business can’t adapt around deadlines and resourcing then you will face challenges in resource management, long term planning processes and more. You may need to find other ways to manage this or get creative with how you can do this and this means utilising, customising or inventing other systems to accommodate this.
No matter what you use, you will face challenges and I’ve never seen a method out of the box that will solve every problem you face in running a project or delivering a product. Agile gives us a nice framework to work within but be okay with the fact that nothing is perfect and it’ll take time to mould Agile to be what you need it to be where you are.
5. Agile is not the silver bullet
I’m not trying to be repetitive with the cons. This is somewhat different to point 4. Agile is not a silver bullet, meaning that if you have dysfunctional teams, people and management Agile will not come in and resolve anything. All it will do is shift your problems.
If however, you have a pretty conscientious team and management, willing to take strides to make something work, Agile can assist if you run into frustrating roadblocks of missing requirements, miscommunication and inefficient delivery. Agile will assist in improving these areas over time if you are all already bought into improvement.
If management and leadership make unrealistic demands without hearing the team already, then Agile might assist in some respects, but it could also leave you in a very similar situation.
So what now…
Well, the truth is only you and your teams will know if Agile can work. The worst thing you can do in a situation is to keep doing something that isn’t working without making a change. If Agile might improve the situation then utilise it to open up some doors for positive change and see whether that can push you forward. Start small, with one project, one team and see if it makes inroads. If it doesn’t rethink and work with that team to talk through what to adjust and try again… Nothing is perfect but something is always better than nothing.
The Minimal Manager 
Leave a Reply