Today, we will be talking about Agile project management, what it is, and why you should be running some sort of agile process in your web design and development projects whether you’re an agency or in a team.

What is Agile?

If you haven’t heard about Agile, it’s the way software and website projects have been built for many years now and it actually stemmed from Toyota back in 1945. It’s essentially a way of building things in small increments in order to test and feedback those learnings back into the production cycle. They call this Lean manufacturing.

You might have heard the term lean in many different contexts such as the ‘Lean Startup’, by Eric Reis which talks about applying these ideas and principles into your startup by eliminating waste and improving efficiency.

On the contrary, another way to build things is Waterfall and that essentially dictates that one phase of a project, say development cannot start until the design is complete. And this makes sense right? Why build something if you don’t know the design first? Well, we’ll get into that but there’s a time and a place for both ways of working. Waterfall makes sense on a factory line where there is a fixed set of assets (or scope) and a defined, unchanging cost (fixed cost).

The Agile Manifesto

So let’s talk more about what Agile actually is. As I say, it was inspired by lean manufacturing from Toyota and developed into a mindset or framework we call Agile. In true agile spirit, the Agile manifesto tries to be as simplistic or ‘lean’ as possible. Check out agilemanifesto.org. Firstly, I can’t imagine a more white male, cult-like aesthetic to this website and these principles but regardless, I do think there’s validity to what they are saying.

It’s important to note here that the Agile manifesto focuses mostly on the client/vendor or business/team relationship over the product/end-user. However, that’s not to say we can’t leverage these ideas when thinking about the end customer.

The manifesto itself includes 4 values;

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Breaking this down,

Individuals and interactions over processes and tools. What this means is that previously we would blindly rely on processes like Prince2 and other project management methodologies to dictate and direct the project. What this value says here is that we should be sensitive to the way a specific team works and how they interact with each other and use that as a basis for what tools they should use. Because every team is different, right?

Working software over comprehensive documentation. Once again, traditionally, software was built by writing lots of documentation and specifications upfront which could take months before even writing a line of code. We’ll come to learn later that what’s most important is getting stuff built. Working software is a far more important and efficient way to build things. You can make so many assumptions on what clients and end-users want and why that when you finally launch, it’s completely wrong. Just build now, talk later.

Customer collaboration over contract negotiation. The ‘customer’ in this statement is actually the client in a client/vendor scenario, not the end-user of the website or product. This value stems from the fact the acceptance criteria was agreed on upfront and ultimately led to disappointment when projects would inevitably fail on their promises. By collaborating with the client you can negotiate and agree on what’s best for the project at a given time directed by business strategy.

And finally, Responding to change over following a plan. So not only are we getting software out there early and listening to end-user feedback, we are actually responding to that feedback and subsequently responding to internal changes in the project, team and business requirements. Similarly, we are responding to environmental or socio-economic factors that mean that our product could no longer be relevant. I think Covid taught us a lot about this in that we can’t just blindly follow a plan. We need to be flexible enough to change in uncertainty.

The Agile manifesto website also talks about 12 principles. In some cases, this does seem to be the voice of a developer who doesn’t like to be told what to do but nonetheless, they are worth breezing over as they do get into some tangible specifics which the manifesto doesn’t make particularly clear.

The Agile Frameworks

So given the Agile Manifesto, where does that leave us? Well, it’s pretty vague so some groups of people decided to develop methodologies or frameworks which translate this into some practices to help put a bit more structure to the Agile way of working.

The most popular is probably Scrum which you might have heard of but there’s also Kanban, Extreme Programming, Scaled Agile (or SAFe), Crystal, Lean Software Development amongst others.

We won’t go through them all but they often involve things like daily standups, stakeholder presentations, Sprints and so forth but I think it’s important to get into why you would use Agile because like I said before, there is a time and a place.

Should You Use Agile?

Personally, I don’t think Agile works for every project, or at least it should but depending on where you are in the ‘food chain’ you might not have control running a truly Agile project but I will be getting into how I think there’s a lot we can learn from an Agile mindset.

If you do have complete control over the strategy and execution of a piece of software, say a startup or a strategic consultancy like Jupiter and the Giraffe, you’re in a position to implement a strategic pathway and project management lifecycle that lends itself to the business strategy of the organisation you are building for. If this is the case then the second question I’d ask is “do we know what we are building and how”. If the answer to this is foggy then you’re in a position to run an agile project as one of the core principles of Agile is releasing early, listening to feedback and making changes based on the findings. So putting in place a way to develop core, valuable (another key term) pieces of software and a solid test and feedback pipeline is a great way to do that.

One thing to note at this point is that this doesn’t negate strong strategic requirements gathering. In fact, it’s a prerequisite that we have this in order to run a successful Agile project. It’s just how we use this knowledge and respond to change as we come into it that makes the project agile.

If it’s a pretty straightforward project or you’re quite low down in the food chain with little to no impact, then maybe an agile project is overkill. Although, I think Kanban is a methodology that is worth considering as it’s all about just getting stuff done with little to no direction or ceremonies in place.

What Can We Learn From Agile?

With that being said, I think there’s a lot we can take from Agile and lean manufacturing in the early stages of a project. Particularly if budgets are constrained but oftentimes a client will have a huge set of requirements and wishes they want to be implemented into their website. Thinking about things in an agile way, I often find that I’m talking clients off a bridge when it comes to their ambitions. Because all the wants and needs are based on assumptions most of the time, I try and get them to think more short term by identifying not only the most valuable pieces of functionality but also the functionality that going to get them earning money from their endeavour. An MVP or Minimum Viable Product, if you will. This in turn is a great way to keep initial costs down while being open to changing requirements and what I feel is a win-win for everyone. Internally, I think we as agency owners can think about the tools and processes we use to facilitate better communication and easier monitoring of status with something like daily standups or a Kanban board.

Finally, I think it’s important to talk with you about the realistic expectations of an Agile project along with some final thoughts. The entirety of true Agile projects is expensive! But then the problems they are aiming to solve if done correctly should equal a huge return on investment because you’re building websites and software people actually want to use. With smaller budgets, fixed scope and timeframe, it’s often preferable to implement in a Waterfall way so that there can be a bit of governance in the execution.

Running Agile projects equates to shorter timeframes before delivering something of value and this, in turn, is an opportunity to start to learn from the project which is why we always use Hotjar to monitor the activity on a website and report on our findings on a near-monthly basis. Especially in the first 3 months or so. This video is not sponsored by Hotjar but we do genuinely use it on most of our projects so I will leave an affiliate link in the description below so that if you do choose to sign-up I will earn a little commission from that. It’s free to sign up and it’s very easy to implement, particularly if you have Google Tag Manager installed already.

Interested in Learning More?

If you’re interested in learning more about Agile, or some of the words I say in this sounded like gobbledygook, then check out my free book. As part of the Lingo series, we dig into the A-Z of Agile terms and I explain them in a simple to understand way along with my thoughts based on my real-life experience running Agile projects in something I call “Sam’s take”. It’s free and as a purchaser, it gives you access to the support Discord community. If you’re interested in joining the free groups then feel free to join and ask questions and help others.

Download my Book for Free: https://thefullstackagency-xyz.preview-domain.com/books/lingo-agile