So, Agile. It seems like a bit of a buzz word, and my favourite experience of someone completely missing the concept of Agile was someone I interviewed, I won’t name them, but our conversation went something like this;
“Do you have any experience working in Agile?”
“Is there any other way to work?”
Okay, this sounds promising! The blank expression on this candidate’s face when I mentioned things like Scrum, Velocity, and Retrospective showed me that the misconception here was that “Agile” simply meant “working to changing specifications”.
Now, moving into Agile can be a scary and daunting task, and the Agile manifesto is a bit obscure, as are the principles of Agile. So the aim of this article is to give some tiny snippets as to how you can make start to (and you may already be!) adhere to this manifesto and these principles.
My plan, for this article, is to demonstrate the manifesto, and how that should worm its way into your every day working!
Value individuals and interactions over processes and tools
Let’s just let that sink in for a minute. Anybody who has worked with me, especially those who have worked with me at Speed, will agree that I love a flow chart, I love things working like a machine; so this one took a little while to sit properly with me.
The more I think about that “value individuals” the happier it makes me. What this means, is we need to collaborate, understand the skills everyone brings to the table.
This one is arguably the easiest one to achieve, but when you’re mulling over specifications and features, get everybody involved. Start to snowball, get creative. Sit everybody around a table with a whiteboard or some post it notes (Jay Heal loves a good post-it session! Or a workshop as they are more accurately described)
People involved in brand will have different thoughts to offer from those thinking of the product from a marketing perspective, which will be different from the UX gurus, and the frontend ninjas, and the data scientists, and the software engineers.
Magic happens when these people are collaborating, and are each individually valued.
Value working software over comprehensive documentation
Again, this was a culture shock to me. I like my software specifications to be really, really comprehensive. However, drawing up these documents take time, and from a technical delivery standpoint there’s very little value, actually, it’s more valuable from a commercial standpoint.
So, what’s the alternative? User story planning. Rather than drawing up a million specification points, let’s plan the user’s story, and build that.
This pulls really nicely into Test Driven Development, and into YAGNI (You Aren’t Gonna Need It), because you develop and delivery what’s needed.
It is better to deliver small pieces of working software, frequently, than spend months hashing out the too-fine details of a contract and specification.
From a commercial standpoint this sounds counter-productive, but hear me out; if you keep delivering working software, you are going to avoid cash-flow problems where you’re waiting to get the project signed off, and consequently paid for. Additionally, you’re going to continue to gain the confidence of your client, so they’re going to be far, far more inclined to continue to invest into a working relationship, than a black hole of “you’ll get to see it one day” development team.
Practically then, what do we do? Go through the wireframes and the high level conceptual specification, enough to know what you need to develop. Then start coding, as soon as you have enough to work on, start coding something, and make sure you show the client. Prototypes are acceptable, but have something to show and deliver. Don’t wait for an unveil moment, make the client part of your development process.
Side note; you’re also likely to avoid costly test cycles and amendment rounds at the end of a project by working like this.
Value customer collaboration over contract negotiation
This leads on really nicely from the last point. Collaborate with your customer. They know their business, as well as your team know the technology.
Rather than having “no” conversations, have collaborative conversations. Using velocity and backlogs and the point system, once the client has bought into the concept themselves (which you might have to do), they can make decisions about how to spend the resources they’re paying for.
Let the sky be blue, lets the creativity flow.
Practically, liaise with your clients almost constantly. Depending on your environment you probably can’t have them in your scrum every morning, but you can certainly keep them involved. Collaborate with your clients, don’t just negotiate terms.
Value responding to change over following a plan
This is the key thing with Agile, that makes it considerably different from other project management methodologies, like Waterfall.
This is where your sprints, and an accurate velocity, come into their own. If everything is planned and scoped (with points) in your backlog, and you know the velocity of your team, changing direction on a penny shouldn’t be a problem.
Adjust your sprint, and continue collaborating. I’ve been on projects where the entire success of the project has been based on my team’s ability to change direction in an instant, to match a new opportunity, respond to a threat, or based on a new strength or weakness identified.
This is about letting the deliverable lead the project, not the commercials. By working against sprints, you can change direction without necessarily worrying about commercials in the first instance.
Further Reading
Agile Manifesto courtesy of AgileManifesto
Agile Principles courtesy of The Agile Alliance
Featured image credit: Agile Alliance (it is their logo)