A term that gets thrown around a lot nowadays in our digital industry is ‘agile’ and you have probably been asked things like “have you worked in agile?” or heard “let’s go agile” and “if we worked agile it would’ve run better”.

Having worked in multiple teams and agencies that have added agile working to their selling pitch, I’ve become more and more aware that even if we try to follow agile principles it might not work out to be the best thing to effectively run our work streams as we may just be following processes for the sake of ‘being agile’ or even worse disguising waterfall as agile 😱. So, I have come up with a radical way to approach this and here it is….

F*CK AGILE. BECOME AGILE.

Now I know that might sound absolutely bonkers but hold on let me explain. I’m a big advocate of the philosophy of working agile and what it means to be a fully autonomous agile working team, but I feel in the age we are in, we are slowly branding agile as simply a ‘process’ when in fact agile is a practice-driven way of working that empowers teams to effectively and efficiently work better together to continuously deliver value.

In my personal opinion, we should be striving to inspire teams and individuals to adapt the agile philosophy to their core values, take from it to make it their own, continually moulding it into what works best for them and their projects to primarily get shit done instead of forcing a process that may not necessarily work for them (cough daily stand ups cough).

So, you’re probably thinking okay this guy is making a little sense, but how do we become agile then? Well it’s your lucky day! I’ve broken it down into 4 quick actions that should hopefully help enable you and your team to better work in a truer agile form. I would also like to stress for you to be agile (lol) here and implement whatever you want in whatever priority is important for you.

Be flexible

This has to be number one on the list. Being flexible enough to react to new insights, opinions and data; just because you’re currently doing something doesn’t mean it can’t change, things may come up that shift the end goal or change how we perceive a problem. We as individuals and teams have got to be able to adapt to those changes quickly – if that means designing a new screen, developing up the new transition or whatever it may be, be flexible enough to pivot on it and own it.

This also comes with not getting so locked into strict sprints/fixed terms, set budgets, and fixed scopes. Empower yourself to be flexible enough to challenge these factors and adapt accordingly to whatever delivers the best value for your users/customers.

On the back of that we should also be flexible enough to give a hand to fellow team members even if it’s just advice, feedback or even helping with a prototype, it helps so much! By helping out one person in the team and allowing them to move more freely in a sprint it results in the entire team moving more freely, more effectively and having a much higher morel level by burning away some of the stress in the thighs for the entire team as a unit.

Get shit done

A lot of people will brush over this one like “yeah it’s an obvious” but the fact is a lot of us (confessing that I also fall victim to this sometimes too) take a considerable amount of time just getting stuff done from time to time; which may be due to frequent coffee breaks (fika in Sweden), browsing the web for random articles (like this one) or procrastinating on ideas on how to do things because “we have time this sprint..”.

I’m not saying we shouldn’t do that but hear me out, if we focus and dedicate time to really ploughing through work and getting it done as soon as possible, the reward of taking that time to have that relaxed coffee break for some pure bants is so much more well deserved and also gives us an opportunity to deliver more afterwards (your’ll also find you could squeeze a lot more in).

If we have the capacity to do another task then heck why not? Get shit done.  Sometimes that may mean skipping some of those meetings about meetings you have booked in to focus on delivering actual work, top tip – YOU CAN AND SHOULD DECLINE (some) MEETINGS.

By moving fast and immediately, we can run through the Kanban board waaay faster, allowing us to deliver real user value quicker with more time to work on the next priority. Saying this though it’s very easy to burn out if all we do is get shit done, so I would heavily still advise rewarding yourself with time away from the screen. ­­

Smash that KANBAN board Bruhhhh!

Question, question, question!

I’ve found throughout my career a lot of people shy away from asking question whilst decisions are being made or whilst work is being done. The statement “we should have done XYZ or XXX” only arises right at the end when it’s too late. We could avoid this problem and operate more efficiently by constantly questioning what we’re doing, why we’re doing it, and what value it will bring to our users at every phrase of our product development.

“Question everything. Every stripe, every star, every word spoken. Everything.” – Ernest Gaines

Common questions in our industry may sound like, “why are developing native and not react?” “why are we not designing mobile first” “why are we not validating this need before designing it” “is this really needed?” etc…

If we can’t justify what we’re doing then we should be empowered to pivot onto developing something that will bring real value to our users.

Throughout product phrases we have to ensure that we are always adding value to our product not just in the now but also the next and future states of our product; which we can achieve by constantly questioning the next priorities and questioning the future of what we see the product becoming.

If it didn’t work, do it differently

Constantly evaluating your team’s and your own effectiveness through practices like retrospectives is crucial to a team’s constant progression and opens up opportunities to mend weak points. Through weekly evaluation and reflections, we can find out if things are working and if we find out they don’t? Bloody change it! Don’t be afraid to trying things differently, it’s all part of being agile! Maybe you use a different method for handovers next week, maybe we use a different coding language or different design software, whatever it is – improve.

Once we start saying no to change we will limit ourselves to repetitive failure or undistinguished success; we have to be agile enough to say fuck it, let’s do it differently this week and if it works well BIG WIN! Continue with it till it fails and repeat; failure should be embraced as opportunities to shake up the process to improve weak points.

The take away

Embrace the challenge of being free to pivot and flexible enough to absorb and adapt to tasks and constant changes, whilst still being able to get shit done fast and to quality. Don’t see agile as a strict disciplinary process to achieving goals, but more a tool that empowers us to deliver faster and better.

Whatever helps you meet user requirements and add value the fastest and most efficient way – Do that!

Props are due to where props are due:

My true agile awakening has been due to the incredible transformation team at AKQA, which I have been lucky enough to be a part of and witness.

Various talks from the likes of Eric Ries, Alistair Cockburn and many many more…

Peace.