Agile methodologies and their application is a topic that you could write (and people have written) copious tomes on. I’m not going to regurgitate all that. Why? You don’t need it. You’re smart – if you can make sense of this, you’ll work out pretty quickly what's important here.
So why write this ? Because I have had this conversation three times in the last week with three different teams, and it will be easier to point people here than explain it again next time. Yep. Lazy. : )
Let's start by looking at the word itself: ‘agile’ is a French word derived from the Latin ‘agilis’ or ‘agere’. Roughly translated it means “to do, to perform, to be in motion, quick, nimble”. You get the drift. And yep - I regret not listening in Latin class right about now and had Google that to confirm. Thanks, Big G.
In terms of projects and delivery, an Agile approach covers a bunch of frameworks that we won’t go into here as they apply largely to software development (Google 'Kanban', 'Scrum' etc if you must keep reading to satisfy that yearning).
The idea is that these frameworks are founded on 'values' and support the successful delivery of outcomes; the ability to adapt and lead change; to solve problems at pace; and to overcome the challenges you and your team will undoubtedly experience in delivering whatever you’re trying to build or deliver.
The four values are widely recognised and known in the tech world. They are as follows, with explanations in context for non-tech or software type teams or businesses, they might read this way:
1. Individuals and interactions over processes and tools.
Translation: You hired people because they were smart and good: let them be smart and good. Enable them. Empower them. Trust a little. Let them self-organise and communicate. Lose the micromanagement. Enable your smart, good people that you hired to get on with the job. And then verify that you are executing, together, regularly.
2. Working software over comprehensive documentation
Translation: Execution trumps knowledge. And documentation. No, I’m not saying you don’t need planning and structure and documentation, but when you actually get something done you can then do something called “showing it to a fellow human”. Probably one of those smart people that you hired that I spoke of earlier. Then those people can use it and try it out. They will then say things like ‘hey – great job!’ or ‘wow – that kinda doesn't work!’ Either way you’ll know immediately where things are at, and can quickly pivot to fix or further it. Document if you must.
3. Customer collaboration over contract negotiation
Translation: This means stay in regular, meaningful contact with your customer or end stakeholder. This is important. And simple. Bluntly, give the people you are doing stuff for what they want or need and update them as you're going through, and ensure they know they are getting it, regularly.
4. Responding to change over following a plan
Translation: Sh*t will happen. Things will change. Suck it up and deal with it. You’ll be able to do that because you’re communicating regularly and being flexible.
What next?
Well, values are great and all, but there's also action that you need to take; a way of doing things if you will.
Here's a list of what I believe are the simplest elements of the approach that most teams or people can apply with very little in the way of tools, time and effort:
Make a list of the stuff you need to get done. Prioritise this list.
Write a job or a ticket or a post-it note that describes each element of work needed to complete the items on your list.
Put it on display so everyone – your team, your customer, your CEO or whoever needs to see it, can. Trello, or a wall and post-it’s are both good for this. The tool doesn't matter.
Map the work to be done into short periods of time for completion. You can even call them ‘sprints’ and sound all tech startup’ish if you like. No rules here, but 2 to 4-week sprints seem to work best.
Huddle every day. This is important. A short, sharp 10-minute (max) meeting to check in, discuss progress, problems, issues. Perhaps stand up so you don’t get comfy and start waffling. This only works when people are communicating well and as working as a team.
When you finish a sprint, meet to retrospectively run back over all the stuff you did, openly. Be honest. Learn from it. Apply it the next time.
Rinse and repeat.
You can flavour this any way you want. Make it authentic and make it yours and your teams'.
The final piece to note is possibly one of the most important things to keep in mind: whenever you're building out or finishing something as part of whatever it is you are working on, you'll likely encounter choices around which way you go forward. Always try to choose a path that makes future changes able to happen the easiest.
The best part about this approach to working on stuff with people is that even adding just a bit of this method into your flow is likely to make a positive difference in any team, even if you make a bit of a ham of it.
And remember: if it's seems stupid, and it works, it's not stupid!
See you on the swings : )
D