Agile in 6 Minutes
We dig into the misconceptions on what Agile actually is and its relationships to Scrum, Kanban, etc.
Today, we will be talking about Agile project management what exactly is it and some huge misconceptions about Agile and its relationship to things like Scrum or Kanban.
If you’re new to the channel, then on here, we talk about website projects and development, including no-code tools like Webflow and Pinegrow
so if you’re building websites, whether you’re an agency owner or freelancer, let’s start by talking about what Agile is.
Remember to like and subscribe.
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.
Even though this is the case I still find many misinterpretations as to what Agile exactly is so we’re going to go through it in detail. But It’s essentially a way of building things in small increments in order to test and feedback those learnings 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 principles into your startup.
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 we call Agile.
“Mindset” here is key. It doesn’t dictate any practices, events or tools or anything. It’s just a mindset.
It’s up to you how you interpret them
but we’ll get into frameworks that sort of do that for you.
The agile mindset is described in something called the agile manifesto, link below.
And In true agile spirit, the manifesto tries to be as simplistic or ‘lean’ as possible.
Firstly, I can’t imagine a more white male, cult-like aesthetic to this website and the principles but regardless, I do think there’s validity to what they are saying.
I think It’s important here to note that the Agile manifesto focuses mostly on the client/vendor or business/team relationship over, say a product/end-user.
However, that’s not to say we can’t leverage these ideas when thinking about the end customers.
The manifesto itself includes only 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
Let’s break this down into plain English
Individuals and interactions over processes and tools.
Previously we would blindly rely on processes like Prince2 or other project management methodologies to dictate how a project is run.
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 the process or what tools they should use
Working software over comprehensive documentation.
Traditionally, software was built by first writing lots of documentation and specifications upfront before writing a line of code.
This could take months
Working software is a far more important and efficient way to build things as we can learn and be flexible in how we 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
This is basically saying build now, talk later.
Customer collaboration over contract negotiation.
As a reminder, the ‘customer’ in this statement is actually the client and,not the end-user.
This value stems from the fact acceptance criteria were agreed on upfront in something like a statement of work which ultimately led to disappointment when projects would inevitably fail on those promises.
By collaborating with the client along the way you can negotiate and stay flexible on what features are best for the project at a given time and stay in line with the business strategy.
And finally, Responding to change over following a plan.
So not only are we getting working software out there early and listening to end-user feedback, we are actually responding to that feedback.
Subsequently, we’re responding to internal changes in the project, team and business requirements.
Similarly, we are also responding to external 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.
I hope that was helpful kind of going over the four values as I think there can be some confusion into what they actually mean.
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.
So given the agile manifesto, where does that leave us?
Well, as I said it’s pretty vague so some groups of people decided to develop methodologies or frameworks which translate this mindset and ideas into some practices which help put a bit more structure to the Agile way of working.
This is where you hear things like Scrum, Kanban, Extreme Programming and a few others.
The most popular is probably Scrum which you might have heard of but they all tend to be pretty lightweight except scaled agile which personally I just think is a money-making scheme to appeal to large enterprises.
We won’t go through them all but they all involve things like daily standups, stakeholder presentations, Sprints and so forth.
My advice would be at this point is to quickly gloss over some of the different frameworks.
Maybe start with Scrum or Kanban and start to apply them in your next project.
Please let me know in the comments if you want me to cover some of the major differences between the different agile frameworks.
I want to make a video on how this practically all fits into the sale of a project but I thought, start with the basics and build from there.
I’d love to know your thoughts on this.
Has this cleared anything up for you? Are you running some sort of agile framework currently and if so, which one?
Let me know down in the comments
If you’re interested in learning more about Agile, or some of the words I said in this episode sound like gobbledygook, then do check out my free book. Agile Lingo.
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
Lingo: Agile. It’s free and, as a downloader, it gives you access to a private channel in the full stack agency Discord community.
I’ll leave a link to everything in the description below
Thanks for tuning in and I’ll look forward to seeing you in the next one