The agile framework is a structure. To help software development teams write code and deliver features, fast.
And yes, compared to older methodologies, it helps teams get and stay organized to build and deliver great software products.
But because it’s a vast improvement. Are we sticking with it because it is “better than before”, instead of reviewing it like we do when creating software and iterating?
So, if that’s the case.
Have we reached the framework’s limitations? As with code, it is time to develop a new framework.
Because it holds back development teams more than it supports them.
Here’s the issue I have with the Agile framework.
What Is The Agile Framework
I’m not going to do a deep dive into the Agile framework.
If you want to learn more about the framework. There are two good articles here and here.
At its core though. It’s made up of 5 key components.
- Time box iterations: A set period to do the work.
- Backlogs: A way to manage what working is coming up.
- Daily meetings: To update the team and resolve issues.
- Review: Show what we’ve built to the relevant people.
- Retros: Reflect on the work we’ve done and improve.
It all sounds good in theory, doesn’t it?
And as I’ve mentioned, it is better than other frameworks.
But for me, the way it’s now implemented is the biggest issue, more on this in a second.
And even though it’s called “agile”, I find it’s become very stiff in its structure.
It’s Better Than The ‘Waterfall Method’
So, I started University back in 2003. And undertook a BSc in Computing Science with a year in industry.
A lot of the software development modules. That wasn’t based on coding. Were teaching us to put in place the “waterfall method” of software development.
And if you compare the waterfall method against the agile framework. Agile wins every time.
The issue I’ve got is that we aren’t moving forward again.
The waterfall method was a long drawn-out process, it could take months. Even years to get something delivered.
Here’s an example. Where the National Health Service started a software project in 2002. It never got delivered and cost £10 billion of taxpayers’ money. Because they were using the waterfall method to deliver the solution.
This method has distinct stages, completed in order. Starting with specification, then analysis, design, build and delivery. Each stage could take months. That’s why it took so long to get something over the line.
One of the biggest issues was if something went “wrong” in the earlier stages. If it was incorrectly specified, by the customer or the development team. Or there was a misunderstanding in the analysis and design stages. This meant it was a flawed build from the start.
What if the early coding of the system was wrong?
This would introduce flaws into the rest of the solution as well.
Time For A New Paradigm
After the dotcom boom and bust. Even though people still thought the digital age was a fad.
The software development industry started expanding. And seemed to speed up, even to this day.
The waterfall method needed replacing.
As part of my Computing Science degree, I did a 12-month work placement.
Rewinding back to 2005. The academic world was way behind the software development industry. I’d spent 2 years learning about the waterfall method. But when I was going for job interviews for my placement. I was being asked if I knew about rapid development lifecycles. Or extreme programming.
I didn’t, but it got me interested.
I’d never been a fan of the long drawn-out process they were teaching us. 20% of my time was on coding. And the rest of my time, learning all these other steps in the process was boring to me.
So these new ideas. Where you try and get something built as fast as you can and go from there. Well, it made sense and it was exciting.
You were now coding for 80% of the time. Result.
These early frameworks were a precursor to the agile framework.
They were a massive improvement. But was a bit of structure needed? As well as bringing in people in from outside the development team to help with the build.
Yes, but have we gone too far?
My Experience Implementing The Agile Framework
I first started noticing the adoption of the agile framework in 2012/2013.
One of the project managers I worked with. He wanted to run a few new projects we had in the pipeline using the Agile framework.
I’d started heading up a small software team. And had a good relationship with the other departments in the business.
So we put our heads together and decided to give it a try.
I went all in with the Agile framework.
Implementing it “word for word”. Following the guidelines to the letter.
I got a lot of pushback from the business. My boss wasn’t supportive and would criticise it at any opportunity. Which pissed me off.
But he may have had a point.
We were already building software in an agile way to start with. Seeing what we could build and get it out. Forever improving something.
And I was great at chatting with others in the business. To find out what their biggest headache was and they tried to fix it.
Putting a structure around it wasn’t the best thing to do.
At the time it felt like the right thing, a way to improve and to get better.
Which we did to be fair.
What I Dislike About The Agile Framework
So having implemented agile in a team. As well as working in other businesses since 2016 that have bought into the framework.
Here’s what I have found that I don’t like.
That we may have to look at, refine, and improve.
1) It Gives Developers “Autonomy”
WHAT A LOAD OF BOLLOCKS.
This is one of the biggest selling points of Agile. Developers have more “control” and it gives them autonomy. Power in the development process.
I CALL BULLSHIT.
Telling a developer to attend a meeting every day. Making them wait till this meeting to resolve issues. Getting them to review work they’ve done at the end of every sprint. Forcing them to do a demo of what they’ve built. Even if that demo is pointless. And pushing it on them to figure out what’s needed in a “story” because the product owner can’t or hasn’t done it.
How is this autonomy?
This is control if you ask me.
A wolf in sheep’s clothing. “You’ve got control”, when in fact you’re tracked and monitored more than you’ve ever been.
Don’t agree?
What if I say the word “velocity”? I’ll come back to this.
2) Refining, Story Pointing
Another thing I dislike about agile. Is the process of figuring out what work is to be undertaken.
And I’m going to hammer home my point on velocity in a second.
Agile has put a structure around how to write out the goal of a “story”. A piece of work that needs to be completed. The Given, When, Then. I love this structure, check out my post on BDD Testing which uses this structure.
Agile also adds acceptance criteria which is a simple question that has a yes/no answer. And you try and turn all the no’s into a yes.
I’m happy with that.
The issue is, that it’s left to the development team to “refine” it.
But it’s never a refinement. In other words, work out what we need to do. The entire story.
And yes, it’s important to collaborate with the product owner and figure out what to build.
What I find is that a basic description of the story gets documented. That’s it. The team has to then spend hours figuring out what to do. To ask the right questions. To create the structure (Given, When, Then) and acceptance criteria.
The product owner then goes back and forth to get all the information needed.
This should get completed before the team is even aware of it.
It’s more responsibility on the team.
Then you have to calculate how much effort it will take. In the form of a story point
If you ask me, this is a way to track you.
3) Team Velocity
You’re dam skippy thises numbers are a form of tracking.
Velocity is a number, let’s say 42. The people running the software teams use it to see how productive a team is.
You can say that it’s to make the business more predictable. Making it easier to see how long things will take.
And that is true.
But if a team’s velocity drops to say 15. Do you think nothing will happen?
“Oh, it’s the team doing difficult work”.
Nope, management will ask “Why is the team not working as hard. Getting as much done, and doing what we pay them to do”.
Velocity = monitoring.
4) Meetings And Retro’s
I fucking hate meetings.
I’m going to link to the amazing post by Paul Graham called Maker’s Schedule, Manager’s Schedule.
Because agile has been widely adopted. And there are new roles, like product owner, and scrum master. There are lots of non-technical folks involved with running development teams.
And coders are beholden to their schedule.
The product owner can’t make a meeting or do a certain time of day?
Everything gets cancelled and the team. The majority of people have to shift their day or week around to fit one person.
Writing code is deep work. And this work needs focus. Having to stop to attend a meeting, the daily stand-up throws this focus out of the window. Every day.
The Minority Wins Over The Majority
I suggested having it as early as possible in the day to a team once.
Guess what happened?
Either the scrum master or product owner couldn’t do that. So the rest of the team has to fit around one person. Again!
So much for the promise of autonomy.
Retro’s are also pointless.
Reflect on what you’ve done. And come up with ways to improve.
Sounds good.
The issue I have is that a lot of the improvements are out of the control of the team. And when you ask the business for help. To sort the issues identified in the retro. You hear crickets.
As long as they are happy with the velocity number, you’re on your own.
All that happens is you end up with this long list of “points” that need action. That never gets actioned. And the list keeps on growing.
The business will ignore 99% of what’s on that list.
They won’t care.
As long as they are meeting their targets. And can keep piling the work on the software teams.
They will carry on until a team gets crushed.
5) Sprint Demos
These things make my piss boil.
We aren’t at fucking school. Why do I have to “show my work”? It’s not a maths test.
The biggest issue for me is that the “stakeholders” the ones that can benefit the most never turn up to the demo. You end up showing it to all the other development teams. Which grinds the whole department to a standstill.
Madness!
Stakeholders are either too busy or don’t care.
It’s another way to prove that a development team is doing actual work.
I also noticed that a lot of questions get asked. Or feedback about the solution gets given. Sometimes they even say that it’s not what they need.
This makes the team look bad, even though it could be the product owner who isn’t doing their job.
So many times I’ve pushed to record the demo instead. And then send a link for people to watch at their leisure.
It will free up so much time. And is also a way to then create user documentation off the back of the recording. As well as having a way for stakeholders to feedback to the product owner before going to production.
Not making the software team look like morons!
What’s The Alternative
I wish I had the answer.
I’m hoping to shed some light on the current framework with this article. To start the discussion of improving it.
As I said earlier in the article.
Because it’s far better than before. Both for software teams and the businesses they work for.
The improvement process seems to have stopped.
It’s Time To “Shape Up”
One company has taken matters into their own hands.
Basecamp, the project management software has taken a different approach.
They seem to have taken the best parts of agile. And tweaked them to help them deliver software and new features even faster.
There’s a great article about how a team implemented the shape-up process with great success.
Conclusion: Is The Agile Framework To “Stiff”
The agile framework is light years ahead of older methodologies. Like the waterfall method.
But like a weight lifter who is now in his 40’s (like me). Is it “ageing” and becoming “stiff”?
The framework promotes itself as being flexible to help deliver software solutions. As well as putting control in the hands of the development team.
But those as now fake promises.
Has it become a victim of its success?
That now all the meetings and non-technical folk that work inside Agile. Have put too much “stiffness” in the system.
And that businesses, use things like story pointing and velocity to track developers’ output. Not as a way to support the team when needed.
As with all frameworks. Like the coding ones we all use.
Is it time to review the Agile framework?
And improve what we’ve got to make it even better.
Or is now the time to come up with a new framework altogether?
