Agile's early evangelists wouldn't mind watching Agile die
builtin.com
builtin.com
> During planning, everyone understood that the estimates were _estimates_. Tasks could take longer or shorter, that was OK and even expected. The goal was to improve velocity, not to accomplish every story, every time.
> Engineers felt comfortable taking stories in areas they knew nothing about. A stated goal was that every engineer understand every piece of the project.
> Standups were team only. Engineers felt comfortable saying they got stuck or needed help or got lost in a rathole and didn't make the progress they hoped.
> Demos were important so that the team and the clients could understand what had changed and what new features were available.
But it quickly got lost - managers and PMs and Directors got involved and Jira boards became published for all to see. (In the beginning it was whiteboards and sticky note). Standups and Demos were all about self-promotion. No one ever wanted to take on a task they weren't 100% certain they could do. If a task was 3 point it needed to be done in 3 days or there would be questions.
When I left the last company it had gotten outrageous. Every task should be completed in three days and in production in five days - and if not that team was Doing Something Wrong.
( We were told that this was standard FAANG practice, I have no idea how true that was )
What happened was what you'd expect - shortcuts, tech debt, unit tests cynically design to pass and meet code coverage expectations instead of actually usefully testing.
The reality is that any process is going to fail one senior leadership decides it's a way to evaluate engineers, not create a good product.
And as you say, managerial involvement is the problem. Managers and execs mostly get paid to appear to be in control, so having the appearance of control is vital to them, even if that makes the results wildly worse.
A better saying would be, you should only use your target as a measure.
If your target is working software, measure how well the software works.
In your imaginary case, what would your specific numerical measure be?
I've legit sat through 1.5 hour long calls with 6 other devs so we could watch our manager type notes into a presentation that he'll give to a collection of other managers who will only be half-listening until it's their turn to be visible, and all because some other, more powerful manager, decided this was important for the org to do.
It was layers of bureaucracy so deep I wasn't sure where I was anymore.
I've come to believe that that main driver for Agile adoption has come to be something similar. Making visible to outsiders what software development teams are doing, and making progress (or it's lack) visible to management. I thinks that's a completely reasonable expectation. Businesses are paying exorbitant salaries and providing ping pong tables, why shouldn't they have visibility into what's being done?
Where it becomes toxic is in areas this posts parent indicates; posturing, one upsmanship, pressure to perform. Effective teams need "safe spaces" to learn, discover, try and fail. Agile isn't that anymore. Hasn't been for a long time.
I can only say that IME a team is going to be a lot more productive if they are able to own their development process. Good infrastructure, knowledgeable engineers, healthy relationships instead of competitive ones - that's what creates a highly productive team and highly productive engineers.
The number one main headline takeway axiom of Agile is that this question is completely banned.
Agile is about delivering working software continuously, delivering whatever increment you get working at each timepoint, adapting to observed reality as it comes, and not having deadlines for specific features that might turn out to be impossible or harder than estimated.
If you babble around saying plans and deadlines are for suckers and that things will happen when they will happen, I am not sure they will keep paying you and your team's salaries for long. This new contrarian cargo cult of waving away any kind of medium-term planning or estimation is hurting businesses as much, if not more, as when all projects were waterfalled and timeboxed to death.
Yes, estimating is hard to get right. No, it does not mean we should simply get rid of it. Because engineers do not live in a little bubble of code: there is usually a whole company around them who need insight into what is getting built and when they can expect it. And anybody who believes that asking this question is too much or intrusive has never worked in a non-engineering position, or think of themself too much.
This process never stops, until you have some toothless PM slave driving devs because they're 8 levels removed from the strategic planning and they've pitched a 40-point/week development rate to their boss because they don't have enough information to do anything else. Anybody that tries to break the pattern is going to find themselves on the receiving end of an unfavourable performance review in any big business I've ever worked for.
There's a happy middle ground somewhere, where devs are given plenty of space to work but their output is still tied to the business's long term objectives. How you reliably reach that middle ground is probably a 8/9/10 figure question depending on the business.
A software system is an objective reality. It doesn't care what we want from it; it simply is. We can have intuitions about it, and use those intuitions to generate hypotheses about what will work, and ask the compiler / test suite to check them. But with a system of any real complexity, we're going to encounter surprising answers sometimes. We can't know how surprising, or how often, how long it will take to make sense of them, or what the ramifications will be for the rest of the project, until we actually get there.
It's not like we were producing useful estimates and then decided against it. They were always lies. Refusing to provide a medium-range estimate is finally telling the business the truth, that we have no idea. Instead we can tell you what we do know: the functionality we delivered last sprint, and the functionality we're going to work on next sprint. That is what you pay us for. The software actually delivered. Not bullshit promises.
But if you really do want a good faith, best effort forecast, then we need to plan the project in as much detail as possible upfront. Lock down the requirements, design the implementation, break down the work, and schedule it. Map out exactly what we're going to touch, so we can at least have a gut feel about how surprising it's going to be. That is waterfall. Own that, and do it right. Don't skip important steps and dress it up in agile clothing.
The challenge is that management is only looking through a small window and everything from promotions to raises to favours are dished out based on that window.
Anything not in view of that window immediately obviously becomes useless to one's advancement in a company, so the window better cover everything which matters and it usually doesn't.
Engineering is one of the only professions that is paid commensurate to the value they provide
Calling our salaries 'exorbitant' leaves you without superlatives left to describe executives that get paid thousands of times our wage, and at least they do work compared to the owners of capital who are 'paid' incredible money without doing any work at all.
To call an engineer salary 'exorbitant' you must be comparing it to the salary of people who function as modern serfs, and are not paid commensurate with the value they provide, or even enough to live a safe and satisfied life. Being paid enough for modest freedom and security is not 'exorbitant' though- no matter what you're comparing it to.
As far as business deserves to know what they are paying for, that is absolutely correct as well.
The problem is that business is not paying for story points. They are paying for actual product and delivery. So when they measure output by story points, you end up with a situation where teams are trying to maximize story points delivery, etc. as opposed to actual product delivery.
but that's the whole problem, if you constrain time, cost and result there's no any space left for agility.
the point of agile is to maximize the value of what can be produced with a given team within a given project, you picked time and cost and you apply agile to emerge stories that are actually important to you and push back on the gold plating.
if you have all three fixed, waterfall works just fine, actually even better.
The devil is in the details and in this case literally because the granularity of progress is too fine-grained to be exposed away from its context. The project manager or whatever you call the nearest person with power over your time needs some leeway to organize, ask for some extra, compensate, forgive, and reward you, without higher powers micromanaging. Freedom is the premise of responsability.
Absolute evil happens when customer demands access to hourly activity log for each developer in the (not on premises) project.
Is it? Maybe it's the opposite? Citation needed.
The question of whom things are visible to is an important one. Your comment says "management", and yeah that's one common way of thinking about it. But managers are just individuals with their own motivations. It is really "the business" that wants visibility in order to best accomplish its goals. There is an assumption that "management" is better aligned with "the business" than the employees they are paying "exorbitant" salaries to. But that may or may not be true, managers are also just individuals with their own motivations. So to the extent that it is true that managers are better aligned with the business, why is that the case? I see a few things that trend in that direction: compensation that is more tied to the performance of the business (through bonuses or what have you), more visibility into the goals and reasoning for decisions being made by leadership, and a better grounding in the dynamics of the business (what is the strategy, how does its market work, how does it make money). The theory is that because of those things (and probably others I'm not thinking of), the managers are better suited to be representing the interests of the business, whereas the engineers are just tools those managers can use to further those interests.
That is one way of doing it, probably the most common way, and it definitely seems like management visibility into work is extremely important in such a setup. But another way might be to align the engineers with the business in the same way managers are: pay bonuses based on the performance of the business, give them visibility into goals and decisions, teach them about the strategy of the business and the dynamics of how it makes money. That is, give the engineers ownership in the same way management has ownership, and trust them to make decisions that are in the interest of the business.
To put this another way: if you trust managers to make decisions about trade-offs that are in the best interest of the business, why can't you trust engineers as well? Are the engineers dumber or shiftier than the managers such that they can't be trusted with this?
that's crazy talk ;-)
Assuming that neither side is doing significant amounts of extracurricular work to bridge the gap, it therefore follows that management understands the business better, because that is explicitly the purpose of their job.
In a best case scenario, it makes sense to provide engineers etc. with the context to understand the decisions. On the flip side, business decisions are often made upon a huge heap of context that is generally invisible to the engineer (unless they spend an equal amount of time in building up their business knowledge, spending time in meetings, etc. - but at that point, they're basically a manager?)
It's not to say that engineers can't develop the background, etc. to make the decisions, but that it's not exactly part of the expected job functions, and not something that's explicitly looked for as part of the recruitment process. In a sense, this is a bit of a tautological issue.
What I'm saying is: what if we rethink specialization on this front? What if we expect it to be part of everyone's job to have deep understanding of and context on the business? Recognizing that there are significant efficiencies in specialization that we lose with this approach, maybe it still comes out ahead. Maybe the improvement in decision making outweighs the inefficiencies introduced by requiring everyone to be a businessperson.
Personally, I think this is a really great way to run a business, if you can get broad buy in for it. The best places I've worked have been those that most closely approached this structure.
But I will admit that this is biased by having a personality where I neither want to be "just" an engineer, nor give up engineering entirely in order to be a businessperson. I think lots of engineers don't want the business stuff to be part of their job, and I guess I can understand that, even if I lament it.
One interesting question is: if everyone is acting with the business ownership mindset more commonly expected of managers, what are managers supposed to be doing? My answer is that front-line supervisor managers are there to support their reports, help them get and understand the information needed to make the right decisions. At the higher level, managers are there to make decisions on tough cross-team and cross-organizational trade-offs. At the very top level, they are there to set and communicate the overarching strategy of the business, which everyone else should be using to inform their own day to day decisions. I think there is plenty of that kind of work to be done, without expecting managers to be making the day to day decisions.
Most often it is not. The problem is that management does not understand shit about software. And they usually don't care to learn about it. Hence this is about as effective as me asking for transparency regarding a COVID-19 vaccine. Yes, the practitioners could tell me they are in a phase-II trial. But to process that information fully and put it into context, I'd effectively need to study medicine.
What about the value of those who cooked your lunch? Without them, software engineers would starve and die, so that makes them have far more value, no? Do you think that food service workers are also underpaid?
Now contrast a Facebook programmer, who in one hour might be able to fix a bug that has been annoying 0.1% of Facebook's 2.5 billion users, causing them to be frustrated rather than delighted for, say, two minutes a day, for the next three years before the feature gets rewritten. Maybe that sounds trivial, but if so, shut up and multiply: 2.5 million hours of delight per month for 36 months gives you 90 million hours of delight, for the same hour of work.
So, at a rough estimate, then, the gourmet hacker is 1.5 million times as productive as the gourmet chef. Maybe if I've been overoptimistic it's only a factor of 100,000 or 10,000, but it's huge. And that's how Facebook can be profitable at all despite all the shitty and stupid things they do: capturing even a tiny fraction of the value they produce makes them wildly profitable, as long as they can successfully externalize the harm they do. Some software companies don't even need to externalize their damages.
And that's why software is eating the world.
That isn't the only reason hackers get paid more than foodservice workers. No business is going to pay more for its inputs than it is forced to; that reduces its profits. Hackers also enjoy a dramatically better bargaining position than most foodservice workers, because a hacker with US$3000 has a better BATNA than a cook with $3000: the cook is going to be trying to sell $3 burritos out of an Igloo ice chest outside of concerts while the hacker can buy a laptop, bring up a couple of VPSes on AWS, and spend a few weeks putting together a useful web service, maybe get a few dozen to a few thousand users, but at any rate can easily scale to hundreds of thousands of users. The cook is dependent on someone investing a few hundred thousand dollars (in the US) to have top-quality tools and a good location. Difficult to do yourself unless your family is rich or you graduated from the Cordon Bleu.
This is purely factual reasoning, so it cannot answer normative questions like whether it would be ethically better to pay hackers more or less. It only purports to explain the chains of cause and effect in the world that give rise to that situation, and illuminate the other possibilities inherent in the current state of affairs, and how they might change.
(Also I don't know where you're from that burritos might be sold out of an igloo chest, that just sounds gross)
That's what FAANG are competing against when they hire hackers. And that's still true even though most hackers didn't apply to YC last fall, because they can sign on as employee #2 or employee #20 with someone who did. Because the other factors of production are not scarce enough to matter, jobs for hackers are abundant in a way that jobs for chefs are not. Patents, noncompetes, H1Bs, the anti-poaching conspiracy, and API keys are efforts to change that, but mostly they haven't been very effective.
(What makes you think the cook is a "he"? Both of the people I was basing that sketch on were women.)
° By "talent" I mean "strenuous and persistent effort by highly skilled people", not some kind of inborn genius. You can't start a business by sitting around thinking deep thoughts; you have to work hard. But for a restaurant, working hard isn't nearly enough, and that puts foodservice talent at more of a negotiating disadvantage with respect to investors.
It's a fallacy to view anyone's work as less valuable when contributing to the whole -- everyone's work is essential in the ecosystem even if all they're doing is unclogging the toilets of all these knowledge workers toxic turds
Software engineers are perfectly well capable of making a sandwich themselves, bringing a packed lunch, or surviving on an empty stomach for a few hours until they get home. Not to mention buying lunch from somewhere else or ordering delivery food if one cafe is gone.
Unless you're positing a world where all food production, farming, fishing, etc. has vanished, then software engineers are in no worse a position than chefs, cooks, baristas, grocery store employees, or anyone else.
I have an idea! Let's call it DevFood, and make it a requirement for everyone.
I mean, we already expect the software engineers to analyze the requirements, so we don't have to hire analysts; we expect them to test their products, so we don't have to hire testers; and we expect them to do the operations, so we do not have to hire an administrator. So tell me, why do we have to waste money on an extra guy who makes the lunch? DevFood is the future of software development!
Their productivity would drop a bit, though. The idea is that people making food enable developers to deliver their best work.
Yes.
>Without them, software engineers would starve and die
Have you ever cooked your lunch?
this is not how prices are set. If you don't like how they are set then you don't like capitalism, where capitalists pay labour, and labour have to work because they need to live.
That's all fine, but let's be clear on how the price of wages are set. It is not "value created - some 'fair value'" for capitalists.
If people could refuse to work because they didn't have to pay rent and had access to the commons to get food or work for themselves, we might see capitalists having to share the spoils more.
But we have full enclosure.
Right, CEO salaries skyrocket, not necessarily because of the value they create, but because they can get the board and stockholders to back them more than the people actually creating value in a company.
They can do this in the form of stock buybacks, dividends, etc.
The standard software engineer does not have the power to "bribe" the stockholders in that way.
I realized that some level of not getting 100% of the value i generate is worth it to have someone else deal with all that stuff.
I'm not saying whether or not engineers are underpaid for the value they create but it's worth something > 0
I've been thinking of going the same route, and I'm confident I can handle the paperwork and deliver, but it's the finding the clients part that worries me the most. Not sure if the problems I see are widespread enough to warrant founding a business and going through all that...
If there were only a handful of qualified engineers available on the market, then they'd get paid CEO-like salaries due to the value they provide and being in high demand. But because there is a whole market of qualified engineers they get paid far less.
It's pretty basic economics and doesn't have much to do with stock buybacks/dividends/etc... Regardless of the value of an individual position, wages will be lower or higher depending on the supply of an occupation. In the big picture engineers are very replaceable at market price compared to executives so their wages are reflective of that.
This would be counter-intuitive, because low demand results in high salary, regardless of supply.
Nowhere is this more apparent than the so-called Hackathon, where you do days of overtime in exchange for a few slices of pizza and worse, are expected to be grateful to management for providing the opportunity to do so! Nothing infantilises the profession more.
Granted, one can filter out 99% of product ideas on a whiteboard but the remaining 1% is still enormously huge. And that 1% is actually the stuff that nowadays gets started.
Businesses are paying market rate salaries to employees who generate them revenue. If anything engineers should be the ones questioning the exorbitant compensation and perks at the top of the org structure.
> why shouldn't they have visibility into what's being done?
Because they shouldn't be micromanaging. They should be setting high level goals and expectations and giving teams autonomy and trust. Intrusive surveillance and low level metrics create perverse incentives that detract from those high level goals.
I'm not saying agile is the right solution, (it probably isn't), but expecting higher-ups to fund a black-box team is kind of naive.
"This just became a JOB..." -Gilfoyle
[1]https://www.youtube.com/watch?v=oyVksFviJVE S01E05 Scrum scene
I do like Agile, it's the typical problem of managers misusing it to micromanage, engage in useless metrics etc.
Reporting on random internal stuff instead of the actual problem at hand is the #1 problem I see with corporate reporting, everywhere. I see various combinations of people wasting time measuring:
1) The thing that is easy to measure, typically money or time.
2) The things they "understand", typically people for HR, compliance for legal, money for finance, etc...
3) The things their manager wants to know, no matter how irrelevant that is to executing their own job well.
Meanwhile what they should be measuring is the qualities of the end-product or the overall external customer end result.
It doesn't matter one iota if Bob the Developer Guy missed an internal 3-day deadline that John the Manager made up on the spot if the end product is a winner in the market and makes the users ecstatically happy to part with their money.
This happens everywhere, with everybody. For an IT-centric example, the common one I see is:
Helpdesk: "The users are complaining that the app is slow"
Admins: "The load is only 10%, but fine, we'll add more capacity!"
Helpdesk: "The app is still slow!"
Admins: "The load is only 5%! They should have no reason to complain!"
Do you see the issue? No, seriously: do you? Because practically nobody does, in my experience. Take a minute.
What happened here is that the admins measured the thing that is easy for them to measure: the load. There's a cute little bar graph in VMware, or a chart in their network appliance, or whatever. What they should have been measuring is latency from the end-user perspective, but that's hard to measure and practically no product tells you this number out of the box. So their entire process, their reporting, their troubleshooting, their forms, requests, everything becomes focused on the thing that they can see and control. Even if it's pointless, ineffective, and basically a waste of everyone's time and effort.
This happens with developers in exactly the same manner. Software quality is stupid hard to measure. Long term supportability is borderline impossible to measure without a time machine. Technical debt is hard to even explain to a manager, let alone keep tabs on in terms of numbers. So what's easy to measure? Time! Deadlines, sprints, release dates, etc... That's super easy.
That's why inevitably the unimportant internal time metrics become critical to everybody, but the actually important metrics aren't even measured and become invisible to management until it's far too late.
It is recognizable to many people, some of whom use it for their benefit, which can be very effective. When I learned that last fact a lot of things made more sense.
Which stops misunderstandings like throwing the code to “Ops” and expecting the VMware admin to understand how an app behaves.
User response time is a fairly simple metric to measure if you’re a developer. They should expose that, and other metrics, that the customer values.
This is one of the reason I’ve enjoyed some “true” agile teams with a strong product owner: they encourage an end-to-end focus on outcomes.
But time and money are the things by which companies live and die. Not keeping tabs on them is suicidal.
OTOH measuring time and money consumption of some technical internal steps is just uninformative.
The core problem with Agile (most forms of software management) is that it massively overweights "first mover" advantage. I keep hearing, as a justification of agile, that software needs to be delivered quickly so that the company can go to market first, and gain marketshare while its competitors are still floundering. But, in practice, that's hardly ever true. I can't name a single product that succeeded solely because it was on the market first. I can name many products that were first to market and failed because they were clunky and difficult to use.
Heck, Apple's entire business model consists of being second to market with a product that is more polished and easier to use than its competition.
Yes, if a developer or team is well and truly stuck (as in spinning their wheels on the same problem, week after week), that's a problem. But you don't need Agile to tell you that. A simple weekly status meeting with incremental demos is sufficient. The only thing Agile does is create a bunch of graphs that allow management to comfort themselves with "story points" and "velocity" so that they don't have to confront the hard reality that they have no idea what it is they want to build.
And for the pm to feel safe enough to communicate to you something is wrong.
This feels like a Taylorism. Knowledge work isn’t factory work.
I totally understand keeping tabs on delivery speed to enable the team to benchmark themselves but the act of identifying a problem from that (if there is one) should be the teams responsibility imo.
As a manager, my job is to enable other people to do their job the best they can.
vs.
"Not everything that can be counted counts, and not everything that counts can be counted"
Nah, you have it completely backwards. If the users said “this specific job took 5 minutes today but was only 1 minute yesterday”, that’s actionable, you can e.g look at what changes were deployed overnight.
But users always say “the system is slow”, even if they have only the vaguest idea of what “the system” is, and even if it’s actually faster than yesterday. It’s not really clear what any sysadmin can do other than spending hours every day painfully extracting the details from the user only to find nothing is wrong. Every day, forever.
That's not true. It's just that most sysadmins don't bother to upskill to find out what they can and should be doing.
> painfully extracting the details from the user
Asking users for any information is a recipe for disaster. Much like witnesses to a murder that can't agree on the most basic details, users inevitably conflate totally unrelated things. E.g.:
"Citrix is slow?"
"Okay, how so... are button presses slow to respond to a click?"
"I couldn't log on. Something to do with my password. It's slow."
"ಠ_ಠ"
So don't ask. Don't rely on your users at all. Build synthetic transaction tests that act like users. Measure end-to-end latency. Sit down with them and watch them work. Don't rely on their verbal feedback, use your own eyes. Use your tools. Measure. Then measure some more.
Conversely, capacity metrics are largely irrelevant in the era of 10 Gbps networks and 64-core server CPUs. Focus on latency. Look for delays. Timeouts. Deadlocks. Firewall packet drops. That kind of thing.
> only to find nothing is wrong. Every day, forever.
Of course something is wrong! Something is practically always wrong, that's why the users are complaining!
Here's a fun rule of thumb for you: For every 1 user that complained, there are between 100 and 1,000 that had the same issue but shrugged it off and didn't call support.
I got that from a scientific paper. I couldn't believe it, so I measured it in a large 10K user system. The error-to-call ratio was about 500-800 in ours. It blew my mind, and it blew the minds of a lot of people in IT management.
We started gathering every error, tracking every possible latency measurement we could, and it was a horror show. 30K app crashes per day. I shit you not. That's about 3 per user per day! Data loss. Hangs. Login failure rate of nearly 50%.
It tooks months to triage the issues, push patches, and apply workarounds. We had to rewrite several components. We eventually got the errors down to less than a hundred per day. Believe me, that was a real achievement.
Users were so happy they were begging to be migrated to the new system instead of pushing back and refusing to upgrade.
If the users are complaining, something is probably very wrong and you just don't know it. Go look.
I wish I had your user community. Here in Wales the ratio is reversed, I guarantee it.
There's an earlier version attributed to Mohammed - "Trust in God. But tie your camel first." - so the sentiment has been around for a while.
It feels like it's just a way of reducing cognitive dissonance, which is useful I suppose, but I wish people wouldn't use it because it allows a feeling of resolution without a real resolution of the tension between trusting and verifying.
https://en.m.wikipedia.org/wiki/God_helps_those_who_help_the...
You use this argument to defend engineers but then question c—level executive salaries. The exact same principles apply but at a multiplicative level.
That’s simply not true, workers and managers are qualitatively different. There are no shortage of examples of managers of companies losing money and marketshare who nevertheless are paid bonuses every year then leave with a golden parachute.
Why? That multiplier is often what's at issue, and why "the exact same principles" don't apply.
Having working software is line two of the Manifesto. They can run it each week and see whats new.
Even better, they can provide feedback on the working software and the team can then quickly respond to that feedback. In a week or two, when the outsider next looks at the working software they will see the software improved.
and it was understood and expected that this meant the estimate would go up
Today we have 'bidding', which if that sounds like something a three year old does to their parents, you'd be right, and it's the same thing. You just ask someone else until you get the answer you want to hear (instead of the one you need to hear).
It's not the same thing. It's not "bidding", even if it's called that because the lowest or highest or middling bid doesn't necessarily get the work. I know, I know, it sounds like another "you're doing Agile wrong", but Agile already fucked it up by saying "bidding", so we get these wild stories of how companies have their laziest incompetents in charge of trying to make improvements to process.
> You just ask someone else until you get the answer you want to hear (instead of the one you need to hear).
Otherwise you will only have the most jr or senior people working on everything. The system of bidding just doesn't work, which is why it's not bidding in a practical sense.
You ask why people put down their estimates by describing what they know about the work. This is an opportunity to transfer some cursory knowledge and reinforce pain points. At a very progressive "Agile" company (we would invite speakers and A/B tested various practices across teams), I notoriously inflated/deflated all estimates by bringing up edge cases and/or constraining objectives. Story grooming aside, there are always people trying to over-engineer and estimation is another gate to prevent that.
Agile was a good try to create software process, but it's incomplete at best. The idea that it would evolve is laughably naiive (https://app.spectator.co.uk/2020/04/22/the-illusion-of-certa...). Companies want S&Ps, not sauce that they have to mix themselves.
I'm talking about the dickering about whether something is N points or N-2 points. Or whether the points even mean the same between two teams. Or whether it's appropriate to assign it to another team or individual who says a smaller number because they have a different definition of Done or are more or less invested in the long-term health of the project.
I'm going to ask this person or the question in this way because I'll get the answer I like, even if that answer is unhealthy or even pure fiction.
One difference between those highly paid software companies and others, is the expectation of performance. Netflix famously considers their team a sports team rather than a typical corporation. It's totally common for a great engineer to bomb out of those companies, just like how great athletes get kicked off top tier sports teams when they failed to perform due to reasons out of their control.
While most other companies, lacking the ability or willingness to pay top dollars, are probably better off creating a safe environment for engineers who can be on-par or even better than FAANG engineers, but lack the political maturity to survive those high pressure environment.
I'm getting really tired of companies trotting out the "because [Facebook|Apple|Google] does it" excuse. Those are massive companies. Are we so delusional to believe that what works for a $70B/year company will automatically work for our $20MM/year company?
The idea that FAANG are faster then your startup is absurd on its face. The revenue and legal risk is absolutely huge.
It was a good way to get your head bitten off.
As a customer, you get to decide what you want to buy, and you get to be happy or unhappy with the delivered product.
But you don't get to control or even monitor the work in the factory/kitchen/etc.
That's instead the job of a boss! Of course, an agile team also has a boss. But it's not the customer.
But usually some proxy for the customer in your organization has to take on that role.
There are no "rules" in agile that says who can do what, just teams of people negotiating what works best for them. "Individuals and interactions" over process.
Not claiming it's inscribed on some sacred tablet.
Gonna play devils advocate here...would those two be mutually exclusive?
I feel there's a fundamental flaw in the garden of agile eden you initially described and that's trust...if you don't have it or lose it then gl trying to convince someone to essentially write a blank cheque for something they don't understand
If trust can erode a whole methodology then it's something to consider imo
It's certainly reasonable for those various stakeholders to ask for visibility. Demos are great for that, and a lead engineer or front-line engineering manager can work with stakeholders to establish some metrics to report on, but those are epiphenomenal to the process chosen.
I'm not saying it's a guarantee, just that nothing else really works well.
The primary point of Agile is to empower developers. If management is determined to micromanage them anyway, then Agile is pointless. If the term Agile is to have any business value at all, then let it be the stick with which developers beat some sense into stupid managers. Points are indeed rough estimates and can easily be off by a large factor, and they're definitely not meant to measure performance. Standups are about the team and about helping each other move forward. Demos are about getting feedback from stakeholders. It's fine if others see the Jira board, but it's not theirs. It's the developers'. And if a task isn't done, and it isn't done.
I fight for this if necessary, but fortunately I'm currently working in a team of very vocal and opinionated developers who take charge of their project and push back against managers if necessary. We do Scrum, but we're not dogmatic about it. We change the sprint scope if the situation calls for it. And we rebel when it's management that's calling for it.
It's well known that the systems an organization produces are bound to reflect the communications structures within that organization this is known as Conway's principle
In order to maintain flexibility in the design it's necessary to maintain flexibility in communication but engineers have no incentive to push for free communication and stick together to see the job done right, each of them is attached to a management minder who reports to a rigid top-down governance structure with very different ideas on how software should be done, effectively stifling any potential dissent at the source and acting like an authoritarian regime with the desire to divorce the workers from ownership of their work and turn them into compliant and productive cogs in the machine
The reason for this is not because corporacy sucks but because humans suck at corporacy and when placed in group environments of over a handful of people we tend to resort to mob rule and groupthink at the expense of culture and individual rights
It's rather complex but incentives are the clearest indicator of outcomes people simply have no incentives to help each other but every incentive to seek permission and recognition from management
In such an environment it's been postulated that four types of personalities emerge as people attempt to exert control and these are known as Control Dramas:
- The Intimidator
- The Interrogator
- The Aloof and
- The Poor Me
You can look these up there are several good articles online about identifying and mitigating these but it's not always just one but a combination that people exhibit
Framed in this context you can see corporations as implemented naively operate on only four cylinders even if it's only figuratively or intuitively true it's far from the humane ideal of what agile intended and this also has to do with metrics becoming targets and incentives trumping ethics
In the end we trumpet DRY and try to 'focus on our work' while we repeat the same inane insane dramas day after day expecting a different outcome that's the worst form of repeating yourself but we collectively walk into it in every case
I'm personally carrying a lot of resentment at the engineer class because we've been trained to know better but we simply can't get over ourselves and wake up to the fact that we're not just part of the problem, we are the problem but as such we also possess the solution if we really sit down and think about it
The solution lies in the following concepts
A) it's possible to have alignment and autonomy it's not necessary to choose between chaos and blind compliance
B) It's possible to have investment and productivity but it's necessary to trust people and that ultimately is where we fail
We should make "estimate" a banned word and replace it with a word like "guess".
Too often what starts out with an off-the-cuff chat about implementing some feature while people are getting coffee with a statement like "Oh I don't think it will be too hard to do this - will take a week tops <filddles with coffee machine />" etc ends up growing its own legs and becomming a gold-plated and irreversible commitment made to a director/VP/CxO somehow. What was a casual guess made without all the information required is now a rod for.our own back. Again.
Perhaps as engineers we should give ourselves a sort of mental style-guide to never ever say the words hours/days/weeks/months/quarters/etc without alarm bells going off in our head and requiring extensive peer review in the same way we do when we're writing "dangerous" code (e.g. user-provided values going in to SQL queries etc) Only half joking really :)
[1] https://www.scrum.org/resources/blog/commitment-versus-forec...
They saw a process that did an end run around them in favour of more self-management, and it worked well and got a lot of hype, that's terrible for their careers obviously.
So they fixed it and kept the same name for marketing.
Estimates are an interesting one. The theory of story point estimation is that you are estimating the size of the work being and not even implying, let along guaranteeing any notion of timing. That being said, it's still sometimes a valid question to ask why something is taking so long.
A great talk that I make everyone watch is John Cleese on Creativity In Management, it is a must watch for value extractors dealing with value creation that ultimately is creative work [1][2].
The open mode is allowing space, time and confidence. Closed mode is finishing/ship it mode.
"CLOSED" MODE
> By the "closed mode" I mean the mode that we are in most of the time when {we are} at work.
> We have inside us a feeling that there's lots to be done and we have to get on with it if we're going to get through it all.
> It's an active (probably slightly anxious) mode, although the anxiety can be exciting and pleasurable.
> It's a mode which we're probably a little impatient, if only with ourselves.
> It has a little tension in it, not much humor.
> It's a mode in which we're very purposeful, and it's a mode in which we can get very stressed and even a bit manic, but not creative.
"OPEN" MODE
> The open mode, is relaxed… expansive… less purposeful mode… in which we're probably more contemplative, more inclined to humor (which always accompanies a wider perspective) and, consequently, more playful.
> It's a mood in which curiosity for its own sake can operate because we're not under pressure to get a specific thing done quickly. We can play, and that is what allows our natural creativity to surface.
...
> Humor is a natural concomitant in the open mode, but it's a luxury in the closed {mode}.
COMBINING OPEN and CLOSED MODE
> Once we've taken a decision we should narrow our focus while we're implementing it, and then after it's been carried out we should once again switch back to the open mode to review the feedback rising from our action, in order to decide whether the course that we have taken is successful, or whether we should continue with the next stage of our plan. Whether we should create an alternative plan to correct any error we perceive.
> And then back into the closed mode to implement that next stage, and so on.
EXAMPLE
> ...one of Alfred Hitchcock's regular co-writers has described working with him on screenplays.
> He says, "When we came up against a block and our discussions became very heated and intense, Hitchcock would suddenly stop and tell a story that had nothing to do with the work at hand. At first, I was almost outraged, and then I discovered that he did this intentionally. He mistrusted working under pressure. He would say "We're pressing, we're pressing, we're working too hard. Relax, it will come." And, says the writer, of course it finally always did. We need both modes.
The world is value creators (product/engineer/creative/imagination) and value extractors (business/management/finance). Once the latter group get control, they end up squashing the "open" mode that is so key to making good products. The value extractors increase pressure but sometimes lowering pressure will let the product iterations flow to a better product end result.
Value must be created first before value can be extracted, but you can't force value creation with only the "closed" mode.
Value creation processes that make sure there is an "open" mode along with the "closed" mode are always more successful, and sometimes the "open" mode doesn't look like work so the value extractors cut it first unknowingly killing the product slowly.
The wrong type of Agile removes the "open" mode and cuts prototyping, iterations and refinement of creative value creation. A more open type of iterative development is always better.
[1] https://www.youtube.com/watch?v=Pb5oIIPO62g
[2] https://genius.com/John-cleese-lecture-on-creativity-annotat...
Agile is about culture and the culture of the pioneers and early adopters was different.
I‘m seriously thinking I should try to go more the Kanban direction these days to aboid the story point hitting / fitting in ever shrinking sprint trend.
The reporting is a whole other issue. I don't use this, but my PM does because upper management keeps changing their reports and my PM has to keep linking and organizing. But as a developer, doing spring planning and burndown charts work quite nicely.
It can still be evaluated on the merits but IMO this greatly pollutes the speed at which software devs as a broadly conceived community can come to consensus understanding of this.
Also I think the comparison to lean manufacturing has always been very shallow. I get the metaphor, I just don't think that human resources in engineering can be optimized like manufacturing processes. This quote is the best part of the article:
> "You’d never hear anyone say, 'We help mechanical engineers be agile. That would be silly. And I mean that in the worst possible sense of the word".
As for the rest of it, I'm not dying to hear what the person who invented Agile thinks we should do next lol.
I have literally heard this pitch.
More generally, it's correlated to it bringing some real or perceived advantage to the person doing the talk.
I mean, have you been watching the news lately?
https://www.bloomberg.com/news/features/2019-05-09/former-bo...
The closest it gets to that is where it say:
We follow these principles:
<snip>
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
<snip>
It basically states a set of attributes your process should exhibit.
Agile as I have experienced it in practice almost never displays those attributes.
The whole thing makes very little sense. I mean read it.
>"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more."
How the hell do you get from that to where we are today?
What it ought to say is:
"We value short feedback loops that minimize risk and maximize learning.
We value flexibility.
We welcome change.
We don't know what we are doing, only what we intend to do. The outcome is a guess. Our guesses could always be better. We strive to make them so."
First words of an agile consultant.
First words of the next agile consultant.
First words of an agile zealot responding to any complaints or negative comments about agile.
Agile has plenty of good ideas.
The problem is the almost religious following and, as you mention, the whole industry that has sprung up around it.
Even the initiators said that it was supposed to be a rough framework, to be adapted to your individual circumstances and teams. It was also a (much needed) counterpoint to the then prevalent waterfall model.
Now we have consultants, people strictly following something they read in a book or learned in a course, adhering to strict structure of meetings/processes, and even a big association with a single software product, Jira. ("You are doing it wrong!")
When you step back, a lot of the ideas make sense, and many teams will even implement similar workflows without having ever heard about "Agile".
Common sense has to prevail though.
It still is and it's barely in the fight still in some corners of the public sector.
If Agile dies (and SAFe might succeed there) then there would be nothing left except Waterfall and people others would call cowboys.
Saddle my horse.
Whether it was right, I'm not sure, but people have been happy with my work, so that allowed me a bit of leeway.
The team/organization has to become a learning organization. That means a number of things, but the critical one here is learning from past failures and successes and incorporating that feedback into their model (ideally continuously, but in Scrums it'd be the end-of-sprint retrospective). You start down a path, and you find it's difficult. You don't press on just because it's the one you selected, that's the way of idiots. You examine the hardships you're facing, and you address them.
> Now we have consultants, people strictly following something they read in a book or learned in a course, adhering to strict structure of meetings/processes, and even a big association with a single software product, Jira. ("You are doing it wrong!")
Yeah. Part of agile is that your process is an adjustible parameter. If you're doing it with a rigid process - any rigid process - then you are not actually doing agile.
Yes. I have found doing agile "properly" to be too rigid. What we need is something more flexible than agile.
Agile and Lean are empirical process controls, they are based on the same concepts. Ken Schwaber explains all this on the first chapter of his book "Agile Software Development with SCRUM":
Defined process control: same inputs always result in same output (manufacturing widgets on a production line).
Empirical process control: same inputs not always result in same output.
Schwaber conceived SCRUM (and was among the founders of Agile) after realizing software development required an empirical process control: give 2 dev teams same specs, 2 different apps will come out (they might do the same thing, but in different ways)
Which bothers me much, much less than selling things like CMMI/PSP certifications or EUP/RUP which are done purely for paper pushing and selling the paper value.
Agile is an improvement on waterfall and you don't need to be certified to do it.
Absolutely. And, having done some agile consulting long ago, I'd say it's more pernicious than that.
The people who truly want to make deep change in pursuit of deep improvement are a small segment of the market. Worse, they don't need a lot of help. In the aughts, I had a few clients who really got it after 3 months of focused work, and then they were off and running.
But a large company that only wants to talk about change and maybe make some 5% improvements if they aren't too hard? That can be milked forever. Well, I can't, because I care about results. But consultants who either don't care or don't notice? They're golden.
And I think this failure of the Agile movement has been obvious for a decade. I gave up on Agile conferences circa 2009, and wrote a long piece about this in 2011: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...
I've seen several director types get promotions promising to get faster and more reliable work out of existing engineers by implementing this new religion... Agile.
The results were always predictable. Layering more meetings and stress on people who already have too much work to do, doesn't help things. But, you're still vice president.
> > "You’d never hear anyone say, 'We help mechanical engineers be agile. That would be silly. And I mean that in the worst possible sense of the word".
This quote is silly.
To me, agile is just good engineering practice, applied to software. Of course mechanical engineers apply its principles, and have for decades before the term Agile was coined.
And as such, this practice is far older than software.
The Apollo space programme is my favourite example: the ultimate goal remained fixed (man/moon/before end of decade), but all steps of the way were discovered and redefined over the programme's course.
Mission objectives were changed depending on what was learned, often even in flight.
This was a very nice and agile (and sensible) approach, regardless of what it was called.
Of course, even more ironically, it doesn't fit the original agile manifesto:
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
I'm not so sure.
What's the official definition? Don't give me the manifesto, that's just an implementation of common sense in development, as applied to software.
As a trained mechanical engineer (maybe that's why the quote about mechanical engineers irked me especially), the agile manifesto just reads like good engineering practice to me.
And indeed the signatories of the manifesto expected to start a huge discussion on what agility meant for any particular team or product, and how to best live up to its principles.
> of course [it doesn't fit]
That was uncalled for.
> and especially any agile consultant's.
I'm (something akin to) an agile consultant though :-)
Also, just to point out: maybe my definition of Agile diverges from canon. That's OK. I don't care to follow the canon, I care to do right by those who I've been asked to support.
> Of course, even more ironically, it doesn't fit the original agile manifesto:
> > Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
I'm not sure how you came to that conclusion.
How is "welcome changing requirements" a bad fit for "changed the mission objectives (as new information emerged)". Clearly the [competitive advantage/likelihood of success] was increased? In fact the entire programme was shaped such that change was explicit part of the plan.
I've stared at this quote for a while now, and I still can't see the contradiction.
I understand why it would be super cool if software worked like that, but I have to iterate on features holistically and sometimes speculatively.
At least for me, software development has never been able to be so cleanly broken down into "first, implement the button" type tasks.
But maybe I'm just dumb.
YES. THANK YOU! I've been trying to tell people this for ages. Maybe other people are somehow capable of perfectly predicting every conceivable edge-case and consequence without even starting to work on something, but I can't. I have to start building something in order to see it clearly. And this ENRAGES certain kinds of managers, I have found.
Here's how you can solve your problem: Make as many tickets as you can think of, it doesn't really matter if they contain the essence of the problem or not, it just matters that there are many tickets associated with the task. Once you have your tickets, estimate them with as much padding as possible. If the manager complains that you're padding a ticket too much, make two tickets and split the estimate.
Once you have a big pile of tickets and estimates, you've bought yourself enough time to do the work. Go do the work, then mark all the tickets as complete. You'll figure out the edge cases as you go, as long as you've made enough tickets and time to do the job at a reasonable pace.
If you have extra time left over, get started on the next thing, improve your tooling, or try to help someone else with their tasks. If you don't have extra time left over, make more tickets next time.
My boss's goal is to try and get everyone to work every waking hour so we can deliver faster. My job is primarily to keep the peace between the executives and the workers. When I fail the workers, it looks like unpaid overtime. When I fail the executives, it looks like undelivered features.
I think the actual purpose of agile, from a developer's perspective, is to create more time to deliver quality engineering work product. From an executive's perspective, agile exists to squeeze developers into completing tickets faster. As a manager, it's my job to keep both parties as satisfied as possible. If engineers have enough time to build and executives get enough deliverables, then the company succeeds.
What's your strategy?
As I noted in a parallel comment, on my team, developers are never creating tasks on their own or in a vacuum. It's done as a team effort during planning meetings.
Perhaps I should add that my boss (senior director) has never asked me about my board, velocity, or anything like that. Discussion is higher level - "is project X on schedule?" or "are you going to miss anything on your roadmap?" not "why is task X or story Y not done yet?" If your director is asking that, he has too much time on his hands.
Asking specifics from higher ups is just smart.
I've reported to two different directors since moving into management. Both were very clear that they'd rather hear about problems early. And both have been nothing but reasonable when I've reported problems. Of course, the entire team needs to be reasonable for this to work, from the product managers to project managers to individual contributors.
And as a manager, nothing annoys me more than an employee who tells me everything is fine then misses a deliverable. Tell me you're having problems so we can find a solution. Please. That's why I'm paid what I'm paid.
Nobody can; that's the primary failure mode of waterfall. Anybody who is telling you to decompose a feature into that many subtasks might claim to be doing agile but they really are trying to do waterfall.
That's the primary failure mode of a straw man software development methodology called waterfall that Scrum practitioners like to use as a bogeyman to appeal to for rhetorical purposes during the inevitable arguments about niggly little details of how to implement Scrum during sprint retrospectives.
I've never actually done real waterfall, but I did study it way back when I was in college, and I have worked in government contracts, which tend to handle the work in a way that is similar to the waterfall I read about in school. One thing I distinctly remember is that it was designed to be a flexible and iterative methodology that would have been difficult to cram into a ticketing system in the first place, let alone cram into Jira while simultaneously carving the work into tiny pieces, up front, all at once.
FWIW, the only place I've ever been asked to do something like that is in ostensible Scrum shops. In fact, the only time I've ever seen anything that looks like the Waterfall of scrum lore is in shops that are trying to do Scrum. I am beginning to suspect that the Waterfall of Scrum lore isn't actually a thing that happens outside of Scrum at all. It's actually what naturally tends to emerge when you try to apply Scrum methodology in a situation where something along the lines of the real, textbook waterfall model would have been more appropriate.
As a concrete example, I currently work at a team that ostensibly uses Scrum, but where QA is a separate department with its own practices that the dev team does not control. They do still want some ability to anticipate work that's coming their way, though, so they're monitoring the scrum board for that purpose. This is the moment where it gets messy, because we're then asked to document things ahead of time, and it's a minor crisis if we keep it flexible during the sprint because any changes to the set of tickets becomes an inevitable hassle as they complain that we've screwed up work product that they generate based on those tickets. It's absolutely something straight out of waterfall horror stories from Scrum lore. But it's only happening because we're doggedly insisting on something that's at least cosmetically similar to scrum. If we weren't doing that, we'd be freer to choose modes of interaction and business artifacts that are better suited to the reality we occupy.
The biggest difference for Waterfall-in-Scrum versus Waterfall is that they've sufficiently (hopefully) decomposed tasks to have short target dates for delivering something to a test team or facility. They don't use it to get feedback from customers (the actual users, not the ones writing the checks). They don't use it to replan when things go wrong. They just use the whip and OT and get back on track.
Out of this chaos, eventually came order. It turns out what mattered most in practice, just like before, was pleasing managers and executives. Effectiveness was generally secondary. So what we ended up dominating is Scrum, the most waterfall of Agile processes. Most shops "doing Agile" these days are still following a top-down, control-oriented, ineffective and unrealistic process, just like before. But now they use Agile labels for their mostly-unchanged process, albeit with a faster release cadence.
* A quarterly release cycle is indeed fast. * 12-18 months between releases (ignoring perhaps bugfix/point releases) is quite common.
You write that "everybody knew that couldn't work" - for some projects.
Definitely agree with your second paragraph - except that Agile labels can be used even without a faster release cadence :-)
It has always been at systems thinking, design and architecture, in that order. Doing it organically is a magic feat rarely done well.
What I do with my guys is I make them decompose the feature, but with the understanding that they'll probably be jumping from one subtask to the other, back and forth, as they understand what it is they'll be building. AND they'll probably come across new subtasks as they work through the feature.
It makes Jira look crappy, but it Reflects Reality (tm) which to me is far more important than keeping Jira clean.
No, nothing is wrong with you. But let me note that the Agile Manifesto doesn't say anything about Jira, or anything prescriptive about how small to make your stories.
If your methodology asks you to do that, I'd argue that your methodology is broken. But it's broken because it's shit, not because it's "agile."
Yeah, it's hilarious how people are being told to do something in the name of "Agile" that is almost completely opposite of the spirit of the Agile Manifesto. sigh
Parkinson's Law doesn't get enough of the blame for bad dev environments. It's so easy to feel like you're doing 40 hours of difficult, important work a week, while actually accomplishing fuck all at best (or generating more work overall at worst).
I bet a big chunk of the problems raised in this thread don't exist if everyone experiencing them cuts their team size in half.
To be able to decompose a feature, you need to learn how to build the software in your head before you go to paper. Consider a large billing page, for example.
Step 1 is to look at the front end. What components do I need to build? (React might use components, or a set of partials and templates in rails, for example.) So, then, I know I need X subtasks, where I will build the pieces I need to expose that behavior to the client to start.
I then look down into the backend. That might be a simple task on the backend, or given 20 minutes of looking, I might see problems that I'll need to tackle. The problems are their own subtasks. I may be able to group some of the front end to a single back end ticket, or I might need a separate subtask for each.
Now, I'm likely to miss something. However, that's why this is an estimate rather than a concrete task list. It's to get started so that we know, at minimum, what it's going to take.
It's not necessarily simple, but it is a skill that can be developed.
Even easier than building the software in your head is actually building the software. I often don't know what the shape of the problem is until I've built something. The users often don't know what they want until they've seen something.
The failure of Agile as implemented is that it's still all about extensive meetings and planning. Software is not like building a bridge where you write out the blueprints and the expensive part is then building the bridge. Software is the blueprint.
To be truly agile is to be able to get software features and changes running and out to users as quickly as possible. You can never get all the information -- if users could provide the details absolutely necessary to build the software on day one then they'd be the programmers. Being experienced helps you naturally scope problems but you'll still be wrong from time time. Being able to iterate on users feedback and dealing with your own failed assumptions is the key.
This is the majority of estimation failures as far as I've seen. You can only "estimate" so far and then leave significant padding for all the other minutia that will likely creep in.
You should still have more granular planning, but it should serve the purpose of aiding the dev in completing the feature. You decide to do more granular planning when, as a dev, you look at a feature and go "The implementation is still ambiguous or I still have questions about how it relates to business goals".
Basically, invert the communication channels and shift responsibility to the devs. They have some loose business goals to hit, and the other staff provide support when they need it.
This solves so many problems I run into in enterprise dev. It kills Parkinson's Law (since the team members that are in the bottleneck are now responsible for the bulk of work generation within the team), it also gets rid of a whole class of poor decisions that are made without the proper context (since now you have a closer relationship between business goals and development).
First off, it means your code is brittle. Second is that you can't trust tests that must change every time your code changes. Might as well not even have them.
Unit tests are supposed to tell you if your refactoring is still working. For the most part, you should only refactor implementation details, not the "API".
There is also a design to uncertainty trade off. The less you know about something, the less time you should spend designing because you can't design something you don't understand. But the more your understand something, the more time you should probably spend designing.
Knowing how much design is too much is subjective and personal. I forget where I read it, XP(Extreme Programming) or Code Complete, but someone worth listening said, to paraphrase, "I've never regretted spending more time on design before I started coding". And I'm pretty sure it was part of XP that said the main purpose of XP(Agile) is to deal with the unknown. The more you know, the less Agile and the more waterfall you should be, saying that for some projects, a 6 month sprint is perfectly valid.
I am in an interesting situation where I am both the programmer and the domain expert. Generally customers come to our team describing a problem that other companies can't figure out. We're pretty much allowed to design everything how we feel like because we're the best at it. We can do virtually any project in a single go of it without feedback from the customer, but we still do agile because it helps with scheduling, planning, prioritization, etc.
We're a "value add" team, which makes things really interesting. None of our work is sold, but the work is important to land large contracts for the companies core services.
No, not at all.
Decomposing a new feature into digestible pieces is hard work and a skill that is learned over time. It's also a skill to know when something is small-enough, or has enough unknowns that further decomposition is wasteful.
Good product owners and managers know this and are good at it themselves. And the decomposition is typically at a story level - "can we take story X, break it into 2 smaller stories, and still deliver something of value?" The tasks are usually pretty self-evident once you break down the stories a few times.
For a lot of my work, if the story is "As a user, I need to do X" the tasks are simply broken into distinctly testable pieces.* Is there a database change? That's a task. Is there an API change? That's another task. Front-end change? Third task. And if you get half-way through and need to start over, that's life and it happens reasonably often. Yeah, there might be some re-testing. Or, a new story for next sprint.
It's up to me, as the manager, to make sure the stakeholders are informed and on-board. At the end of the day, as long as the team is making progress, I'm happy. And if the team isn't making progress, it's probably my fault (and almost never the fault of an individual contributor).
* In my world, tasks don't exist in isolation. They're all subordinate to a user story. Every task (piece of work) we do is done in the furtherance of a well-defined need of the user. And developers are never defining tasks on their own - it's done as a team.
Forget the developer for a moment and take the user perspective. What's the first thing the user wants to do? Log in? Ok, that's a story. What's the next thing the user wants to do? See a list of widget prices? Ok, that's a story. What's the next thing the user wants to do? Change a price? Story.
If you can't sit down and think of a dozen narratives like this, then the fundamental problem that you don't really understand how people are supposed to use your software or what your software is supposed to do.
(Also a user doesn't actually want to log in, they want to do something and you are making them log in)
The task of login is more about security, access control, authorization and tracking, not just giving the user access to a web landing page.
That level of complexity makes it a project in itself.
But sure, you can have follow-on stories like "user is denied access protected resource" or "admin sees resources accessed by user". Enough individually-useless stories and you end up with a useful app. That's kind of the point of agile.
It wouldn't be a complete decomposition, of course, a person watching would see your thinking unfold. I think speculative decomposition would be very interesting, especially in retrospective if we could see the rabbit holes we went down.
Decomposing is easy since we naturally have to do that as we work. Heck, those 500 tasks are probably in your shell, browser and commit histories, mixed in with a bunch of other junk.
The problem is tools like Jira make this heavy-weight, doing it up front makes it nigh impossible, and having others review all this stuff and it becoming promises blows up the LOE significantly. And, I don't think I'd want to be under that much of a microscope as I work.
But if it were very lightweight, where I'm just posting my thoughts and can see them as a quick dependency diagram, and maybe attach notes, commits and URLs to them, and other people can see them, that'd be pretty helpful.
That's precisely the objective of "user stories" and other things. You write a high level version, put it in a backlog with priorities. When you get to it, you realize it's bigger than anticipated ("Oh, I can't just do X, I have to do A, B, and C."). So you turn X into three things, one of which you work on now, and the others in the backlog. Repeat until done.
I don't think Jira is necessarily too heavy-weight, it's the way everyone seems to use it. They want to assign the tasks now, not treat them as backlog items or things that can be modified in the future. Which pushes them back towards big-design-up-front and entirely defeats the objective, you're back to low throughput, high latency development.
https://blog.codinghorror.com/tending-your-software-garden/
The reality is that your ability to break things down depends on experience. I’ve built so many landing pages, for example, that I can tell you an exact breakdown of tasks. Been a part of so many SaaSes, I can tell you exactly what non-core features you’ll need, when, and how much work they are. I can also predict where you’ll hiccup.
But ask me to build something new that’s never been done before (at least by me) and the most I can do is shrug and guess. Maybe give you a rough sketch of an outline of subtasks.
But as an example of early Agile intent, here is how we worked in 2004: http://williampietri.com/writing/2004/teamroom/
You'll note that we never did detailed planning more than a week in advance. We could have, but it would have been a waste, because it would have been speculation on speculation. Instead we'd agree on something small to build, get it working, and then see what we thought.
Here is why it is important:
a) Risk management - if you break a feature down into sub-tasks at any granularity, you are creating an agreement (or at least a conversation) among your peers that this is how something will be implemented, and digging in beforehand to uncover areas which might impede shipping the feature sooner.
b) You're going to have to break down the feature at some point. Being able to think through this ahead of time can be challenging, but often times is the meat of the work you do. You have to get into the hang of it -- think top-down or bottom-up ways of approaching it.
But what if you don't have enough information or understanding yet to do that? Agile is not great for these tasks where you need to take some time learning or experimenting.
I would offer you a couple extra tools here:
- A "spike" ticket -- Agile is all about deliverables and commitments, but sometimes that doesn't work. So create a spike ticket, and define what it is you want to investigate. If you deliver something, great! If not, no worries. The important part is that in the future you've done work that enabled you to learn how to estimate or break down that task in the future.
- A time-boxed ticket -- similar to the spike, but you just make sure you don't spend more than an allotted time on a task.
Basically, you blaze a trail to the most disgusting, kluge-y, and otherwise slapdash implementation that validates your assumptions and satisfies your constraints while making note of everything that needs further work. That lets you bail early if some unknown issue will block success given the current criteria and constraints, and sets you up with the a list of the 80/20 work required to deliver the completed project.
Some things need to be designed, and don't work terribly well if they're evolved incrementally from user-visible features. Incremental additions can be, but there's also a risk of gradually degrading the architecture of a system through risk-minimized local changes by interchangable resources, I mean developers - which is what I generally see occur under Scrum.
Company and developers are busy and successful, so they hire more, which continues until they are no longer successful.
They remain busy, however, progress on the product is roughly constant. All the additional work capacity is spent on meetings and otherwise organizing the increased worker count.
I believe the above describes every situation in which I have been asked to break down Jira tasks into unnaturally small tasks.
Maybe it was just my particular job, but so much of my work was figuring out how to do xyz, so it was hard to give estimates for something whilst I was still figuring out the scope and complexity of along with how it even works and I was rarely, if ever doing the same/similar thing multiple times. Whenever project managers did push for me to break things down further they’d then immediately complain about too much technical detail.
Which is to say: To all the people jeering for Agile's demise, please provide a superior alternative. I came from a world dominated by Waterfall, and I never want to go back to that. A lot of companies get Agile wrong, and it isn't a panacea, but it is much closer to what developers are naturally inclined towards (e.g. rapid incremental improvements) than Waterfall ever was.
So I challenge anyone who wants to replace Agile, please lean into how developers work rather than trying to mold their work onto your rigid front loaded methodology. Trying to bring in ideas of other industries, like engineering or architecture, that build physical goods and only have one shot at is a folly.
It was utterly frustrating to be powerless to improve specification quality and find out you built exactly what was asked but you were asked for the wrong thing.
The silos were horrible. Devs were often as bad as BAs, dev’s just were just crapping on the testers instead. Spare a thought for the production ops person at the very end of the chain. Here comes 3 months of developer work in one weekend and no it doesnt work but we’re still going live because the entire tech org is invested in this release. Now you have smaller squads, you can postpone a release without it looking bad on the top person and thus affecting your career prospects.
In agile models you have the power to fix crap processes that don’t work. You can call out any BS on the retrospective and make it super visible when things are being swept under the rug.
I worked on the customer delivery side of a $750M software project that was a steaming pile of shit, with critical defects that were known for a year with zero effort to address. The integrators were paid to deliver a spec, and it took about a year to get change orders created to diverge from the spec.
The old school waterfall outsourcing models are truly awful, but you don’t really understand how bad unless you’ve lived it. Stupid agile religious practices are dumb for any startup type org, but are probably better than the alternatives in many big enterprise scenarios, where the goal is chunk up the work so marginally qualified people can do something.
The goal of Agile is to let smart people work incrementally towards a somewhat nebulous goal. The ceremony that's arisen around that tends to be put in place by people who feel the need to manage, but don't know how to help their developers achieve that goal.
The alternative, as far as I've seen, is to hire smart, curious people, let them work closely with the end user, and pay them a lot of money. In this situation, the engineers will typically self-organize effectively.
Now it’s 100 people across two countries, expected to collaborate closely with sibling orgs. Management philosophy has shifted to “we will ask a few handpicked experts to write down the best way to do a thing, and then everyone else is a machine for executing that procedure.”
If software engineering worked like that, we would have automated it.
Assembling a talented team that ultimately delivers nothing of value is practically a cliche in this industry.
Agile would work much better if every implementation stated upfront, "Does not work right out of the box".
> Now, continuous delivery is what’s expected, and the industry is ready for the next thing. But that next thing shouldn’t be another methodology, according to Mary.
> There is no methodology in my field of software engineering that can conceivably last more than five to eight years,” she said. “Everything that is 10 years old is obsolete. Everything that is 20 years old is archaic.”
> Furthermore, she said, methodology requires codification. Beginning with the Capability Maturity Model (CMM) in the ‘90s, software development methodology meant developers had to show they had standards and that they followed them, rather than demonstrating that their standards were constantly in flux depending on consumer needs. That’s the definition of quality standards lean manufacturing practitioners in Japan originally espoused, Mary said, and they’re not compatible with methodology. Instead, they’re all about learning.
> To that end, Mary is excited about all the ways artificial intelligence will allow software engineers to learn better and faster. Automated testing, continuous deployment and cross-functional collaboration are now table stakes, Mary and Tom agreed. Cutting edge companies will discover the next great approach through an engineering mindset and a willingness to learn.
___
Consider that Mary and Tom Poppendieck were responsible for many of the Lean inclusions of the agile movement, which (largely) came from watching plant manufacturing at Toyota. Similarly, much of the DevOps movement was tied to this as well. If you want to talk about what is next, it is likely taking a first principles look at what we're doing today, questioning best practices again, and saying, "if we were going to make a manifesto in 2020, what would it look like?"
The only "strawman" here seems to be taking my point about pre-Agile methodologies out of context, and using it to dismiss the entire idea that this article is unconstructive/has no actionable solutions.
The criticism in this comment thread was that their advice wasn't actionable, not that actionability was a prerequisite in order to criticize Agile at all. There was no false dilemma here because there was no choices provided (false or otherwise), merely a weakness in an argument raised.
> “I don't care if it’s Lean or Agile, there’s no silver bullet where if you just follow this formula that somebody else followed, you’re going to be great,” she said. “So today, my favorite word is ‘engineering.’ Just let engineers be engineers.”
Maybe we need to call it the Lego process. SCRUM is Duplo. Waterfall is worse Duplo. Start there if you need, but get to Lego instead. Maybe Duplo is enough for you.
Which is not entirely true since some of the best parts of Agile are XP practices that almost everybody does by default now...
Someone once said that the only successful Scrum projects are also doing half of XP (as in, things Scrum doesn't prescribe but are essential anyway). I am still looking for a counterexample.
Give individuals ownership over different parts and then let them self organize, that is all you need if you hire competent people. I'll never work at a place which doesn't work like that again.
QE is a direct transfer of wealth from dollar holders to investors and banks. No way around that.
Gambling with unlimited amounts of other people's money is going to be profitable.
https://www.rollingstone.com/politics/politics-features/2008...
I suspect that most knowledgeable developers rolled their eyes when Agile was "invented". It's a mish mash of a lot of things that were already obvious at the time and some weird kool-aid like pair programming. And just one more in a long line of consultant enrichment schemes.
One of the reasons Agile (with a big A) is so successful is that its peddlers have convinced everyone that there are only two options: Agile and waterfall. When you're up against a strawman, it's easy to win. But it's absolutely a false dichotomy.
There's a quote in the article that I like:
> Find me an actual tech company that talks much about Agile, and I will be astounded.
In my experience, people at tech companies (at least the FAANGs) rarely talk about Agile, although they do talk about things like continuous integration/testing/deployment. They do not obsess over methodologies for how to move post-it notes around a whiteboard (Scrum vs Kanban) or agonize over how to word a user story narrative, or other parts of Agile Theatre.
People at some non-tech companies, especially those supposedly going through a "digital transformation", seem to have fully bought in to the crap that Certified Agile consultants are selling though.
So a superior alternative to both Agile and waterfall is what's in use at a lot of the big tech companies. For example, the engineering culture at Google, which relies on design docs and a very good set of developer tools and infrastructure. It's not perfect, but it's far, far superior to Agile.
And before anyone makes the argument that those non-tech companies are not doing "real Agile", but Google is, let's be linguistic descriptivists and accept that Googlers don't call their methodology "Agile", whereas the Scrum consultants at big corporates do.
That said , plenty of tech companies have inconsistent practices that don’t necessarily lead to great success. To say Google’s methods are “far far superior” to Agile assumes they’re uniform, portable or relevant externally, or that they lead to above average success. That’s debatable given Google’s reputation for abandoned half-built products and an almost comical lack of customer focus.
The big drawback to good managers is that they stand up for their teams and don't kiss boot the way bad ones might.
You don't need to buy entirely into a single methodology. When people say Agile in software today, they really mean the Jira-flavored Scrum. Some now claim that they've abandoned Scrum and you hear more about Kanban. Sometimes they really are switching, other time they're really just doing Scrum with a Kanban board. But again, they're often falling into the same traps of forcing solutions, rituals, and processes they might not really need into their flow.
You want to be Agile? Start small. A simple checklist is a good way to start.
"Individuals and interactions over processes and tools"
I think part of the issue is that Agile is meant to be a Process imposed from top down to improve productivity by X%, a way for management and a small army of backlog/task managers to say they are doing Something and having impact (or literally the only thing they actively do). Not only can it easily get in the way of that, it almost always fosters an environment of shaming and lack of trust, because it is too tempting for estimates to be taken too seriously or productivity/performance measured "objectively" by invoking the task-tracking system (in which case you incentivize only taking on very easy, very well understood tasks). It doesn't always devolve to that, but I think at many places if anybody Important up in the management chain starts thinking that way, it will inevitably trickle down. Thus any sufficiently large organization will corrupt Agile.
Perhaps some companies need that level of accountability and visibility, even knowing and disliking the drawbacks, but not all of them. I am honestly not convinced that a rigid process is necessary at all. Yes it makes sense to have a system where you keep track of things that need to be done, but if there's a culture of trust, I don't think the system needs to be gamified or fetishized as much as it usually is.
Big 'A' - "Agile" is waterfall re-branded - an excuse for corporate empire building and business as usual. It involves lot's of meetings and not trusting those who build software to do the right thing.
Small 'a' - "agile" is the implementation of the manifesto, which basically comes down to smart people figuring out how to work together towards a goal, often by taking small steps.
Until the terminology is sorted out the discussion can't help but be confused.
Hiring a consultant to teach 'Agile' is easy: the change of practices from something completely top-down to something that empowers the people at the bottom is the hard part and some orgs aren't capable of changing. Too many orgs are built around micromanagement, they don't know any other way.
We can talk all day about principle philosophical differences and what is/isn't 'agile,' but there has been a consensus from businesses in industry that 'agile' is 'Agile.'
Agile has become an excuse for terrible planning and offloading more and more work with ever increasing responsibilities to developers. At some point, enough professionals will reject following these terrible frameworks through different mechanisms. We're definitely not there yet, unfortunately.
Build software in small firms or consultancies who will treat it as a craft.
Maybe more a hope than a solution.
Once it got popular, "Agile" was co-opted by all the usual players (cf "extreme" before it, to a lesser degree).
The important idea is "agile" vs. waterfall, whether or not that includes anything directly recognizable as "Agile". Or call it something else, doesn't really matter.
Recent history shows you can certainly do things directly recognizable as part of the Agile methodology while demonstrably not being agile, so modulo the no true scotsman fallacy it's a much less fruitful distinction to draw.
I guess I'm saying "Agile" was/is one of several, and that's ok (good even). It's worth not getting bogged down on the "Agile" part and focusing on the more essential things.
You are correct. The Agile term was probably marketed to the management types as a some breakthrough methodology to _finally_ control the budget for software development. Then it took a life of it's own as many things do.
That being said. I think there is a lot of wisdom in the original agile manifesto. The core principles are solid, but the methodology has clearly been co-opted by consultants and supported by management looking to increase the headcount under themselves.
I've often struggled to understand why my team is made up of only 20% engineers with the other 80% pretending to create value by holding meetings to tell engineers what to build next when I feel like it's your clients that should be doing that.
Ultimately it's engineering that becomes the constrained resource which leads to technical debt in favor of pushing out product's features.
I would venture a guess that most engineers have used (critically) more software in their lives than any non-technical person driving the development of the product. Why then are engineers not the most consulted people on the efficacy and value of new features? I think there is a big myth out there that engineers are incapable of directly handling client feedback.
Creating the _right_ thing is extremely hard.
Here is what I think: I would place designers closer to the engineering (necessary) side of the spectrum. Designers do in some cases build tangible things, are very technical, and they approach refinement from angles of impact that some engineers may be unaware of.
I do think there are quite a few interpretations of what a "designer" does across many industries. In the field of software did you have in mind architects, UX, product, something else, all of the above?
The definition of engineer includes design in both it's noun and verb form:
"a person who designs, builds, or maintains engines, machines, or public works." "design and build (a machine or structure)"
But the definition of designer makes no mention of engineer.
As such, I would enforce that my designers are actually engineers and stay away from "pure" designers that do not have the technical foundation necessary to validate their designs. Design in a lot of ways is an emergent property of the engineering task at hand - unless we're talking about purely artistic pursuits.
I think it has survived so long because it provides its practitioners with two ace excuses: when things fail, they say, "what we did wasn't really agile," and when somebody proposes and improvement they don't like, it's always, "that sounds like waterfall." A team can't recover from their agile transformation until both of those phrases disappear from the team lexicon.
> “Way too much of Agile has been not about technology, but about people and about managing things and about getting stuff done — not necessarily getting the right stuff done, but getting stuff done — rather than what engineering is about,”
I'm not sure agile was ever designed to fix this. The whole process is really handy-wavy about the actual engineering: "we'll just make this a spike." The process also demonizes documentation and design work, which is antithetical to most engineering.
That being said, I love iterative development, and I like the concept of stories as descriptions of functionality. But I do think agile, as taught by most consultants, is really designed for consultants who build CRUD web-based applications. Sprints are timeboxed so consultants can charge by the spring, and stories lack implementation details because companies hiring consultants don't want or need to know how their sausage is made. The further away your product is from that area, the less effective agile is; some companies really need to design their sausage well, up front, because they are going to be eating it for years.
A process that's built up over years has become the way it is typically for good reason. And in my experience, teams forced to transition to agile will end up shoehorning their existing process into "agile" and calling it done, so most executives don't really see how their "transformation" failed.
I'm going through that right now, in fact for the past two years our team has been transforming into agile. Although when I say team, it's more the developers that are forced to work in an agile way. The business is still very much waterfall, but for them it's okay. If they want to throw a new story into the sprint, they'll just call it being "flexible", and adjusting to business requirements. It's not because they can't plan two weeks in advance.
There's also way to much time spend on story points, I always assumed these were estimates, to get a sense of how much can be achieved, if a story runs over, so be it. However here, these are seen as deadlines, a 3-point story shouldn't take longer than a day or two. Our "scrum master" is constantly asking wether we can achieve all our stories this sprint, what's the point of even estimating if you're going to do that. And recently, we now have to plan our two week sprint, day by day, committing to 2 week plan before the sprint even starts. There's nothing agile about that to me.
Here's another anecdote, a couple big teams that went the full SAFe route spent 3 years building something that ended up being thrown away and replaced in 4 weeks by 3 staff working part-time who were just given some instructions, some deadlines, and told to go code.
It's become repeatable, big teams toiling for years getting outpaced by smaller, more "agile", teams.
The balance has gotten out of whack again and it's really time to start over again. When I go back and read the original manifesto, what I see today in modern practice looks nothing like what was intended. The point in too many shops has been to accomplish the Agile things, not to deliver.
The manifesto itself says:
> Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
I get the impression as to what you're witnessing is, water-scrum-fall...
See: https://i.imgur.com/6eqk7eF.png
On the flip-side, your team of renegades managed to deliver in 4 weeks, while being great, I would question how sustainable that is. Also I get the impression they had skin in the game.
> what I see today in modern practice looks nothing like what was intended
You're 100% right. I don't think it means agile should die, I think it means people have forgot what it set out to do.
Scrum existed before agile and is a framework to help people work in an agile way. However people have got too wrapped up in the orthodoxy and have forgot what agile is actually about.
My mantra is simple: Release early, release often, listen to the customer
When I first got into software development it was because of open source software. On the SourceForge website, under the “Promoting your project” section, you’ll see it say “Release early, release often. Frequent releases state loudly that your project is alive”.
Years later, I learned that this philosophy was popularised by Eric S. Raymond in his 1997 essay The Cathedral and the Bazaar. Only, his version also says “listen to the customer”, an important part that’s all too easy to forget.
I just wanted to amplify this simple, elegant, statement. I don't have anymore to add, but this is a better statement than the entire Agile industry has managed to produce.
I thing “good, fast, cheap; pick 2” is still generally valid.
So I always felt that fast and cheap go hand in hand.
I think the triangle is:
- features
- quality
- cost (=both price & time)
Edit: I forgot to mention that you cannot just throw more engineers at a problem to make it go faster. There is such a thing as an optimal team size.
Another edit (sorry it's Friday evening here;)): The faster you can get it done, the cheaper it will be.
Therefore, if cost must be pegged due to limited time/funds and quality must be pegged due to existential risk then quantity/richness of features must float and be flexible.
All good product owners will learn this truth eventually.
This is unlikely to be true. Bad decisions are your biggest cost.
An employee has a "return multiplier" - for every dollar you spend on them, what is the return to the business? Sometimes it is high. If so, the developer is very cheap. Sometimes is it low, or negative. If so, the developer is expensive.
Why would it be high or low? Part of that is developer skill, but mostly it is how well your organization runs itself and makes decisions.
Organization is definitely a big factor.
But when I said developers are your biggest cost, this is from an accounting point of view.
Or until the ever-growing pile of garbage that agile produces gets too tall and tips over. Then you throw away the codebase and start again :).
I've seen this before. After the second iteration it becomes neither fast nor cheap.
Management was not a huge fan of this piece of paper.
“Way too much of Agile has been not about technology, but about people and about managing things and about getting stuff done — not necessarily getting the right stuff done.”
This is the whole point of agile: progress on iterations, inspect and adapt at the end of each iteration.
Your team might build the "wrong stuff" for an iteration, realize it (inspect), then make a course correction (adapt). If you end up delivering the "wrong stuff" is because you didn't follow this very core principle of agile.
I find it hard to believe these so called "Agile Early Evangelists" can make such a statement. Their background in lean development should have made the familiar with empirical process controls, from where lean and agile come from.
My guess the author quoted them selectively to fit the "agile sucks" narrative of the article.
Edit: expanded last 2 paragraphs.
Keep in mind though problems also show up with waterfall or young small startups. Its just which flavor of friction/pain project issue you are willing to deal with
I have been privileged to work in a company that really thought about and worked to prioritize the four values on the left. I would follow those agile coaches to any place they wanted. I have been a staunch defender in real life and online, because I've seen it work very well. I also have been on teams with other processes and seen how much worse it can be.
I will take the values of agile and push for those, and I'll take the lessons learned such as quick feedback loops, continuous integration, relative estimation, automated tests (which came from people like Kent Beck and Robert Martin pushing them so hard alongside agile), and the good stuff.
However, after seeing how badly it can be weaponized against developers, I'm certainly ready to throw out the bathwater, and I think this is what they're talking about. I've seen far too much cargo cult agile and far too much command and control with a light layer of SCRUM.
We have agile "coaches" who have never learned to code! They take a set of color-by-number technical practices but don't understand how or why they matter! I had to correct someone's slide that got the four values wrong, and their consulting group apparently had been copying and pasting them incorrectly from presentation to presentation!
The values and principles of agile are great. The current implementation has some serious debt.
(And while we're at it, we could update it. Too many people misunderstood the documentation part. Continuous attention to technical excellence needs to be upgraded to a value. Delivering frequently today means days instead of weeks.)
Poor management is a separate issue from agile. Even so, I would rather stay on a poorly managed agile shop than go back to a waterfall shop.
As far as the "values on the left", I like to explain them as a 55/45 split (and adjustable depending on your reality): we still deal with processes and tools, we just take a second to think whether a process is actually needed when we can just talk to someone instead.
Example: on a small team, you might just ask "can someone please approve my changes?" instead of having a whole jira workflow with code reviews and approvals.
The only alternative to Agile isn't Waterfall. The right alternative is probably something entirely new.
Which sounds a bit like the "no true scotsman" fallacy.
If so many people have trouble implementing agile maybe it just doesn't work?
The problem with agile and other empirical processes of project control is that it goes against the OCD tendencies of scientifically minded people. They assume that, since programming is all math and logic, software development projects should be as well.
They add micromanaging processes in a futile effort to control what they perceive as chaos and end up trying to fit a square peg in a round hole.
Agile was a neat idea 20 years ago and it changed the engineering practices. However, unlike the methodology, engineering practices continued to change and modern software development practices automate away a lot of what agile processes tried to orchestrate.
If you are doing continuous delivery and lean development, you should be conceiving of and shipping software features in time units smaller than a sprint (i.e. continuously). That was very rare 2 decades ago and has become the norm for a lot of tech companies. It requires asynchronous processes and practices. It's enabled by having automated builds, automated tests, and automated deployments. These tools barely existed 2 decades ago and have had a far larger impact on software development then any form of agile.
Lots of large OSS projects and software companies have made the shift from doing feature based software delivery to time based software delivery. E.g. MS famously kept missing its own deadlines with windows vista, windows 7, etc. and shifted to having a more predictable release schedule. Ubuntu's LTS releases appear regular as clockwork in April of every second year. Linux ships a kernel every 2-3 months. Mozilla ships Firefox every month.
Time based releases are basically about releasing an unknown quantity of software at specific intervals and with a high level of quality. It involves having multiple asynchronous tracks of development and instead of planning which of them need to be ready they simply use quality gates to determine which of them are actually ready to ship. It's a shift from what to when and it emphasizes quality (i.e. good engineering) over schedule.
Most agile methodologies are still stuck trying to do feature based planning. It's the project mentality from the nineties where things get commissioned and have to be delivered on a particular schedule. Worse, these things are often under specified and then blow right by their planned deadlines. Just like in the nineties. I've seen a lot of agile projects shipping low quality software doing the wrong things right on time.
If you want a stapler, you have to schedule a meeting 3 weeks in advance with 2 team leads and 3 contractors who decide what sprint "getting a stapler" will be assigned to. Then "getting a stapler" gets pushed back two sprints because some priority came along (a vice president somewhere just learned that his binder was on hold for four months). An Accenture contractor from India informs you that a hole punch is on the way. Apparently you checked the wrong box on the stapler requisition form, so you have to start the process over again.
Then the Accenture quarterly deck shows they met 97% of all stapler demands for the quarter! Isn't life so much more easier and more measurable now? But they will need to hire more contractors to keep up with capacity.
When you finally liberate a team from Agile, it's just breathtaking how much you can focus on delivering working software that gets deployed with quick iterations that's closely aligned with the business and customer's needs. When free from the tyranny of Agile, teams can be effectively self-organize, remove micro-managers, and quickly adapt to changing needs and requirements. My experience is that staff are usually much happier, more productive, and less stressed once agile is gone.
I mean contemporary Agile as pushed by corporations and those awful "coaches" (who never seem to be actual developers) --- if you were you design a system whose end goal was making great developers unhappy, unproductive and locked into a dysfunctional system, Agile would be it.
That's literally the agile manifesto.
"Scrum" is one implementation of what agile was trying to achieve. Maybe that's what you're thinking of?
I know, that's the irony. Agile as pushed today ends up with the compete anithesis of that. It's the difference between "Agile" (Capital A), and "agile"
Read SAFe Distilled or SAFe 4.5 Reference Guide for what happens in large enterprises (god SAFe is a fuck up). It consists of some good ideas, but also some very explicit practices that don't help in every effort (and sometimes hurt). It is literally the opposite of Agile, which is supposed to be about flexibility.
If you want to hear about its "success", just remember it was used for F-35's software...
Big-A Agile is based on the belief that adoption of practices is sufficient, and that deep understanding is unnecessary. This is the realm of cargo cults.
This is the example I use all the time!!
Maybe agile is great when you're making an online shopping cart for a e-commerce website, but the idea of using Agile for complex, engineered systems is laugh-out-loud hysterically absurd. And this does not just mean spaceflight software, it basically means anything more sophisticated than a CRUD app.
The thing people have to forget is the notion of "deliver on two week increments". It's not about delivering a product that can be fielded each increment, in the case of an embedded system, but about delivering something that has some improvement or new testable component. I can't make an embedded radio handle, in two weeks, a completely new message type (well, depends). But I can do things in each two week interval that is verifiable. I can show that I've actually received the new message, that I can send it back out, that I can pass it through the various internal processors (if multiple processors are used) or processes (if a single one). Then I can start transforming it, storing it, changing other things about the radio state based on the message contents. Each of those is independently verifiable and completable within a short period of time. But taken as a whole, it's a 6-month project. The agile way has you make those small things, verify them, and then move on to the next thing. I can deliver (to the test team, to others using the system) the partially-completed system, it just can't be fielded (and that's fine).
And that's not unique to embedded. If you only focus on things that can be fielded in each increment, you'll never develop the more complex tasks, or address the tech debt.
For example, there are days towards the end of the sprint when I’m not allowed to pick up new work and the infinite wisdom of the agile coach is that a ‘clean’ board by the end of the sprint is the what we’re really being paid to deliver (and starting something else would compromise that). This runs alongside serious customer deadlines which are hidden by the dates the Agile program runs by.
When you throw in the incentives of compensation and career advancement, politics and human nature are bound to corrupt the process further.
This is why codified process will always be better in the long run for most companies, because it's the only tool possible for combatting this
How do you create a paradigm or process that can be amended adapt to a persistent threat without that amendment process itself being used as a tool to corrupt it?
Bureaucracy, heavyweight process, and all rest are ways that systems protect themselves. Wasteful though, which is why new paradigms such as Agile come along.
Now the Agile ecosystem has become corrupted by a process not comparable to all the above. Not solvable by those means either. It’s a toughie.
I think that’s what’s missing in most companies. We have 360 reviews, retrospectives and all kinds of stuff but there is no feedback channel up the chain. At my company whenever there are obvious problems management secludes itself and then a solution will be revealed to the underlings who never got heard. Especially in tech it’s pretty safe to assume that engineers at the bottom of the pyramid are as intelligent and educated as people further up the chain so I think their input is valuable.
It is human nature that when talking to your boss you put things in the most optimistic way that fits your understanding, and your boss hears it even more optimistically. After a few steps up the chain this results in a complete disconnect from reality.
http://www.stamey.info/Humor/shithappens.htm is a humorous but basically accurate take on the dynamic.
Now, you say, reality eventually intrudes. Yes, but it is normal for upper management to not realize that deadlines will slip until about 2 weeks before they do. And will continue to think it is about 2 weeks off indefinitely.
I learned this the hard way, maybe 3 months into my first real job. I was testing safety critical systems, but it was still being developed so the tests procedures were also being developed and executed. I was asked for my status, I said: I've tested about 60% of the system (this one was small enough that that sort of statement was actually valid), everything has passed so far. My boss heard: Everything passed. He released the build to the customer, who found a failure almost immediately (about the same time I did, but I had no idea it had been released). I was taken into a conference room and chewed out for making us look like amateurs (we were, when it came to software). I learned several things: 1) I needed a new job; 2) Never use the words "done", "everything", "all" until everything is actually all done, managers only hear those words and nothing else.
> Now, you say, reality eventually intrudes. Yes, but it is normal for upper management to not realize that deadlines will slip until about 2 weeks before they do. And will continue to think it is about 2 weeks off indefinitely.
A manager, fortunately not mine I was his peer though he got promoted for his "successes", would always say that his products never shipped late. "How can you say that? I know your last release was 3 months late." "We updated the schedule and we hit the new schedule." "But you didn't update it until the last month. It was 2 months late by then already." "But we hit the final scheduled release date." He just got lucky that the customers weren't loud enough for his boss to realize the spectacular, repeated failure until after he got promoted. The new manager got hit with it instead.
Well, who would have thought :)
Me > Well um.. because I just thought ticket B is a three and this is comparable complexity.
Lead Dev > Yea... this is a two. I mean ticket B.. that can be a two too.
Me > Ok
Product Manager > Next ticket. Let's say a five? Or a four. Everyone hold up your fingers, is this a five or four
Me > (Looks around to see the popular choice. Holds up the same number of fingers)
He then went off on his own to talk to upper management and committed, without our input, to large new pieces of work, and was told what the budgets for those deliverables were.
At the next sprint planning, he was basically telling developers their estimates were wrong because the number of story points we were deciding equated to more money than the budget for those features.
Rather than play along, I simply said "Well why don't you come up with the estimates for us, then?".
To his credit, he did then stop trying to influence the votes after that, but it wasn't long before the product was put into maintenance mode and he was assigned to a different team.
This is not to say that management isn’t useful or necessary, but they are a facilitator of work, not the patron.
There's a lot of companies where delivering what the consumers want/need is not the end goal of the company, at best it's needed to help fulfill the end goal.
A key success of agile was to provide a buzzword that let engineers say no when they were asked for a fixed estimate for a fixed-until-it-changes scope to fit in a Gantt chart.
Take agile away and they'll be straight back to demanding to know how long it's going to take to build something when no one's really sure what the something is.
Bullshit. Back then, the term "programmer" didn't mean what it means today. A "programmer" was someone who entered a program into a computer, or even earlier, plugged in wires according to a schematic. The actual development of the program was almost exclusively done by men, even more so than today (this is not supposed to be a value judgement, nor do I want to justify the situation back then or today).
It's really disappointing to see this tired myth of a supposed "Golden Age of women in computer science" repeated in the article.
I teach CS in college. I see it every day. Women on average are more interested to work with people than men. This hasn't changed despite trying to boost girls' interest in typical STEM fields for 25 years. HR departments have been pouring money into this like mad. Hasn't moved the needle. Research has shown that girls don't fare worse in math tests if they are told beforehand that girls are worse at math. In countries where the sexes are treated more equally men more often choose thing-jobs and women more often choose people jobs.
Who thinks that if society would treat everybody completely equal, all occupations would end up exactly even distributed across the sexes? There are real differences between the sexes.
The push towards exact equal distribution in everything is futile, hasn't worked and will not work.
I think it's more important that people can choose to do what they want to do.
Sounds like a rant, sorry.
Your premise also confuses me as I would argue software engineering is more people focused than, say, lab work.
I believe that while societal factors have contributed to women pursuing specific career paths, if one was to factor that out or course-correct in some way you'd still see less women in engineering due to their preferences.
Is it wrong to feel like on average men and women are different in their preferences? This is not to say that there are not men who exhibit traditionally female preferences and vice versa. If we could undo the last 2000 years of societal programming (and run a new experiment) I think we'd see different preferences in men and women then we see today, but I seriously doubt you'd see 50/50 engagement across the board because men and women are distinct - although they certainly share a common set of attributes.
I keep hearing it touted as this kind of universal cure-all but I just do not think it is applicable everywhere. On a personal level, the more any given thing is touted to me as the solution for any and all problems, the more suspicious I grow. The more fervor, the more I draw away. The more cultish it seems (convert, adhere, rituals, special names, and then finally the narcissism of small differences in practice as exemplified by that old Emo Williams routine), the less I want to participate.
The more I have seen it shoehorned into places where it seemed ill-suited, the more this was revealed to me, yet the evangelism continues. Nothing like watching the tape backup guy, suffering from a flare of gout, hobble over to a room to perform his "stand-up" routine to hammer that home. Of course, we "probably weren't doing it right," but the more I have seen the slavish adherence to the strictures of Agile the more it seemed like this was an exercise in polishing a boss' resume so that he could say he had done The Things when he went elsewhere.
Reader, he did.
Perhaps the Agile that can be critiqued is not the eternal Agile.
https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...
Not a good start
The real problem doesn't seem to be that Agile is irrelevant, it's that Agile (and this is actually fairly quickly explicit in the Manifesto and accompanying Principles) cannot be limited to a siloed tech organization but must fully incorporate the business sponsor of the project, whether that's the firms business management for a software/services firm, whether it's an external customer for a firm doing bespoke software development, or whether it's an internal customer for an IT organization doing enterprise-internal development. And despite that being clear in the Manifesto and Principles, it very often is the case that “Agile” is seen as something the tech team is (or worse, does) that stops at their boundaries, and that fundamentally doesn't work.
There are other equally serious problems, like ritualistic adoption of fixed processes being described as “Agile”, which it clearly is exactly what Agile is most opposed to; the use of the phrase “Agile (or Scrum) ceremonies” is a clear sign that an organization has been infected with this toxic mindset.
And I'm not talking about just engineering - I'm mainly talking about customers and management.
Most of the gains come from tighter feedback loops between engineers and other stakeholders than tend to happen without an intentional effort. This works because it is simple - tell teams to talk amongst themselves every day, get feedback from customers more incrementally than you otherwise would, etc.
Most of the rest of the promised gains need better disciplined customers and managers - ill-defined specs, dropping projects to pick something else up, only to switch back a couple months later, managers who don't pay enough attention to what's being done until it is too late, etc.
Perhaps the problem is that it is a management fad aimed at engineers. It needs a v2 aimed at nontechnical people, "become competent at asking for what you need".
- development becomes a 1st-class "business" activity a la accounting, sales---not that you necessarily do it as aanger, but you're looked down on if you can't
- a culture of "ask about the internals" becomes prevalent, where anyone who bought software without knowing how it worked was looked on as an idiot
- developer coup
He subsequently gave a talk comparing agile (and open source and consulting and startups and...) to fascist propaganda. https://www.youtube.com/watch?v=c5Xh2Go-jkM
I'm not promoting it or saying I agree with it (I actually disagree with quite a bit of it), but it is entertaining.
In places I've worked without the pressure of the quarterly earnings report I've seen that developers tended to use whatever methodology worked best. It could be Agile, pair programming, or just walking over to each other's desks and talking on IM.
As far as I'm concerned, "agile" refers to the principles on this page[1], and ONLY the principles on this page. Not Scrum, not Lean, not Kanban, not Xtreme.
The problem is, it's hard to sell a set of principles. To understand people and interactions takes months of working with people: it's much easier to sell them a process or a tool and leave. Customer collaboration requires building a relationship: it's much easier to negotiate a contract for your client and leave. Responding to change requires you to stick around and see what changes happen: it's much easier to sell them a plan and leave. And to arrive at working software you have to get a lot of things right: it's much easier to sell a bunch of documentation for software that doesn't exist, and then leave. Money ruins everything: the reason agile had to explicitly deprioritize the things on the right side of the list in the first place is that all the incentives in a software company push you toward the wrong priorities. The things on the right side of the list are all quick, easy wins that look good on a quarterly report.
There are companies who I've worked with who do agile (the principles) well. There's nothing wrong with looking at Scrum/Kanban/whatever as inspiration, as long as you realize that they're just processes: individuals and interactions matter more. There's nothing wrong with using Pivotal/Jira/Trello/whatever, as long as you realize they're just tools: individuals and interactions matter more.
> Engineering is about seeing a problem, understanding it and using the technology you’re good at to solve it as quickly as possible.
Everywhere you turn to there is someone thinking that speed is the most important thing ever. Everything must be done quickly. The best way to do something is quickly. If something takes longer, it's clearly worse.
Even in an article about "the problems with Agile", people still fall into the trap of speed.
Engineering is clearly not about solving problems "as quickly as possible". It's about solving them in the best way possible, where you first define "good" as a balance between all the advantages and all the disadvantages of each possible solution. Speed is but one of the factors you evaluate.
This was/is literally true at a place I worked. Their official enterprise Agile process includes a long list of mandatory documents, one of which is a list of all sprints and sprint goals for the duration of the project, that must be checked into a document control system.
I so hate the use of the word "resources". so dehumanizing.
SAFe is everything that has ever been wrong with the software industry rolled into one terrible thing that is anything but agile.
I can't fully express here quite what I think of it!
So it was done using agile diagram methods?
The other issue that agile conferences don't have developers anymore.
Tech guys like to do the same. One director once showed the "architecture" of the next big thing in our department. It was a bunch off boxes with "authentication", "JSON", "distributed", "NOSQL", "JSON", "Roles", "reliability" and twenty other buzzwords. He asked for estimates how long it would take. after asking what this means and what it's supposed to do I was out of the planning. Two years later there are still two guys developing it but nobody knows what it does.
I said that it would take me 5 minutes to go into Jira and close out all the existing issues if that is what they are worried about?
The only long term solution for us was to have days dedicated to Agile ceremonies and days where no team member can be interrupted based on an agile ceremony need (there were few exceptions, like critical bug discovery, etc.). In weekly sprints, we had at least 3.5 days of uninterrupted time and in two-week sprints we had 7-7.5.
That changed a lot the pace of those sprints as people had a lot of time to do their job and everyone was happy.
And if they really want to consider all of that in a dichotomous way. Who really does not want "working software", and why would I even have to "prefer" that? this is just too much fundamental that we could as well say: we don't want to work on garbage projects, and it is stupid to have an extremely good documentation of a pile of crap. But why jettison documentation if "working software" is not even considered optional to begin with? I fucking want stellar documentation. Because why not? I'm tired of reading source code all day to try to understand what things were even supposed to do...
In some industries "agile" in its original definition can make sense. In others, not at all. Yet, tons of people will pretend they do "Agile" regardless of what it is, what they think it is, and of what they do. This is sometimes some kind of management virtue signaling; except it is not signaling positive things anymore to those who work.
It really has no meaning anymore. To be honest I'm not even sure it ever had, as implemented by most, out of the industry it came from (with associated practices that were also highly contextual)
People should just avoid focusing on fashionable shallow words, and skip right to the ideas: if all of Agile and even all of Scrum is what will make your project shine, just do it, but writing essays about it is not really doing it, nor is pretending it is a kind of universal panacea, nor constructing consulting services around cult practices. If you must do the complete opposite; do the complete opposite. And tell everybody you are "agile" without an once of shame, if that can help raising money or stupid shit like that -- I mean what is even more agile than doing otherwise than "Agile" if it is a better idea in your context; so you are not even lying :p
Problems begin when that gets forgotten, and following the process becomes your job -- not following the process is doing your job wrong.
Always remember that your job is to build stuff, any way that works.
If you just "step back" from trying to control the average bunch of engineers, they will miserably fail, because they have never gone to a school that taught them how to rapidly drive business value through software. If you hire the right people, they already learned all of that, and so they'll be successful.
That's how the Netflixes of the world survive. Their organization and process would seem totally insane to any "average" tech engineering organization. But it works for them because they learned how to work together the correct way, the business got the hell out of the way, and it also invested a ton in helping them do what they need to do.
Agile does not give you any of that. Agile is just a promise of what should be happening, but it doesn't tell you how to get there at all. It's a pipe dream.
Agile is not the problem, though. It's businesses thinking the engineers are simple tools to be used to produce widgets, and if they just shove enough extra business roles and processes around the engineers, that will end up creating value. But the solution is actually to remove all that extra crap, and get the engineers to do everything in a way that the PMs and DMs and QEs etc are no longer necessary.
I guess we'll have to see if we ever have a major health care crises. Wait...
And we wonder why the hospitals didn't have enough PPE on hand. Did the MBA virus spread to hospitals and did they misapply methodologies like Lean where it had no place, except as short sighted cost cutting?
One of the major problems in industry I've seen again and again is management, etc pretending they know more about the job and it's requirements than the people doing it.
As Lean originated in manufacturing with the WORKERS making the improvements and the WORKERS being empowered (anyone could stop the line if there was a problem) it's bit ironic that a corrupted version was used later to beat workers into submission and achieve petty cost cutting versus process improvement as in the health care anecdote above.
Calling it a to-do list instead of user stories? Not aligning teams on where we are in the to-do list regularly and removing and adding things?
Agile proponents often say "waterfall", but I have no idea how you would go about working waterfall day to day.
Would you just make all your user stories/to-do's on day one and never update them and now you have waterfall?
Having entered the industry long after agile became the new normal, it seems like the whole discussion is either "stand-up sucks" or people discussing variations of what is essentially "Regularly report where you are on the to-do list, often update the teams to-do list", but never "Why not this different paradigm instead".
Maybe I am lacking imagination, but I am not really sure what a serious alternative is here.
If that's part of the original reasoning, then it was very random. R&D has not much to do with manufacturing. So I would greatly prefer an actual example from "product development" rather than car factories...
I mean what build our software is e.g. gcc. I don't know if gcc is feeling lean, and actually I don't care much :)
As an ops type usually only on the peripheral of sprints etc I feel I don't fully grasp the nuances of the different methods enough to really comment, but that just really got my attention for some reason.
Found the video, linking at the timestamp that includes the manifesto for agile (which I think has some obvious flaws)
If you go over to http://agilemanifesto.org/ and read these simple 4 sentences, it makes sense:
* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Would any of these work for, say, building a house?
I hate agile from the bottom of my heart.
Do you launch a new bed in your house to charge people to see every month?
They are not even comparable, like at all. If all you have is hate for something sure you can not understand it.
If the customer wants a horse to run 60mph backwards, and the project manager has no idea that a horse cannot possibly do that, i have to hear why my "horse" should have been designed with Agile philosophy in mind. Agile is nothing but a bunch of techno-babble that "sounds good" but offers no practical advice on how to achieve those ends. It is the scourge of the earth and would love to see it purged from collective consciousness.
For over a year I pushed back on story pointing and things that felt micro manage-y to me.
It was very hard on me, but it was worth seeing the productivity.
Eventually I was forced to give in to Agile with the big A and left soon after.
I can't get another management job because everyone wants to do Agile in a way I hate to manage - so now I'm a developer again... :)
But I object to the authors complaint “and it’s pushing women engineers into non-technical roles.” and elevating the primacy of engineering above all else.
People come in all levels of competencies and have all manner of skills. I don’t care if you are a man or a woman. I care about how good you are at doing the tasks that need to be done to get the job done. And in large companies there are big jobs that require a lot of people and a lot of coordination.
I work with a woman who is not a very good software engineer, but she is good at administering and coordinating the work among other software engineers and she quite enjoys doing those tasks.
While she can improve on some of her skills as a software engineer and I try to help her with those, the author’s recommendation seems to be that because she’s a woman, I should push her away from work that she likes doing, that she’s good at doing, and which is important work to do.
This is objectively terrible advice, but some might accuse me now of male chauvinism. If so, fine. But I will forward this article to my colleague to ask her what she thinks and I’ll let her opinion be the ruling decision.
To deliver any real business value following these philosophies requires an extremely mature, experienced team. Not just great engineers, but also great communicators that actually care at least a little bit about the mission/product/goal.
This simply does not scale and is a complete antithesis of 99% of organizations culture and hierarchical structure.
That's it. The more people are involved, the more complicated the process gets and all of these approaches evolve out of trying to find an agreeable and effective way of doing it so that everyone doesn't have to figure out a new solution every time.
As much of a buzzword hell as it is, I really believe that Scaled Agile Framework (SAFe) is the closest thing to the right balance of trade offs.
This may be a bit different depending on the make-up and maturity of the team. Sometimes, we need daily engagement with team members and "structured" collaboration, other times we just need to make sure everyone understands the sprint goals and then get out of their way. The challenge has always been when upper management wants to see a single dashboard which boils all teams down into a set of pre-defined metrics - and then positively reinforces teams (or their managers) for hitting metrics instead of delivering solutions. Training your VP's can be exhausting.
In this situation, you'd get shot down for following rigid Agile, because the process gets in the way of delivering value. What you end up doing is using the concept of "agility" to sell some agile-lean-hybrid-involve-the-stakeholders-think-small-and-demonstrate-the-value-of-delivering-value. It's not about the Method, it's about the outcome.
No one needs to go black-and-white rigid Agile, that's where it went wrong. But agility is a good way to describe the concept of efficiently changing (and handling change).
I just feel that every article about capital "a" Agile immediately sinks to level of pedantry that is a complete waste of time, so... I didn't read the OP.
Just like the very process of software design this was meant to aid, they failed to understand the importance of clarity, brevity, and providing exacting specifications or instructions.
Fuck you, agile. This is not how engineering should be done in any profession. Thousands of hours of my career has been wasted clarifying this unclear process to swarms of people who have no single resource to learn from. And each new company brings a new “we do agile, but....” exception to adapt to, and damned be if anyone ever writes a single fucking rule of this process down, so we get to endlessly debate what is this “agile” thing at each and every opportunity.
Way too easy to "seem" productive while actually being net negative for the project.
That said, I've had excellent agile projects that have delivered huge value to the customer at cost and time well below initial estimates.
These days I ask people who shout for agile to actually explain the fundamentals to me, as though I have no clue. Very rarely do I find anyone who can hit even one of the four original core ideas and values of "agile":
And when I bring up the core ideas, and why they can work really well, I often see that the people who shout agile actually don't agree with the fundamentals.
My best team is me alone, but other than that, the best team I ever had was one in which there was no meetings, no dailies etc. It was just me and a few others, receiving the outlines of what the final product had to do, what inputs and outputs it should process, and then filling this outline with code and hard work until it was whole. It was far from perfect of course, but we weren't bothered by unnecessary processes. There was no agile back then yet....
That said, the methodologies are not the problem. The problem is peoples attitude and mentality and how they use them.
Sometimes we move things in and out of a sprint mid-sprint because new information came up and it's high priority? It's not ideal (and we'll discuss it in retro) but that's agile.
We've sat a fat 5-point ticket in our backlog for 3 sprints straight because it needs a decent sum of meeting time and dedicated attention from multiple engineers who keep facing higher priority work and not quite having time for it? That's fine, we're being agile.
Our backlog grooming meeting ended after 8 minutes because we had nothing to discuss and we're all focused on delivering? Very agile.
Then, the problem with frameworks like Agile is that smart people will use them wisely, and less smart people will try to apply the concepts without really grasping the ideas and not really gain anything out of it.
But you can't really prevent people from reading the book, and do stand-up scrum meetings and sprints and shit...
Unless someone comes up with something else (which most likely will be equally twisted) Agile is here to stay. I just wouldn't mind watching conversations about Agile die.
I think we need Outcome Driven Development- we define a metric measured in say graphite, we link a ticket to that asserting the ticket will make the metric change this way or that, and we commit code to make the metric change
so we start a process of defining what we want, implementing how to measure it (there could be a null metric and the ticket is to make it not null) and then measuring our success of changing the metric
this will have organisational impacts as well - no one should take a ticket without authority span to impact that metric
this will start in the direction of software as literacy or the developer anarchy
I couldn't agree more
THAT said agile was a breath of fresh air at the time and it got us to question a lot of assumptions related to how we specify and develop software.
Everything else can flow from there.
Story points remind me of those weird units of work the cloud providers bill you for, or the company scrip that a coal mine would have issued 100 years ago. I call story points AgileBucks.
Why not just use standard units?
In our 2 week sprints we have four possible story point values - 3, 5, 8, 13. If the story should take a couple of days, it’s 3 points. If the story will probably take the full sprint, it’s 13 points. If the story is somewhere in between, pick 5 or 8.
It's easy to say that, but the obvious follow-on question is "and replace it with what, exactly?" Maybe the answer is in TFA, but I didn't read it yet. I hope they have something to propose, otherwise this discussion is pretty vacuous.
I think it's probably a good reinterpretation of the original manifesto that is a bit more fundamental and a bit more direct. I like the concepts a lot.
What it doesnt give any guidance to is how to organize information about how to build the right thing. If a system is very large, without some methods to understand and communicate what you are building, it just becomes ad hoc. Agile is not a product management/requirements identification methodology.
https://github.com/rayfrankenstein/AITOW/blob/master/README....
Here's an archive link https://archive.is/wip/OFF0F
The set of methodologies and processes that ensued, as well as the entire industry of coaches, consultants, evangelists and "practitioners" was probably coming from a good place - trying to propose an implementation for how to put in place those abstract values and principles, or to help with that. The commercialization, envy and corruption that followed is what the problem is. "Agile" has become a synonym for "cargo-cult brainless implementation of sprints and stand-ups to copy something called scrum but effectively doing things in a very much waterfall and old fashion that isn't even remotely close to the original intent".
The problem is of semantics order. What does need to "die" is the "agile" industry, with cargo-cultish coaches whose only value is to repeat Scrum says X, XP says Y, Agile says Z, my other customers do Ω, without trying to convey the reason behind those implements ; "agile" methodos like "safe" which have very little agility backed in and whose "Enterprise Architects" proponents usually don't get any of the intent.
But take a look at the manifesto[1] and tell me that you want it to die, I feel like the arguments will be very complex. Re: the that we should become "engineers" (semantics and cargo-cult again), there's a very good reason why agile applies well to software, but not to mechanical engineers. The economic equations between those two practices are completely different[2][3], the "engineering" phase of mechanical engineering is cheap compared to the production costs and so iterations have effectively an extremely high overhead cost, whereas the "engineering" phase of software engineering represents most of the cost, and so iteration and adaptability have a very low overhead.
But saying "agile needs to die" because of how the "agile industry" corrupted it is similar to saying "email needs to die" because what you see most is spam.
[1]: https://agilemanifesto.org/
[2]: https://www.developerdotstar.com/printable/mag/articles/reev...
Agile alone is insufficient to successful products, which the original proponents would tell you. It’s a body of practices. There are more practices than just those. People seem to want “12 steps to an easy rich life” and want to scream when someone offers only 6 of them.
Most of the Agile practices the industry has adopted and evolved without calling them agile. So in that sense, it’s a “success”.
But agile coaches often are so focused on the original 20 year old practices and they miss the bigger picture of business and products and supporting technology, and the evolution that’s taken place in each during that time.
Any software method that is delivering software for users to consume has to be complemented by outcome-focused approaches like user-centered design, product development, customer development, and budgetary funding / management practices that don’t weaponize the use of openness, sharing, and metrics for political purposes that hurts people’s self worth. If you’re missing those, agile isn’t going to help you much.
Ultimately just letting engineers be engineers is partly how we got into this mess in the first place. People don’t know how to organize themselves without some kind of constraints: design constraints, time, physics, customer constraints, quality, etc. Talented teams turned loose that ultimately deliver little of value is a cliche at this point. Agile tries to use time as a constraint to limit active work in progress to force the delivery of customer visible / valuable results that can be tweaked. It’s not the only way to constrain the problem space, but “cost of delay” does have a fairly universal explanatory value in showing what really matters to a business, as lean product development and manufacturing has shown. But that might not be the outcome you’re looking for.
whatever process or practices you do, Agile or not, it has to be organized end-to-end to be tied to some kind of tangible mission or outcome or else it’s just a form of self-deception. For example, if we think products need to be usable and solve actual problems, and that design can evolve, then Product owners need to speak for the Customers and have the power to make decisions. Engineers need to be empowered to make the technical decisions. These seem obvious but they’re rare: committees and political strings attached are the norm. If you get both an empowered balanced team of product, design, and engineering you’ve got potential for an engine of collaboration and learning, which is the whole point. Don’t build projects, build human/techno systems that grow and improve and evolve.
Agile is also not universally applicable and much of the resentment stems from a religious conversion therapy or Developer Rehab approach to marketing (even though some really could use a stint in rehab). Agile is applicable to some kinds of software (user-Centered software in particular), which happens to be a big chunk of industry. It isn’t applicable to everything, such as deeply technical components, pure or applied scientific R&D, or certain kinds of exploratory work. Nor is it applicable to jobs with set and unchangeable requirements.
People are best to understand there are a spectrum of practices and processes suited to different environments and stages of organizational evolution. Or they could reject such complexity and nuance and just adopt SAFe, I guess.
Generally speaking, lean is a tool for reducing various kinds of 'waste' and 'doing more with less'. That's the part people seem to focus on anyway. The problem is that people become myopic. Lean becomes the justification for premature optimization and focusing on details that don't matter.
Sometimes, waste is good. Or, stated differently, not all waste is equal. If you have 5 machines that each produce $1000 of value per hour run, and you're attempting to go lean by rearranging them so you can lay off a $20/hour employee, then you are focusing entirely on the wrong thing.
Lean is often pushed with the idea that employees shouldn't be standing around doing nothing, or that you shouldn't produce excess material which will sit in a pile. The problem with this is it often fails to account for needed excess capacity, and when something goes wrong, everything falls apart.
The correct move (depending on margins) is usually to hire more inexpensive humans to stand around and make sure the expensive machines never stop generating value because you overburdened one of the humans. When you want to make things faster, you don't stop producing when the next machine in the process can't keep up (producing a pile of unused parts). You buy another machine that performs the next process or figure out what it needs to run faster.
Lean is the methodology most people use when they can't make big changes that will have a major impact on production. It's a tool for making the existing (possibly broken) system function better. It's culturally good to focus on reducing waste, but often it's the waste you're not measuring or thinking about that's killing you.
Lean isn't bad any more than optimization is bad, it's just not the tool you typically want to be starting with. I work directly with customers, have no deadlines that aren't self imposed, and couldn't tell a story point from a scrum master, so I can't say if the failures of lean manufacturing implementation extend to agile, but I'd be curious to hear if they do.
A tool I find more useful than lean: https://en.m.wikipedia.org/wiki/Theory_of_constraints
Our stand-ups are pointless because they're just status updates. Not much of consequence can happen in 10 minutes anyway. I ignore our metrics at the end of each sprint. They're meaningless. Our retrospectives are largely useless other than giving shoutouts to team members. I feel the sprint structure leads to Parkinson's law.
This situation, however, is perfectly normal because Agile advocates "people over processes." My team doesn't give a shit about the Agile process, so it's mostly like forced physical training but without the fitness benefits.
I'm working with a team that the PM follows Agile like its a silver bullet solution but is obviously terribly flawed.