It's one of these terms that seems to be used either as something specific, or by others as just a an adjective.
When "agile" first came on the scene, I think there must have been a tighter line to its principles, but decades later, who the hell knows?
I'd like to open the floor for input. ❤️
Agile has become a marketing term for companies. Seemingly every developer job ad mentions how the company is "agile", then you start there and realise they have no idea what they are doing and it's really just some mutated form of waterfall. For every person trying to keep the ship steered straight, there is an overzealous boss or manager who thinks they can turn the process on and off whenever they want.
Even many of the companies that are doing Scrum/Kanban/X flavour are not doing them properly. Some companies pick and choose parts from Agile methodologies and make up the rest. The result is some form of broken faux-agile that ends up not boosting workflow or productivity whatsoever.
And then you have the companies that implement these kinds of methodologies purely to micromanage their employees. Agile started out as something created by developers for developers, then the consultants and management got involved, and saw it as a framework for micromanaging their employees. Scrum is a great example of this, the concept of a daily standup meeting, (every day you're asked to say what you worked on yesterday, what are you working on today).
If anyone doubts it's not about micromanagement, look no further than the concept of burndown graphs and all of the other charts which visually plot the performance of teams and individual team members. People in management ranks absolutely loves graphs and other meaningless metrics which mean nothing in the land of software. The only thing that should matter to developers is shipping, that's it.
The whole idea of sprints fails to take into account developers taking days off because they are sick, mental health days, etc. They assume that you have X amount of hours in a two or three week sprint period, but we all know that is not the case. What about emergencies that require deviating from the sprint to fix? If you're using Scrum, deviating or changing the sprint once it begins is technically not allowed.
To me, the worse parts of Agile can all be traced back to Scrum. Daily standups, planning poker, sprint retrospectives. It assumes you have stable priorities, introduces multiple concepts such as boards, burndowns and backlogs, disallows changing mid-sprint. If Scrum were easy, there wouldn't be Agile coaches or entire companies dedicated to helping other companies implement it. To do proper Scrum/Agile, it's become this big song and dance.
Agile has lost its meaning and increasingly, it has become irrelevant (especially during the current pandemic).
You're right, many things which were intended to improve process were taken over by managers and used against developers:
Yeah, Agile lost something when Processes and Tools actually took over. That and the fact a lot of companies absolutely cannot give up control and realize that you cannot be agile with one program manager on top of everybody (it was precisely the main point of it!).
Agility require trust and not so many are ready for it…
Agile requires organizational change, that's the main issue. Business needs to be much more integrated with the software development process. That's why you have the notion of Product owners, but if they're still too far removed from day to day business you'll never get trust between the two.
I think that's where a lot of companies struggle
"Agile started out as a methodology"
Please, wording matters, read the definition of methodology, of method, of framework, and let's avoid confusion.
@arnaud Semantics. There is no confusion here. My comment is pretty clear in the message that Agile and its numerous flavours like Scrum, etc have become bastardised and broken over the years. What started out as a way to help streamline how work flows from conception to realisation has become a way for managers and executives to manage the performance and expectations of their employees on a molecular level. Agile doesn't exist anymore.
agile was never intended to be a strict process to follow, the manifest clearly states this. What we have now is exactly what Agile is not. A strict process, where consultants come in trained in this process and selling the process as "Agile coaches".
The bastardization comes from the fact that people have made this process rigid again just like waterfall, instead it should adapt to each individual company and its processes. You take what works, you leave out what doesn't. That is what the Agile manifesto was aimed to achieve.
It was never just meant for developers, what would be the point of that when you have to collaborate with stakeholders and to ensure you actually build what a business can use. It should narrow the gap between developers and business, that is the point.
Here's the essence:
big-design and waterfall are natural approaches to projects. It makes sense because it reflects how physical things are traditionally made. Most things that are "made" are done to spec and then finished.
The issue is that there is so much time between the very beginning to where anything of value (typically the whole project) is delivered. By that time, it's too late or costly to take in any feedback or adjustments, and so what you end up with is something that was incredibly expensive, missed the mark, and completely failed. The problem is the feedback comes in a day late and a dollar short.
I liken this to big blockbuster movie flops. Think "Justice League (2017)".
As an alternative, agile development emphasizes delivering in iterations, using those iterations to feedback into the development to guide the project toward the right goal. That's basically it in essence.
"Some is better than none. Perfect is the enemy of good."
Everything else is just cruft from people trying to shoehorn methodologies and processes.
To follow the analogy, it's like just writing the script and getting feedback on that. Then filming a pilot for a show. Then getting feedback on that. Then releasing a Season One. Feedback and iterate.
You keep test quality up so you can keep in iterating with the knowledge you're not breaking existing functionality.
Waterfall as described in the original paper was always meant as an iterative means of developing software. Sadly, that iterative part was overlooked. You can read the original paper and you'll see it's clearly stated there.
At any event, the current business of Scrum isn't much different with the exception they've added short iterations instead of large up front design. Everything else is as rigid as it comes.
I joined a team that was trained by Thought-works (beginners of agile) when I started my career. Agile was awesome but it had one weak point, "the teams can modify it according to their convenience". I think that's where everything broke.
Management team started to drop all the needed part of methodology and agile started getting narrowed down. Today it stands to say, "deliver whatever is needed immediately".
There are reasons to this. In early days when waterfall model was followed, there was 6 months as design phase which people didn't utilise effectively to think and to figure out deeper aspects of the product. Mostly it was time gone in vain.
Agile had the kick of giving immediate product. But nowadays people are giving prototype in the name of product. It's not actually agile.
Agile had a standup meeting to last within ten minutes. No one asks any questions unlike nowadays it goes on for hours.
TDD test driven development, we were given enough time to write test cases first and then the code. Nowadays for faster delivery it's very hard to follow TDD. I remember we wrote 200 lines of test code for 100 lines of code.
Pair programming, it's forgotten a way long back because it consumes two developer time. It is a very strategic process to build a stable product. Because while one codes, the other watches to identify missed scenarios, edge cases, better patterns and more. Juniors can be easily trained to high level of code quality in a span of 6 months when they are paired.
Continuous integration was a must.
It was 2 months cycle as I remember. 1st week, everyone sat together to estimate and assign the task. That 2 months was considered quick delivery. Nowadays it's reduced to 2 weeks!
Agile actually creates a very stable product if followed properly. Gone are the days 😐
"Agile had a standup meeting to last within ten minutes."
Please, wording matters. There is no standup in the agile manifesto. You write agile and you mean Scrum. And Scrum, is a framework, not a method, even less a methodology.
It was back in 2008 when we hadn't heard of the word scrum but yet we had standup meetings on a daily basis
I think you're mistaken if there's a one size fits all solution, this all depends on the company and their release cycle needs. Your 2 months may have been great, but for others it would be an eternity.
Agile is meant to be flexible and a take what you need approach, however it really helps if you have people that know what that means and how to implement it
That's right. When we wait for the order in a restaurant, it looks like we have been waiting forever with the hungry stomach.
But for the chef and team, it takes breathless moments to deliver as fast as possible. Even after that they may read in a review that orders are delayed.
A (management) excuse for always shifting priorities and requirements.
While not pushin timelines out..
And adding new stuff mid sprint ;>
Well, priorities and requirements are always changing. Agile just an attempt to cope with this fact.
To be honest last time Agile really mattered to me was when I was completing my degree and writing a theory about agile in one of my theory papers.
After that, while working as a developer, I have never ever implemented agile or used it in any of my delivered projects.
check out Kanban, you're going to love it.
Eric Brechner from Microsoft does an excellent presentation on why this works so well
youtube.com/watch?v=CKWvmiY7f_g
Thanks for sharing the video..
Will surely have a look at it
It‘s all of what‘s been written in the comments.
At its best, it’s about a team of business people and developers collaborating every day, to build and deliver software frequently that people truly love. It’s the most effective way to build software known so far.
At its worst, it’s about keeping the way that companies have been run for years or even decades, but with new roles assigned to people that they know nothing about. It’s about pushing more work on people to complete in shorter time, and frequently changing requirements without clear product vision.
1) waterfall or fragile or similar
2) chaos mode
3) a particular framework where everyone is practising exactly the same way (mostly agile frameworks for corporate use)
4) we stick to Kanban or scrum by the book
5) we use a set of methodologies and principles that allow us to deal with a lot of unexpected shit, build iteratively, learn from mistakes, ship often with predictability, without much red tape, automate a lot, inspect and adapt and our management is part of this culture.
6) we are on our way to reach one of the above 5
I think it worth to distinguish the concept of iterative development (basic idea behind all agile methods), agile methods (sets of rules and practices which can be used to do iterative development) and particular implementations of these methods. Idea is fine (after all requirements are still changing just like almost 50 years ago). Agile methods are more or less fine too, after all they usually a summary of experience. But just like any other idea in this world, they can be misunderstood, misinterpreted or intentionally screwed. This is what usually happens during particular implementations.
My own experience with agile is we look at the principles and then take what we need. Things like iterative development and client feedback are pretty useful to avoid wasting time. Continuous integration to make sure anything we write basically works is also useful. If you push a simple block of code and it doesn't even work, what's the point in expanding your code at all?
I don't know about traditional manufacturing processes like building a house or whatever, but the only thing that matters is whether the end result satisfies the goals, which means we should always be checking to make sure we're on-track. Don't spend time writing 10000 lines of code only to find out it's not what the client wanted.
What if the client doesn't like to be bothered so much with progress updates? Well that would be kind of their fault ain't it.
In most companies worked in/with: Fatboys, post-its brainstorming and one person ending up doing all the shit work, while other are debating the future of work, society and the precise date when AI will cook lasagna perfectly.
In decent software company: splitting the work between a product team shipping user stories and dev squads organizing themselves to implement them. It might sound a bit restrictive, but it is a big, big move away from the "one guy a the top of the pyramid micro-managing everything".
The one part I have yet to see greatly implemented is the: Individuals and Interactions over Processes and Tools. Way too often, Agile becomes an argument over how you implement it and quite a complex machinery.
It’s a shortcut for not waterfall, that’s it.