Make Agile work for you – balancing methodology and momentum

First things first, we love Agile methodologies. Like any right-thinking digital team, we use some form of Agile of it on every project we’re involved in.

The web is already awash with how-tos, and guides to improve the running of your project, so we won’t try and do Google’s job there.

Instead, we want to talk about our approach to Agile, namely how it isn’t a one-size-fits-all approach to all your problems.

We wish it were, obviously.

Make Agile work for you

By now we’re sure you’re all pretty well acquainted with the doctrines of strict ‘capital A’ Agile. Perhaps you’ve already run a few sprints and met a scrum master or two in your time. But how should you use Agile processes to actually be agile?

Remember that you have to make methodologies work for you, not vice-versa. The way you work should suit the project – spending countless hours and headaches forcing your project to ‘be Agile’ defeats the object.

We get that sometimes it’s tempting to follow a methodology like a religion, but it’s important to not get lost in the process and keep focus on the bigger picture.

At Lighthouse, Agile project management takes different shapes and sizes depending on the project that we’re working on. Never be afraid to adapt!

Don’t get lost in the process

Rather than get bogged down in whether you have the right process in place, it’s better to boil it down to one simple question:

Are we making enough progress using our current project management workflow?

If yes, then great. You win! ??Keep doing the right stuff.

If no, then why not? Slow progress can be down to lots of things, but too much time spent in meetings, workshops, standups, and retros is a common blocker to actually doing work. How many check-ins are truly necessary to make the project work smoothly?

A big problem that comes with being too caught up in bureaucracy is that time increases exponentially and leads to higher costs.

Strict Agile brings a well-defined and implementable process, but it can also bring baggage. Try to be too rigid and you might find that you’re putting barriers in place of actually getting things done.

Sharing progress, reviewing regularly, and being open about what’s going on is great, but you might have just added another five meetings into people’s diaries that could have been used to do solid product work.

The stricter you are, the more unexpected red tape it can add.

If teams follow Agile religiously and let the process get in the way of progress, it ironically becomes a contradiction to the very nature of agile working.

Lighthouse and Agile

Let’s illustrate our point with a couple of real-world examples.

Our work with DCS sees us collaborate with seven teams spread out across Europe working across multiple products. Each team has several members with varying roles: designers, product owners, business analysts, developers, and Scrum masters.

A project this complex needs a well-defined, strict process to keep it running smoothly and to make sure every different team gets what they need when they need it.

We run the whole lot – sprints, retros etc. – coupled with detailed PI planning to figure out workloads for all teams weeks in advance.

The pros here are that things would literally fall apart if we didn’t do this. Pretty soon we’d see huge cracks starting to appear and productivity would slow down without the visibility and regular communication that this process brings.

The flipside is that we spend a lot of time in meetings and calls but it’s a necessary by-product of the way this project needs to work.

The pains (and gains) of managing a multi-brand UI design system ??

Conversely, our work with PayPoint was with a smaller team but one who wanted to see results quickly and didn’t have lots of time outside of their main role within the business.

Full Agile would have been a disaster, no one had time for that.

We scaled back the in-week scheduled touchpoints and put basic rules in place around presenting designs and receiving feedback to manage expectations from both sides. While this wasn’t capital A agile, it was a form of agile that served the problem and helped us find a solution.

Adapting the way of working depending on the type of project, team and technology we’re working with has proved to be time and cost-efficient, providing great outcomes.

Conclusion

Work Agile. It’s a tried and tested way of running a successful product team, and you’re never going to hear anything different from us.

However, it’s all too easy to read the book and think that this is exactly how you should implement the strategy within your team, getting hung up on following it to the letter.

If it’s not working for you and the method is blocking the outcome, then it’s time to rethink how Agile serves you, your team, and ultimately your clients.

Real agility comes from getting rid of that stuff that doesn’t serve you anymore.