This is a quick question to answer… ’no’ it doesn’t. In our opinion, Agile is often not great for web development projects, but why..?
First of all, what ’agile’ is is open to interpretation; so instead of talking about the dictionary definition, as per the Agile Manifesto, let’s discuss how it really pans out, based upon our experience, of working in dozens of web development teams at digital agenices, UK government departments, and large private businesses.
Planning:
- Split work in chunks and split chunks of work in to ’sprints’
- Decide how long each ’sprint’ is: e.g. 1, 2, 3 or 4 weeks long
- Decide with the team how long each task should take e.g. assign story points to a task
- Deliver a completed piece of work at the end of each ’sprint’
Story points and/or assigning timings to tasks
When you look at a project you have to estimate how long each task will take. We have covered this when we talked about how to estimate a web development project, and we have a definite system which we link back to time.
Story points are supposed to be arbitrary so you may have points like 1, 2, 4, and 8 or you may have code words like small, medium, large. If a task is larger than large or bigger than 8 then it should be broken down. So far so good.
The trouble is when:
Story points are always linked back to time. See those numbers 1, 2, 4, and 8. They suspiciously look like a breakdown of an 8-hour work day. So a developer is basically being asked to say a task is 1, 2, 4 or 8 hours and a project manager has a set number of days to complete in the sprint so you can see how pressure to complete a '2' task in 2 hours becomes very real very quickly.
'Small', 'Medium' and 'Large' also need to be linked to time otherwise how can anyone plan anything? If you go to the client or your boss and say this task is 'Large' they will want to know what that means in time.
By abstracting time to 'story points' we’ve potentially added hours to each project as developers argue about them. If you work on projects with freelancers, whereby a new developer needs to be introduced to the team then you can have this argument a lot.
Sidenote: Some consultants/agencies charge, not per hour, but on what value the client will get from their work. Which mitigates a lot of these issues but if you have staff who are paid hourly, daily, or monthly you will always be in need of knowing the real time a task takes.
Timings in reality
Tasks start to look very different as soon as they become real and stop being theoretical discussions in planning meetings. You discover they are easier or harder they you estimated; rarely are they exactly as you expected and planned for.
An example
Task A is estimated to be 10 days i.e. the full sprint for one developer. But 3 days into Task A we realise that Task A will take a minimum of 20 days. So what do we do? Try to reduce the scope? Extend the sprint? Add more people?
Often the budget is fixed so the only option agencies have is to cram all the work in and burn out their developers.
Which leads us to…
Worker stress
By blocking work out into 1, 2 or 3 week blocks you get a strange phenomenon. You get developers who are happy and relaxed at the start of the 1/2/3 week sprint and very very unhappy and stressed at the end of that sprint as they fight to finish the work for an arbitrary deadline.
The reasons agencies and clients like this approach, (and I have no idea why private companies/public organisations like it) is because the agency can invoice at the end of the sprint and the client can see tangible proof that the project is going to according to schedule.
Constant ongoing reviewing:
You meet each morning to discuss what you did yesterday, what you will do today and what if anything is stopping you (e.g. a 'blocker').
This meeting is called a ’stand-up’ because you’re supposed to be physically stood up which, in theory, helps avoid the meeting becoming too long.
A good quick daily meeting can be a great tool. Finding out what each team member is doing can really improve communication.
The trouble is when:
- the team gets too big and the quick meeting takes 30 minutes or more
- people come into work and don’t do any work for the first hour because the stand-up is at 10:30am and there’s ’no point getting into a feature only to stop for a meeting’
- everyone is forced to physically stand up, 'because it’s quicker' but then people are stood uncomfortably for 20 minutes
- people feel the need to detail everything they did yesterday. We’ve seen people bring lists to stand-up and read them out.
- people feel like they are being publicly judged for their output in front of their peers
- people can be on multiple teams and may have 2+ stand-ups per morning
- often, it’s only the developers who have to state what they’ve done; the Project Managers/Owners often don’t state their activities, which feels is a bit unfair.
Reviewing at the end:
In an agile project you often hold a ’retrospective’ whereby the team gets together at the end of each ’sprint’ and discusses what went well, badly, and what could be improved, writing these as notes on a post-it.
Half of these very long meetings or ’retros’ consist of people not knowing the difference between the 3 categories, and debating them. A lot of the time, people are unsure what to write on their post-it note and in my experience, no matter how long the meeting is, you never finish everyone’s post-its. There’s always one character who writes dozens of post-its and many people who write very few or none.
The solution
We don’t really have one. We’re just not fans of super rigid deadlines and forced meetings. We’re not anti-deadlines, and we’re not anti-meetings. They all have their place, but we want to always ensure they are relevant and have an impact.
We like to take each project at a time and see what is best for it based on the type of work, the real deadline, and the budget.
Deliverables at key dates are super important, but so to is communicating to clients that these dates may need revising. Communication and honesty, as always, is key.