Why Isn’t Agile Working?
hackernoon.com
hackernoon.com
Code is so specific and brittle compared to the lovely fuzzy English language that we think and write in, that we can never get the requirements just right. The biggest problem is integration of ideas into an existing system. Yeah ok you want to extend the login screen to support one extra field? That's great but after a couple of days work, it turns out that 2 years ago Joe Bloggs added some complex verification algorithm no one understands to a stored procedure, oh which contains about 30 other input fields, and so is going to take an extra week to untangle. The procedure is also used in 20 other places too and there's no unit tests covering any of the functionality.
Agile gives the programmer a voice in the process, and once they update the tasks and time estimates, the feature's priority can be re-evaluated. Treating development as a one shot process is just doomed to fail and more stressful for everyone involved.
Rather than try to ignore this, agile aims to treat it as a base truth, and work with it. Whether it succeeds or not is open for debate, but for most domains, I tend to prefer it over big, upfront design.
In theory, perhaps, but there are many places (everywhere I've worked) where the programmer voice is subjugated to project managers, product owners, and pretty much everyone else.
> once they update the tasks and time estimates, the feature's priority can be re-evaluated
Never worked anywhere that developer task and time estimates were considered as "truth" rather than something for everyone else to override or ignore based on external constraints.
Sorry for being a bit dismissive, but take the above quote and apply it to Agile. I frankly never seen it working anywhere, ever. Most of the times it actually made things worse.
But the requirement is to have a good team. And when you have a good team, most things work, agile or not :)
So yeah, I agree. :)
In that case – and I've said this often – the problem is with wider organisational culture and 'agile' or otherwise will not help with that.
I work in an environment where those estimates are just bluntly accepted, because they're the considered opinion of a team of professionals, and they're never overridden. If they are too high to meet some other business or marketing constraint, then we can start looking at ways to reduce the scope, extend the deadline, or incur some temporary technical debt.
I can't imagine having my estimates 'overridden' by anybody else and would not continue to work in an company where my actual, professional opinion about my own work was routinely ignored.
Or, like my wife, you are one of these people that are proud in a kingly yet humble manner -- and never allow anyone to step on them ever since early childhood. They seem to have a presence/aura that strongly discourages all dictators from trying to dominate them.
If you actively ignore the process, the process fails. People also expect too much of a quick fix. But change takes time.
I briefly worked in an environment where everybody was on board, and I have to say it worked really well, until new management screwed it up all over again.
Impossible, unless you work in a very narrow scope. Examples:
(1) I had to add several new parameters to an endpoint that accepted data from HTTP forms. It was a pain since there were mechanisms in the code nobody documented. Estimate: 1 day. Done: 2 days.
(2) I had to make phone numbers mandatory if your physical shipping address is in a certain USA state. Estimate: 3 days (loads of JS written by previous team). Done: 2 hours. Reason: they actually added an engine for such dynamic rules; after doing due diligence, the work was walk in the park.
(3) I had to allow a small part of our endpoints to be able to save to two different data stores. Estimate: 1 week. Done: 4 weeks. Reason: hardcoded Oracle SQL everywhere, had to rework 50+ modules several times.
(4) I had to improve helper modules that cached data from remote API that was painfully slow to proxy through. Estimate: 3 days. Done: 3 weeks. Reason: the current code that cached stuff was extremely superficial, didn't deal with cache expiration, and it didn't even work part of the time.
I can go all day. Point is, when you can do a lot, you get assigned a lot, and usually they are pretty different tasks. You can't reasonably draw any meaningful conclusion, except one: that an individual is over-estimating themselves. And even that is not always true because even at 37 I still don't expect at least half of the stupidities I find in legacy code that I have to maintain and evolve as part of a contract. I try very hard to not to be an ass, meaning I do not assume everyone is an idiot. From my perspective I give realistic estimates. In retrospect however, I probably should've assumed the worst 19 out of 20 times.
Your examples are what orginally was the reason for massive massive emphasis on code quality and automation ( I started out with Extreme Programming in 99 ).
Your examples are actually the whole point, if your code base becomes such that estimates vs actual does not correlate very well, then you don't use it to plan, you have too much variation. You look at what the cause of all the variation is, then sort it. It's actually good when it's no good for planning, it means you should have a bunch of obvious things to improve.
Estimates were, in the XP world at least, virtual. You could give them a unit of "JellyBeans" so tasks were either a 1, 2 3, 4 JellyBean level of effort. Then you tracked how many jellybeans you get done in a time interval. Plan based on how many Jellybeans you got done in the last time interval. You track the variation. If your variation essentially means it's not predictable, then you look at why, and improve that. You as an individual should also be concious of how you are estimating as well, if you "should've assumed the worst 19 our of 20 times" then do that. IT'S THE WHOLE POINT. It's a feedback mechanisim.
It's really important you don't blindly do planning with estimates if it's not working. It's meant so you can make reasoned choices about scope to achieve a particular time line.
- so either variability is good meaning you make reasoned choices about scope
- OR it's bad, and you make reasoned choices about improving the code base.
What I am saying is that estimates, even wildly incorrect ones, are over-valued and over-used. You seem to agree with that.
I was pretty self-conscious (still am) in why do I mis-estimate but truth be told, nothing much can be done most of the time. If you go the cautious route, management tells you "that's too long, reduce it". If you reduce it, it's very likely you'll miss that now imaginary estimate, and the whole thing restarts itself for yet another vicious cycle.
If you overwork yourself and manage to meet the near-impossible deadline, this becomes the baseline expectation for your productivity. One you cannot maintain for long. Yet again, management is unhappy afterwards.
All of what you said I can easily agree with... if we the programmers had actual decision power in the managerial hierarchy. Which we don't.
overworking is not agile, one of the 12 principles "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. "
but what you are saying is the common case of "let's do agile so we can get the software we want when we want".
and then, commonly, that is "a scrum like planning process" and buzz words like CI and tests.... but it's just not agile. It's why you feel like you have no power, it's agile practices used in non agile ways.
From my experience, ~90% of time is spent on technical excellence, 10% is the broader process, and the broader process get's tweaked regularly to adapt to changing circumstance
Yes and no. Yes, because almost nobody really follows an agile process -- the original manifesto seems to be lost on almost everybody in the area.
No, because I feel I have no power because nobody wants me to make decisions that even the slightest business implications.
This is wrong on many levels. I'll be the first to agree many programmers are naive as cocker-spaniels and only think of the technicalities and never of the real world -- sadly that's true enough. Those of us with a wider culture however can make huge impact, and we're denied the possibility because of prejudiced cretins in suits who actually have much less culture in different areas of life compared to us.
> From my experience, ~90% of time is spent on technical excellence, 10% is the broader process, and the broader process get's tweaked regularly to adapt to changing circumstance.
Nasty stereotyping, unless I am reading your text wrong. What I and many others have as daily reality (happily I parted ways with such employers but many others haven't yet) is:
- 40% of the time is spent in meaningless meetings: sprint starts, pointless bickering in status meetings, discussing a task for a longer time than it would take me to code a prototype half-asleep, personal vendettas concealed as coding style wars -- you name it, it's all there.
- 20% of the time is spent in documenting things you simply don't know right now. You're paid to spend 20% of your time as a fiction writer.
- 20% of the time is spent in actually coding. If you don't get interrupted 5 times an hour, count yourself lucky.
- 20% of the time is spent in "retrospects", mini-meetings, mid-sprint priority re-adjustments and the "Scrum master" trying to act like a big daddy to everyone while full-well knowing he can't influence his boss' opinion on when the final shipping date should be.
Only at dysfunctional organizations. Organizations without developers in the managerial hierarchy are almost universally incapable of developing software effectively.
It would be nice to actually spend time improving the codebase but unfortunately customers, marketing, and management have different priorities.
He's not saying it doesn't work at all, he's saying it often doesn't work when the developers aren't listened to.
Re-read the final section, or the conclusion:
Which brings me to Agile. Agile is worthless unless it serves as a catalyst for continuous improvement.
This is not my experience of "agile"; in practice, it's a conveyor belt of user stories in a feature factory, and developers are simply cogs in the meat grinder.
You can try and feed information in via estimates, sure, but that can only marginally change how the product evolves under the prevailing winds. Unless you give silly estimates, you have a hard time changing product management's mind much. And it's not a route for coming up with new features by recombining already existing work.
I have pity for you that you have to live with such a shitty product manager.
But don't think it reasonable to paint all PMs with that same brush.
Conversely, I could claim all developers are flat-food-eating basement dwellers who can't communicate with real humans. But that wouldn't be very fair, either.
...and these 2 PMs didn't last even 6 months. Higher management is not happy when its prejudiced idealistic picture of productivity and feature deliveries is challenged by reality.
A bit too cynical, I know. But it has been true in the majority of my office / freelance / consultant / remote work.
You couldn't be more wrong on this one. Managers love their power and they don't give it away to programmers no matter what.
In 15 years of career I've never seen a manager treat a programmer as a decision maker, not even once. And I suspect that's a biiiiiit more than "anecdotal evidence".
What usually happens is:
- "Why did this estimate change from 2 days to 3 weeks?"
- "Are you sure you're doing this right?" (coming from a non-technical manager)
- "Let me stop you right there. We heard your concerns but you overplay their importance." (that I can agree with sometimes)
- "This feature is important. Reduce your estimate, it doesn't look good to the people above us."
...etc. to infinity.
Agile is not, and never was, a magic bullet. It's kind of like some economical systems that only existed on paper -- sounds perfect in theory, is never implemented well (or fully) in practice.
Estimating story points for tasks when we know there is only one who has the skills to do it, direct conversions between time and story points. Countless hours spent in splitting and combining "stories" to make them agile sized bites. Estimation meetings that take half a day, where for every story only 20% of all the people who sit there can contribute.
I feel like this is all a big fat joke.
That's the problem there – the job you describe is not on a 'truly agile' team. It sounds like almost exactly the opposite – a focus on process, rather than 'whatever works'.
I work on a definitely 'truly agile' team – one estimation and planning meeting per two-week sprint, for a team of three developers, lasting about an hour. And it's great!
The problem is that if, when faced with example after example of something labelled 'Agile' not working, one discounts each as not 'truly Agile', then once one subtracts all those examples of Agile not working from the Agile literature there's nothing concrete left to prescribe other than "keep trying stuff until you find something that works for you."
There are some basic practices that are required for an organization to adhere to an agile process. Transparency, accountability, introspection... it really is basic stuff. And either they're doing them, or they're not.
If they're violating the definition of the process, they're not implementing the process.
If someone got into a car accident and didn't have a license, and I said "Yeah, but they aren't a qualified driver", you wouldn't invoke the No True Scotsman fallacy, would you?
These are concepts, not practices. And 'introspection', while arguably being a practice, is really, really not basic stuff. Introspection with actionable outcome is about as basic a practice as "finding inner peace" is.
> If they're violating the definition of the process, they're not implementing the process.
As seen even in just the comments on this submission, if someone follows the definition of the process as laid out in the literature, they are dismissed as being too process-focused and not truly Agile. If someone doesn't exactly follow the definition of the process as laid out in the literature, they are dismissed as not following the rules of Agile.
Agile has no "process as laid out in the literature".
I'm not even sure where this idea comes from.
The Agile manifesto is extremely basic. It contains a few core principles, and everything else is elaboration on them.
This organization is violating even those very basic tenants.
It's possible that, over and above the manifesto they're trying to implement Scrum or Kanban or some other process, and heck, they may be failing to adhere to those processes as well
But if they're not at a bare minimum attempting to live and breathe the values encapsulated in the manifesto, they are by definition not executing an Agile process, since the manifesto defines what "Agile" is.
Living and breathing values and principles entails putting something in to practice which means you need to put a stake in the ground as to "how", instead of just repeating platitudes. If you can't find three people who all agree on what "living and breathing the Agile values" means, then you can't practice Agile at team scale.
All you're saying there is that people have started using the term 'agile' too much, and applying it to processes or methodologies that aren't agile in the sense it was originally defined. I can totally agree with that idea, but it's a different problem – not "agile doesn't work", more "people consistently lie about being agile".
There's no true agile process, because agile is not a methodology.
So when people say I've worked on a true agile team, and then go on criticizing their team's process, you know instantly they're not criticizing the agile core values and principles, but are actually complaining about scrum or whatever made up methodology their management invented and then likened to make everyone believe that because of it the company shares, supports and lives by the agile values and principles.
If your read the manifesto (you know who else had a manifesto..;) The tone of the manifesto is all about getting shit done and communicating often. I guess thats the point. A lot of developers look normal, but are pretty terrible at communicating with the business, especially the non tech savy that are at the other end of things.
Agile like what your talking about kind of does this. But as other have stated, someone went on a course and is adopting agile like a cult. When the premise is actually to be flexible and allow for change etc.
TL:DR Agile helps bad communicators communicate a little less badly. But people usually fall back to trend.
Its not, but many companies get it wrong (sounds like your one does too).
In my opinion, a big part of the problem is that you get some manager types who thinks they're "doing agile" just by cargo culting it a bit and then wonder why it didn't work. Another big problem is when teams make up their own pseudo-agile (that is, they pick only some parts and change others saying things like "we work differently so needed to change it to suit us") and then complain that agile doesn't work when it fails.
That's why I like the GROWS Method [1] -- its designed for customisation because it acknowledges that every team actually is different and has different needs, but its also split into tiers that you should progress through and customising the process is a higher tier: you need to be experienced enough in agile to know what works and what doesn't work for you before you start to change or twist it into something else, otherwise you end up with an incoherent unworkable mess that adds more overhead than the problems it solves, or you have some pretend-agile that doesn't actually achieve anything. You need to get beyond that to what agile is (in my opinion) really about: getting shit done, aligning stakeholders and team members, communication.
Read the manifesto, apply some techniques, methodologies, frameworks that you hear about but always keep the manifesto motto of "constant communication and improvement of the process" in mind. You and your team should try different approaches and learn from them on what is working for you while keeping: 1. Communication 2. Constant feedback and improvement 3. Knowledge sharing
If only 20% of the people can contribute you have a problem with your team, not with the agile process to be honest.
My work ethics motto is to work for my own obsolescence, if you are in a team for more than 3-6 months and there are still people that really can't participate anyhow in a part of your tasks then your team is failing.
Of course I wouldn't apply this for a team where MAJOR higher education skills are necessary (like a PhD on some specific IA or statistics background) but really... 90% of this industry isn't in a team like that so there's a lot of room for improvements.
And please, be civil, I don't appreciate snarky comments (and neither does HN).
Agile meetings serve a few basic purposes:
1. They provide a venue to communication requirements from Product to Development.
2. They provide a venue for Development to communication questions, concerns, or technical details back to Product.
3. They provide a venue for external stakeholders to observe progress and provide further input on requirements.
4. They facilitate communication inside the team, both on basic status, but also in refining and improving internal processes through introspection.
You could avoid a lot of this by, instead, writing lots and lots of documentation covering requirements, processes and procedures, etc.
Or, you can hold regular meetings and talk stuff out.
You pick.
No process is perfect, but every process has to provide these communication channels in one form or another.
Of course, to a single dev, communication always feels like overhead. It's not.
That said, just a couple points in response to your rant:
Estimating story points for tasks when we know there is only one who has the skills to do it
Then your team should do more cross-training or be more creative about sharing work. Just because one person can code, doesn't mean other people can't test, perform code reviews, assist in writing documentation, participate in pair programming, etc.
Alternatively, the team is just too damn big. Including Scrum Master and Product Owner, you should be at no more than 9 people, and preferably 7. At that size, it's pretty hard to have only one person work on anything.
It's an absolute sign of dysfunction if, in your team, people think "only one person can work on that"... you're being myopic.
direct conversions between time and story points.
You're not supposed to do that. Your process is broken.
Countless hours spent in splitting and combining "stories" to make them agile sized bites.
That's a good thing, not a bad one. Small pieces of work are achievable and predictable.
Estimation meetings that take half a day,
Your process is broken. There are many ways to streamline these activities. Introduce timeboxed backlog refinement meetings. Ensure the PO is adhering to a strict Definition of Ready. Have a discipline Scrum Master who shuts down irrelevant ratholing.
And why aren't these issues raised and addressed in your retrospectives?
where for every story only 20% of all the people who sit there can contribute.
See above.
- complete failure to adapt to unplanned interrupt driven work, such as mid-sprint escalations, QA issues etc. Management rarely pull anything out of the sprint when a developer gets pulled to work on unplanned tasks.
- countless meta discussions about what constitutes a story point and whether it should be tied to time and just exactly what it means to be "agile". Agile discussions are starting to turn into "no true Scotsman" arguments.
- grooming and planning discussions often overlap in scope leading to exact same things being discussed twice
- management/senior staff pressures to trivialize tasks complexity leading to pressure to underestimate and little thought is given that not all developers work at the same pace across all technologies.
- sprints rarely finish exactly as planned, so a lot of tasks either get carried over to the next sprint or if they are finished early, it leads to even more unplanned meetings to decide what should be pulled into the sprint. I recently noticed among my colleagues who complete tasks early to just "ride them out" until the end of sprint.
In parallel universe they are on the same space ship with telephone sanitizers, hairdressers, jingle writers and accountants.
And before anybody tells me how rude I am I want to clarify I have been extremely nice and understanding.
Agile is in almost any form just waste of time. Wannabe mangers or HR professionals are parasitic foreign body in almost any IT related profession. But they talk better than we do.
Things that help are:
1. Having a project manager with at least several other projects to manage (discourages micromanagement).
2. The project manager should also be good at defending the dev team from distractions by triaging incoming requests into urgent bug fixes vs. waits until the next sprint planning meeting.
3. Having a product owner who does not act as a manager but as a consultant on a day-to-day basis (the dev team has to however appreciate that the producer owner is the person they are developing the software for). Ideally the product owner should be available but with some other work to be getting on with.
4. Having a professional development team that are more focused on delivering a product than building a CV/blog.
* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan
Even if your imaginary 25% were true, sales people can't sell what the company doesn't have (a product). Or at least they shouldn't (sadly I've seen sales people sell thin air many times).
Specifically, for me, agile doesn't make the development _process_ faster, it just encourages you to adapt more quickly and may (should) speed up delivery. If you want to make the _process_ faster, you have to look to other solutions (which are pretty orthogonal to agile).
For others, it's that slow grinding process of sprint planning, task estimation, pointless scrums and using estimation as some kind of metric for performance.
Then I took an agile course from the scrum alliance and the instructor only cared about Agile as a way of building "high performance teams". E.g get a group of people together, stay together, let them manage their time and they way they work to get the best usage out of them.
I've done all 3, to me agile fails because nobody really knows what it is other than they are doing "Agile"
And as soon as you say "Agile isn't working", you'll get a flurry of responses saying "You're clearly not doing it RIGHT".
There is also the other problem with complaining agile dosn't work - it's that there are no clear candidates for what does work.
To me, agile is mostly about measurement. If you have a process that is exactly as slow as what you did before you "went agile" but now you KNOW how slow you are, and you have realistic deadlines, know beforehand when you will miss them and so on - then agile mostly works for you.
Additionally: don't believe him, what's the problem with that. Just don't.
Agile gets you there fast, but the product is crap. Traditional engineering design results in good reliable products, but typically won't be either fast or cheap. Outsourcing everything to developing nations gets you cheap crap long after you needed it.
I prefer traditional engineering design, but I prefer to work with hardware so there's no real ability to patch.
The point is, agile development isn't magic and doesn't mean that more work will automatically get done. It doesn't work if it's imposed top-down, it doesn't work if the team are fighting it, and it doesn't work for every product.
It's a tool, like any other, that helps the team to respond quickly and incorporate feedback frequently, with the goal of making sure that the products produced are effective and fit-for-purpose. The work still has to be done, and if anything there is more overhead. But that can be a valuable tradeoff if it reduces cost elsewhere.
Being on a team that does agile properly is amazing, and it really is a shame that it's become so widely derided as a result of ridiculous consultants and the associated mess.
The real problem is that whole subculture of 6 figure Agile managers, Scrum-masters etc.. that preach their little thing as if it were a religion that leads to maximum productivity and dollars. But in the end it is only about their dollars. Most of those people cannot code, cannot design, have no vision, no skills whatsoever to build a product as what the team is actually doing. They sell themselves way more important than they actually are. I don't need a DRY coach or manager who helps me avoiding to repeat certain parts of the code. It's a very simple concept, don't need any coach for that, same counts for Agile.
In the company where I currently work they have now fully adopted Agile. Result? We hired for over a million dollars a year on Agile managers, Scrum masters, coaches etc.. We do meetings all the time, very structured indeed! My productivity as a developer dropped over 50% (and not only mine). But I don't mention it to these awesome Agile managers, as soon as they know I'm not a proponent my days in the company are counted.
It's like filling up a Formula 1 cars with bricks and asking why it doesn't go fast (an hyperbole, but the point stands)
Actually, I have been seeing things like that almost happening several times (firing 5 out of 7 programmers in a team, or firing the entire sysadmin/devops staff -- 9 people -- overnight).
Agile is a philosophy not a process. The process will differ company to company, and should derive by working backwards from the goal you want to achieve: "We want to solve the right problems for our customers".
What that ends up looking like, what you ship, what you DON'T ship, and how you do/don't ship it will matter entirely on your customer, your product, your company, and your specific team.
From my experience, people's negative experience with agile is usually because Agile is often adopted top-down as dogma with highly paid consultants and strict rules, instead of bottom-up as just another tool to do your job.
This comes back to the XP practice[1] of simple design[2] or "code that can change" which Fred George says has 4 properties:
1. Works
2. Communicates
3. No Duplicate Code
4. Least classes and methods
[1] https://ronjeffries.com/xprog/what-is-extreme-programming/ci...
[2] https://ronjeffries.com/xprog/what-is-extreme-programming/#s...
[3] https://www.youtube.com/watch?v=l1Efy4RB_kw
[4] https://gotocon.com/dl/goto-amsterdam-2015/slides/FredGeorge...
In reality, any system can be bad if you obsess on process over results.
A product manager once told me that I was past the code freeze date of his 6-month (heavyweight/waterfall) release cycle so I'd have to wait 8 months...to get a single file changed. When a VP overruled him and forced the issue this guy called me up to angrily complain how much "extra work" this would be for him and his release process (and I was just passing along the request on behalf of the business). Buddy, if your software release process doesn't allow you to change a single file in < 10 months, you're doing something wrong.
That's not to say Agile is a cure-all. I've worked at co.'s that insist on daily standup meetings so they can say they're "Agile", even if they have no practical value and are a time-suck.
I've seen mid-level executives obsess over the terminology -- t-shirt sizes, stories, kanban, scrum, sprints -- mainly to sound impressive dropping jargon in front of their superiors, even if no actual progress is being made.
Or they say they're "Agile" as an excuse to play "Etch-a-Sketch" with requirements, changing every few months because they're "iterating."
That being said, I'll take Agile over Waterfall any day. There's just too many unknown unknowns in writing a specific type of application for the first time to gameplan everything out in mockups successfully.
I think the bigger problem is mid-level bureaucracy at too many companies, and that would exist with or without Agile, IMHO.
Indeed, agile and its brother XP are pretty awesome concepts and ideas but have been heavily corrupted by well-paid "motivation experts" and "efficiency consultants".
Business loves making money on the back of people who don't understand a new concept well enough. I, like you, am sure that won't ever change.
I don't know, there is another comment[1] that might be competing for that title.
Both comments are gold though!
Plus it completely ignores the real world. Ie the release date is usually set as early as the rfp response/pre_sales stage and requirements are usually legally signed off.
It's a circus and I have no idea why is it played. 90% of all devs I ever worked with see this bullshit a mile away and laugh about it in coffee breaks. In every single place I worked.
Also they keep forgetting that if your system is developed with waterfall or no development structure it just won't support an agile way of developing. It's Conway's law...
It all depends on the people working. If you have bad people that doesn't do shit it doesn't matter what development model you use because the output will be shit nonetheless.
You can have a waterfall based team that produces a lot of good stuff in short amounts of time and you can have an agile team that does the same. The model doesn't really change anything.
But if everything is so bad no matter what you do, then it's not really anything to do with how to do software development, it's a whole different problem.
Clearly they didn't change everything. Given that statement, they failed to change the CEO's understanding of his role to becoming a servant leader vs. 'managing' a bunch of peons. If he's still walking around trying to tack accountability on anyone but himself at that point, he's the source of the problem and needs to fire himself.
Agile is continuous adaptation of methods to the particular circumstances of the team (both it's tasks, and it's composition in terms of individuals.) That's all Agile is.
The problem is that concrete fixed methodologies that are applied in the same way in widely divergent organizations under the oversight of gun-for-hire “master project managers” and other consultants, the exact phenomenon Agile emerged as a reaction against, are now being sold with “Agile” attached to them as a hollow, meaningless buzzword.
The Agile movement is in part to blame, because while the Manifesto has a great statement of values, there is no concrete operationalization of them embraced by the movement that emphasizes adaptation of process. (Which is one way in which the Lean community is a somewhat better forum for similar values, since it emphasizes more high-level metamethodology around evaluating and adapting methods, making it somewhat more resistant to being converted into a label for fixed process.)
Go back and read the Manifesto. Agile is not a process. Scrum is and maybe that's not working, but don't rip on Agile. It's four sentences.
If you’ve ever looked into DevOps, you’ve no doubt come across this “evolution” type image, with an ape type figure on the left, labelled “Waterfall” and on the right, you’ve got an android labelled “Continuous Operations”. Along this evolutionary journey, you’ve got agile, lean, continuous integration, continuous delivery and continuous deployment.
Agile is just part of the journey, not the destination.
I recently found this on how to deal with unplanned time when planning sprints: https://www.mountaingoatsoftware.com/blog/sprint-planning-fo...
It's not something I've seen discussed much elsewhere. Is there any other advice on this out there?
My current view (not backed by any numbers) is that the majority of widely used software started as an spontaneous initiative by a small group of developers or even a single developer that didn't use any formal methodology.
I started with Extreme Programming in 99, and watched the march to Agile tree hugging, hippy, non programming, consulting gold mine weirdness.
I barely know what people mean when they say "agile" now. I think anything that is some variation of scrum planning is considered agile
Agile is about understanding why these difficulties exist in the first place by realizing the human aspects of software development, and provide an alternate model for software delivery that is based on a pragmatic understanding of the complexity of humans and of software.
It's more about realistic expectation calibration and compassionate project management than turning developers into highly predictable and efficient machines, which sounds a lot more like the folly of waterfall development with fixed goalposts set years in advance.
The problem is all the wrong people have jumped on Agile and are trying to use it to "solve" a perceived problem rather than using it to better understand the human condition and taking a more pragmatic and compassionate approach - yes with accepting "we dont know" is a valid answer to a lot of questions.
The core point of Agile has been lost, because the people now riding it to death never understood it in the first place.
My experience with him really made me understand what agile is all about, and care less about the tools and more about keeping the original intent. That was transformative.
But people like cargo cults, so we should let them have their fun.
[0] For additional fun, we've had projects with 200 page of nonnegotiable specification that the customer wanted "to be done agile" (but any deviation from specification had contractual penalties attached).
From the blog post:
> And, unfortunately, I think time has proven me right. The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.
> So I think it is time to retire the word “Agile.”
> I don’t think anyone could object to a ban on the word when it is used as a noun. That’s just plain wrong. “Do Agile Right” and “Agile for Dummies” are just two of the innumerable attacks on the English language featuring the word. They are meaningless. Agile is not a noun, it’s an adjective, and it must qualify something else. “Do Agile Right” is like saying “Do Orange Right.”
90% of the capital A processes I've seen are actually the degenerate cases of Scrum where the company has simply encoded crunch-time into a standard practice.
Those who can do, those who can't invent methodologies.
Or they follow methodologies invented by others because they can't manage to get their own mess under control.
Process:
- Let us say a release is planned for January 2018. Projects are decided around June 2017. By the way, In Oracle RDBMS, a project essentially means anything more than 5 lines of code change.
- Each developer is assigned a project.
- The developer is given a deadline to write a design spec by August 2017. Developer spends 3 months in writing a design spec. A lot of bike-shedding occurs for those 3 months on mundane topics like whether a certain timeout should be 0.5 seconds or 1 second.
- Then the developer is given another deadline, say September 2017, to write a functional spec. More bike-shedding.
- Then the developer is given yet another deadline, say October 2017, to write a test spec. More bike-shedding.
- 5 months have passed and not a single line of code has been written. But 3 large documents with about 10000 words in total and another 10000 words of bike-shedding has been written.
- Finally, the developer is given another deadline, say November 2017, to complete writing the code with tests.
Results:
- Developer writes 10 lines of code and checks in their code by November 2017. Project completed!
- Everything looks fine for a few days.
- About a million or so tests run over the next few weeks. 1000s of tests are found to be broken. So much for 5 months of spec reviews! (Note: This happens for every such project, about 20 or so projects in a year.)
- The bugs are distributed to various developers. It takes them another 12 months to figure why each test broke, how tightly every layer and corner of the code is coupled with each other, and how they are solving the biggest puzzles of their lives: How to fix one thing without breaking 10 more things?!
- The original design, functional and test specs go out of the window. This is really bad time. Management is unhappy. Larry is unhappy! We got to fix those tests, no matter what it takes to fix them. Radical decisions are made as developers discover clever tricks to fix one part of the code while somehow finding a way to keep the other part of the code happy.
- 12 months have passed. It is November 2018 now! (Remember, the project was scheduled to be released 11 months ago!) It looks like everything is fixed. The whole 10 line project is somehow held together by tests. Nothing appears to be broken. But nobody is really sure.
I am glad there are other saner companies where people understand that waterfall model development is flawed and embrace agility. Having done waterfall for a few years, agile development is a breath of fresh air where I can spend more time writing code than writing documents, where I can evolve the code based on actual user feedback rather than feedback from bike-shedding by people who have not contributed a single line of code to the software.