Agile, simply means able to move quickly and easily, that’s it! The term agile though, has been used in all sorts of ways over the years, whether that’s to describe a process at a company, or used as a stick by clients to beat their suppliers with when they want to change their minds over and over again “I thought you said this was an Agile project!”
To understand how we got to where we’re today and how the term Agile is now everywhere, you have to first go back to how we used to work in the 1900s on the assembly line. Management has evolved over the last century but it started with simple repetitive tasks.
1.0 Management (Assembly Line)
Management in the 1900s was the assembly line, management separated all decision making from the workers. One set of thinkers, another set of doers. This approach was heavily influenced by Frederick Taylor.
2.0 1950s Management TPS/Lean)
In the 1950s, simple repetitive work become more complex and workers were getting bored with 1.0. 2.0 empowered workers to stop the production line to fix issues, reduce waste and fix issues. This approach was influenced by Taiichi Ohno and W. Edwards Deming
3.0 1990s Management Agile
Technology and software is becoming prevalent and more complex. Waterfall is starting to fail because of its inability to predict in advance what's needed. Scrum was introduced to allow for short iterations and fast feedback and the Agile Manifesto was created
Agile is not a process it's a mindset or a set of values
So you’ve seen how the term Agile came to prominence, mainly down to needing to adapt and improve how we work in an ever complex world.
For now though, the best way to start when describing Agile in a business sense, is it’s really just a set of values or just a mind set, that then trigger a number of behaviours that show agility.
That could be showing transparency as the more everyone knows, the more you can improve, adapt, change direction if something isn’t working etc..
Project types, simple through to chaos
Still to this day, we assume we’ll know exactly what will happen in a project months ahead of the start date. In reality, it’s impossible to predict, so knowing where your project type sits, will help you take the right delivery approach.
The below examples of where different project types sit, is a really useful took to work this out.
You simply need to ask questions like, do we know exactly what we’re building, and do we know exactly how we’ll build it? Pretty sure the majority of you will reply with no to both of those.
If so, you’re in perfect spot to deliver your project in an Agile manner.
SIMPLE: This is where manufacturing sits, you build the same thing over and over again. Very little uncertainty, we agree what has to be built and how we’ll build it.
COMPLICATED: We know what to build, or how to build it but not both. This increases uncertainty. Building a large bridge is a good example.
COMPLEX: Typical product development sweet spot (Agile), the customer has a rough idea of what they want, but they’re not sure, so things change frequently. We can’t remove all uncertainly, so we manage it with fast feedback. This is when agility becomes an advantage
CHAOS: No clue what we’re building or how we’re going to do it. Don’t go here!
The Waterfall approach: The classic project delivery method
So by using the tool above, or just using our common sense we know where our project sits, but we still deliver projects in a way that we know is going fail.
We’re understanding pressure to define everything up front and commit to a date we’ll deliver it. No matter how many times to approach fails, it’s still repeated over and over again.
The most common methodology is called Waterfall and it’s been around far longer than I’ve been delivery projects (many of those using this methodology and the scars to prove it!)
What is it?
You complete one phase before moving onto the next phase
You rarely aim to revisit a phase once it’s completed. So you better get it right the first time!
But!
You don’t realise any value until the end of the project. You leave testing until the end. You don’t seek approval until late in the day. By the time you finish, your users might not want it or have move onto something else!
So even though we know this approach to projects rarely works, why do we keep using it?
Fear and trust. Fear of the unknown, I have to know what I’m going to get now, as there is too much at stake not to know.
If we get everyone to commit to everything now, we can all relax and plough on ahead. Relax everyone, the 150 line project plans says we got this! Then trust.
In the digital industry you’re continually working with new people, teams, agencies and brands but quite often the trust isn’t there.
This is understandable we’re talking about peoples livelihoods here, so we need commitment you’ll deliver X, otherwise I can’t get Y.
So what happens with lack of trust, we write down exactly what what we’ll build, how long it will take and how much it will cost and put it in a contract. Phew, I’ll get my Y now as it’s in a contract.
One thing I haven’t mentioned yet with all this fear and trust issues floating around is the user or the customer in a Waterfall approach. As a customer I’m not even on the 150 line project plan as I’m beyond that.
By the time I can get this product, it will either be to late as I’ve got it somewhere else, what you created isn’t actually what I wanted in the first place, or unsurprisingly the end date that was given in the first place has been missed and the product still isn’t ready!
So what do you think about Waterfall? I know I paint a pretty bleak picture, there are some projects out there that sit in the simple space and can work in this way.
Although this post sounds like I’m here to bash Waterfall, it’s actually to explain how important it is to find the right methodology for your project, recognise this before we begin will save you so much time, pain and money further down the line.
And just as importantly, create the best possible product, service or whatever it is you’re creating.
The cheetah or bull, which one are you?
Another way to think about how Agile your current company or your projects are, is to think about how easy it is to change direction.
You might be part of a project that is moving fast, lost of people working on it, new features all the time being build and you’re progressing quickly towards a deliverable or a hard deadline that you’ve agreed upfront.
Much like a bull facing a matador, the bull can move really fast, it knows what it wants to achieve (get the Matador!) but once it’s running in that straight line towards its target, it continuously misses, as although it’s fast, it doesn’t have the agility to pivot direction and achieve its goal.
Sound familiar? Many projects are excellent in creating the team, defining the deliverables and setting an end date, as that’s the easy bit.
What happens when the market needs change, or your customers now want something else, there is no stopping that bull/project as the contract and deadlines are set.
This is the traditional Waterfall methodology, and ultimately when you need to adjust, you can’t and miss the target.
Now, what if we put a cheetah in that arena with the Matador?
The Matador wouldn’t last one minute as the cheetah has incredible agility and can move fast.
This is what being Agile really is. Taking the project example, when market needs changes, or your customers now want something else, an Agile project can pivot and focus on the highest value item at that point.
You can still move fast, but moving fast isn’t always the best approach, so the cheetah or an Agile project can do both.
You don’t know in business precisely what is going to happen or is needed in the future, there is too much volatility, uncertainty, complexity and ambiguity. In this world, if you can respond fast that gives you a competitive advantage.
How many times have you worked on a project and you know exactly what a customer will want, and exactly what you’ll create?
What Agile isn't
To help explain what Agile is, it’s great to have some examples of what Agile isn’t. A phrase I’ve heard over and over again is we’re doing Agile.
You can’t do Agile, you can only be Agile. You can do Agile frameworks, like Scrum or Kanban, but you don’t do Agile. Agile is an adjective, so you can’t do agility.
You can’t do Agile, you can only be Agile
Agile is NOT an excuse to stop producing documentation. It’s about producing documents that are really needed and have value
Agile is NOT about blindly following a set of “best” practices, it’s about adapting and improving everything you do
Agile is not a methodology or a process
Agile means agility, it’s not Scrum or stand ups it’s means ability to move with quick easy grace, to be nimble and adaptable
Agile is NOT an opportunity to eliminate planning. You actually typically plan more regularly
Agile doesn’t mean you are constantly changing everything or you can constantly change everything
The fundamentals of Agile: Agile Values
While there is value in items on the right, we value the items on the left more
Individuals and interactions OVER Processes and tools;
What this DOESN’T mean: Processes and tools are irrelevant. Processes are what enable teams to learn and improve over time.
It’s about using processes and tools that support the team and goals for the project
Working software OVER Comprehensive documentation
What this DOESN’T mean: Documentation is not needed. You produce the documents that are needed by the team and the product, but it doesn’t reduce the interactions between the team members.
Working software has greater value, as a user can test software or whatever product or service you’re producing, they can’t test a document.
Customer collaboration OVER Contract negotiation
What this DOESN’T mean: Contracts aren’t important. They are. But they can be broad enough to recognise that the exact deliverables aren’t specified in advance (because they aren’t fully known when the work starts).
And if both sides are truly collaborating and reasonable, then both should be satisfied in the end.
Responding to change OVER Following a plan
What this DOESN’T mean: Planning isn’t needed. Plans are important, but they usually shouldn't be written in stone and you must assume they will change. Plans need to adjust to allow for the highest priority actions to be worked on, so you can create value.
The Fundamentals of Agile: The Agile Manifesto
When the Agile values were created back in 2001, 12 principles were also created. Although the principles were created with software development in mind, they can be adapted or used for any type of product or service.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity--the art of maximising the amount of work not done--is essential.
- The best architectures, requirements, and designs emerge from self-organiSing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Popular Agile Frameworks
