We've found that agile is really only part of the puzzle. As your business evolves, development has to evolve too.
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.
The most successful software I ever worked on was entirely waterfall. You do need extraordinarily competent customers to make it work, though. I see very few customers good enough for it.
Agile wasn't supposed to solve big problems of software development, like how efficiency scales down as you add more developers or why it's hard to predict how long it will take to deliver X.
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.
Consultants selling shiny toys which may or may not be snake oil is nothing new. Consultants want products and services to sell. This probably causes some dissonance, as agile works only if the team and company takes owenrship of the process. If they try to buy the process from outside it's like planning to start exercising by first buying new shoes - it seldom works.
It’s funny reading your post : I’ve only known one really senior agile specialist, and he too put a tremendous emphasis on the human benevolence aspect, saying it’s the core of agile.
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.
Agile is the self-fulfilling truism that small, focused teams with a cooperative customer can create good software. If you create software in a contractually or regulatory heavyweight setting and are "doing agile", you're fooling yourself[0].
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).
For me, agile is about responding to change quickly: reducing the waste in the development cycle by not building stuff that isn't needed. That's an important step, but it has very little to say about the way in which you build the stuff that is valuable: it doesn't dictate architecture, approach, standards, or any thing else (except that onerous / long-winded processes conflict with the agile approach). Agile is great for developing things where you're not totally sure what the end result is.
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).
In a perfect world, agile is about responding to change, in reality it is about responding to change and to misunderstandings. I believe that the latter is even more important, but an emphasis on change might be helpful to sell the idea to people who don't think that it could happen while they are involved.
It's funny because everyone seems to go with their own ideas on what Agile is. I know companies who do agile and to them it's moving fast, loose requirements, etc. That is what it means to be "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"
Agile in almost any form is there because we, as a programmers, allowed HR 'professionals' to imagine what would it be to run our job. They have no idea what our job is but they certainly make sure to be needed even if they are not.
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.
Agile can be used in such a way that it gets management off the developers backs and empowers the developers to take their own decisions about how to plan their work and their time and to control how feature requests end up in their personal to do list (i.e. the feature request has to wait until the next sprint).
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.
The worst thing about agile is zero autonomy and zero ability to make decisions and be accountable/responsible for them. You never even get the feeling that you achieved or at least did something. And managers were not the biggest problem. Fellow developers with strong micromanaging tendencies were.
depends on whether we're talking Agile(tm) the package sold by Professional Management Consultants or agile, the handful of complementary practices and processes that can help a team run itself more efficiently.
The Agile Manifesto was written by programmers for programmers. Never forget the principles, even as the reality has been taken over by cargo-cult MBAs:
* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
is there anything more cliche than the jaded software engineer rant about how great they are and how bad everyone else is? In even tech. companies code is probably less than 25% of the overall picture of a successful company. get over yourself.
You are (1) generalizing and (2) responding to a rant with a rant.
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).
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.
Yep. I find it pretty comical when an externally hired "Scrum expert" is trying to motivate the team and make them work faster (somehow) while he/she full well knows the shipping date of the final product is non-negotiable.
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.
I think the software industry is doomed to forever argue about the definition of agile…
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.
Couldn't disagree more with this article, is this even written by a programmer? Agile takes into account the very real 'semantic cost' when translating from user requirements to actual code.
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.
I think the last paragraph is perhaps as important as the first one, though I wonder if it highlights the most poignant issues. In a sense, one concept agile is aimed at is that (most of the time) neither the developer nor the user / business knows exactly what the end result should be.
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.
> Agile gives the programmer a voice in the process
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.
"Communism never worked because it was never implemented in its purest form".
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.
Exactly. A hand-waving methodology means nothing when the people like what they do and they're professionals -- maybe even friends. I've witnessed that in both semi-agile and semi-waterfall teams.
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.
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.
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.
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.
estimates are supposed to be just that. You then compare them with what actually happened, then you can work out if the estimates correlate well with work getting done. The whole point of that is you can then start making decisions about scope / timeframe. If it's not used to make decisions about scope and time frame, then don't do it.
> estimates are supposed to be just that. You then compare them with what actually happened, then you can work out if the estimates correlate well with work getting done.
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.
yes, in the early days of agile processes the term "brain engaged" came up a lot when it comes to practices. You have to understand the purpose of things.
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
> It's why you feel like you have no power, it's agile practices used in non agile ways.
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.
> if we the programmers had actual decision power in the managerial hierarchy. Which we don't.
Only at dysfunctional organizations. Organizations without developers in the managerial hierarchy are almost universally incapable of developing software effectively.
> Agile gives the programmer a voice in the process
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.
you have a hard time changing product management's mind much.
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.
I don't hate PMs per se, mind you, but my experience for 15 years of career is exactly the same. I have stumbled upon exactly 2 out of 70+ PMs that actually valued programmers' opinion and used it to change project roadmaps and schedules.
...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.
> 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.
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.
Whenever agile "doesn't work" is because higher ups keep expecting the same (useless) artifacts and ways of working to be present. Including the biggest one of all: a fixed shipping date without compromising on features
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)
That's why I lay on the floor with laughter when I read the “Changing your management culture” point at the end. That particular event is literally the last thing to occur, ever.
Agreed. It's more likely that the entire technical staff will be replaced before even one manager changes the way they do things.
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).
If you argue agile isn't working, you must have some hypothesis of both what it is and what it would look like if it worked. I fail to see that in this article.
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.
The main issue is you can pick at most one of three from "good", "cheap", or "fast".
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.
> 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.”
I've been cringing at nearly every comment in this thread using the word as a noun.
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.
It's a good article, though the headline seems likely to produce a rash of comments that perhaps agree without reading :)
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.
It would be great to survey a large selection of software projects and see if Agile has positive or negative impact on the success.
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.
Worth noting those that 'Agile' is not a formal methodology and are most likely a set of principles that are already followed by the sort of projects you are thinking of.
Because Agile is a vehicle for selling books, consulting, training and speaking engagements. It was never intended to actually be used for producing real, working software in a commercial setting.
Those who can do, those who can't invent methodologies.
Because it was taken over by cargo cults like SCRUM who desperately try to turn it into a "process" forgetting the very first line of the Agile manifesto: "people over process".
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.
My current job is my first truly agile software development position. I have never spent this much time in worthless meetings ever before. I also never saw a team with a lower "velocity" before.
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.
Sounds like someone where you work swallowed a book on "Agile development" and is not capable of actually making it work for your company. I always encourage teams to take whatever agile process they're trying to use with a pinch of salt and make changes to / cut out parts of the process that are in the way, causing delays or don't make sense for that team. It's just bizarre when you see a team bothering to have retrospectives but don't have any power to change how they work.
I am working in one of MANY scrum sized, agile teams that all need to cooperate -there'd be no viable way to push back against the upper management. Also, my direct superiors are in love with the agile process, while pulling their hairs out puzzling over why it isn't working.
I don't think telling my "scrum superiors" that our management sucks and that we'd be twice as efficient by removing 80% of all agile bullshit would give us the velocity improvement they oh so desperately long for is a smart idea. Sorry, I have got to go now, there is a 2 hour workshop about how we can improve our velocity.
My current job is my first truly agile software development position.
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!
Your response, as do most such Agile defenses, suffers from the No True Scotsman fallacy.
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.
if someone follows the definition of the process as laid out in the literature,
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.
There is plenty of literature. None of it necessarily agrees with the rest, but Agile proponents over the past 15+ years have produced a copious body of literature. If you disown all of that literature, then all you are left with is some pseudo-religious principles, tenets and values, which is not useful for someone trying to improve a development org. It also make evaluation of its effectiveness impossible as there's no agreement on what's being evaluated.
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.
No, that's a misuse of the fallacy. To stretch it to breaking point, I am currently here with a 'true scotsman' of an actually working 'agile' process and it's all going well :)
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.
The big fat joke is thinking that agile are the processes and methodologies developed from the manifesto.
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.
No, I sit in a team where I'm the magical devops (I've been a backend developer for more than 10 years, took DevOps roles in 2 different companies, had front end and mobile experiences at some startups, etc.) and I love to share and teach my teammates when I'm the only person with the right skillset.
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).
Well, unfortunately, this all comes down to communication.
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.
I have been working in Agile or "Agile" for the past 7 years, across 3 different companies and noticed similar patterns:
- 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.
Agile is just a model, it doesn't reflect the real world at all.
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.
Sort of, the point of Agile is if it is bad, then you know much sooner than with waterfall.
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.
> Which brings me to Agile. Agile is worthless unless it serves as a catalyst for continuous improvement. Scrum and SAFe are worthless unless they serve as a catalyst for continuous improvement.
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.
I worked at Oracle for a few years in their database development group (internally known as "RDBMS"). You would be surprised to know that they follow a strictly waterfall process to perform database development. The results are horrible.
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.
Sure it doesn't work anymore, humans have innate ability to corrupt any outstanding ideas and agile is now finished. Post-agile was already formulated like 5 years ago. The only source of progress in humanity/tech is a few folks that work on radically new and effective ideas the "corruptors" can't yet understand, giving them time to do something of importance. Once these "corruptors" catch up, it's over for that given area. Agile is also very flexible, so anyone can put its sticker on a BS du jour and stay safely within bozoland, never achieving anything and preventing others from accomplishing something as well.
Most accurate comment in the entire thread. Thank you!
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.
Agile is nothing more than a methodology that can help a dedicated team to have a little more structure and transparency in the development process. Any team can easily do a weekly 30 minutes meeting to update on progress and issues. Also, a product owner can chop up epics into manageable user stories that can be done within 1 or 2 weeks (call that a sprint).
IMAO there is not much more to it.
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.
I sympathize with you. Time for another job, buddy. I am not saying this lightly, I fled three such companies and it hurt every time but always turned out to be the right decision in retrospect.
116 comments
[ 5.0 ms ] story [ 122 ms ] threadIf 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.
Get lost you slimey salesboy!
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).
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".
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).
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
[1] http://growsmethod.com/
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.
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
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.
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.
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.
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?
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!
[1] https://news.ycombinator.com/item?id=15413277
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.