There is pow'r in an Agile methodology
August 31, 2015 9:58 AM Subscribe
Mike Bulajewski on the war between labor and management in the software industry, as manifested in the rise (and possible fall) of the Agile development: From this subset of principles, it’s clear that although Agile positions itself as a software development methodology, a closer inspection reveals clues to a greater ambition: to protect the interests of software engineers at work. [...] With this agenda, it is possible to characterize the Agile movement as a labour union.
When Agile development actually increases benefits, adds legal protections, and reduces work hours in the Valley, maybe then you can call it a labor union.
posted by SansPoint at 10:15 AM on August 31, 2015 [41 favorites]
posted by SansPoint at 10:15 AM on August 31, 2015 [41 favorites]
Looking at all those tags, I am going to guess no, because Larry's stuff doesn't play well with anything he doesn't already own.
posted by wenestvedt at 10:16 AM on August 31, 2015 [1 favorite]
posted by wenestvedt at 10:16 AM on August 31, 2015 [1 favorite]
With this agenda, it is possible to characterize the Agile movement as a labour union.
I actually read this far in the article.
I feel a little bit queasy now.
posted by brennen at 10:17 AM on August 31, 2015 [1 favorite]
I actually read this far in the article.
I feel a little bit queasy now.
posted by brennen at 10:17 AM on August 31, 2015 [1 favorite]
Happy engineers do better work.
Do you use GitHub, Stash, or something else that provides a commit graph for your employees?
Go find the weeks where there are commits on Sunday.
Now, look at the following week. Notice that it's a lot lighter than all of the other weeks around it?
Yeah. Tired engineers do shit work.
I don't necessarily follow all of the dogma of agile, but it's absolutely true that a well-managed team does not overwork its employees and is able to successfully organize (and execute) sprints. I'm not sure if being able to pull off Agile is necessarily a symptom or cause for a well-managed team, but it certainly seems like a good benchmark.
Also, be wary of cargo-cult management. Agile isn't necessarily the answer for many people, and perhaps unsurprisingly given my previous point, organizations that have business requirements that preclude the implementation of Agile also tend to be particularly difficult and problematic environments for building and delivering software.
This is especially true for consulting and government work. I work in the former category, and it's tough to reconcile the demonstrated benefits of agile with the (totally reasonable) expectations that our clients have about wanting to know what they're paying for and how long it's going to take.
posted by schmod at 10:17 AM on August 31, 2015 [21 favorites]
Do you use GitHub, Stash, or something else that provides a commit graph for your employees?
Go find the weeks where there are commits on Sunday.
Now, look at the following week. Notice that it's a lot lighter than all of the other weeks around it?
Yeah. Tired engineers do shit work.
I don't necessarily follow all of the dogma of agile, but it's absolutely true that a well-managed team does not overwork its employees and is able to successfully organize (and execute) sprints. I'm not sure if being able to pull off Agile is necessarily a symptom or cause for a well-managed team, but it certainly seems like a good benchmark.
Also, be wary of cargo-cult management. Agile isn't necessarily the answer for many people, and perhaps unsurprisingly given my previous point, organizations that have business requirements that preclude the implementation of Agile also tend to be particularly difficult and problematic environments for building and delivering software.
This is especially true for consulting and government work. I work in the former category, and it's tough to reconcile the demonstrated benefits of agile with the (totally reasonable) expectations that our clients have about wanting to know what they're paying for and how long it's going to take.
posted by schmod at 10:17 AM on August 31, 2015 [21 favorites]
I read this some time ago and it's an interesting perspective. It's interesting to me though, that in more toxic workplace cultures, Agile methodologies can be used to spur developers into a state of constant emergency by setting up a regularly scheduled series of artificial deadlines and punishing (through poor performance reviews and deeming people "not team players") anyone who doesn't consistently meet all their sprint goals, no matter what obstacles or interruptions come up along the way.
While this is very much not how these methodologies are "supposed to" work, Agile can easily be co-opted by toxic management into "Quick! Be agile! Everything is a sprint so you should be working harder! Agile means we can change anything anytime, so why are you shaking your head at me when I tell you to drop everything and change this toolbar? There are still four stories left in this sprint, but don't worry I'll order pizza so you can work late." If I belonged to that union, I'd quit.
posted by zachlipton at 10:18 AM on August 31, 2015 [47 favorites]
While this is very much not how these methodologies are "supposed to" work, Agile can easily be co-opted by toxic management into "Quick! Be agile! Everything is a sprint so you should be working harder! Agile means we can change anything anytime, so why are you shaking your head at me when I tell you to drop everything and change this toolbar? There are still four stories left in this sprint, but don't worry I'll order pizza so you can work late." If I belonged to that union, I'd quit.
posted by zachlipton at 10:18 AM on August 31, 2015 [47 favorites]
Agile the methodology is like an Oracle product in one important respect: it empowers the uniformed to defer decisions under the cover a creeping barrage of status reports full of pretty graphs.
posted by feloniousmonk at 10:18 AM on August 31, 2015 [3 favorites]
posted by feloniousmonk at 10:18 AM on August 31, 2015 [3 favorites]
In the two workplaces that I have seen attempt Agile adoption it has merely been a different coloured stick to beat more productivity out of devs with.
(sample size of 2 is small though)
posted by Cosine at 10:19 AM on August 31, 2015 [6 favorites]
(sample size of 2 is small though)
posted by Cosine at 10:19 AM on August 31, 2015 [6 favorites]
PLEASE COME BACK WATERFALL MODEL ALL IS FORGIVEN!
posted by Foci for Analysis at 10:25 AM on August 31, 2015 [25 favorites]
posted by Foci for Analysis at 10:25 AM on August 31, 2015 [25 favorites]
On a more serious note, I think the industry both needs organized labor and is simultaneously the least likely to be able to deal with even the concept of discussing it. It's hard to imagine a group as readily hostile to the idea as developers. Maybe Wall Street financial types? There are enough people at the high end making ridiculous money to inspire a large number of the remainder to believe that they, too, are just a good idea and an acquihire away from the $300k+ jobs and all of their bonuses and perks. In order for a labor movement to succeed in software, it'd have to get to the point where it wasn't relatively easy to find a higher paying position at a new company for someone with 5 years or so experience, at least, and likely much worse than that.
posted by feloniousmonk at 10:28 AM on August 31, 2015 [2 favorites]
posted by feloniousmonk at 10:28 AM on August 31, 2015 [2 favorites]
Agile means we can change anything anytime, so why are you shaking your head at me when I tell you to drop everything and change this toolbar?
Yeah, unfortunately, this.
I think if anything, agile isn't so much stealth union as it is stealth anti-big-corporation -- because my experience has been that it does actually work pretty well in a small shop, but it falls apart badly in a big one. Once a company gets over a certain size, you inevitably have people in the management structure who view agile as justification why they can change requirements all the time, any time, while conveniently forgetting that while that's true to a degree, it's supposed to come with the understanding that if the product owner decides Feature X is now the top priority, Feature Y might not get done this sprint (or ever).
Agile in a big org is basically signing up for the worst of both worlds -- "we're agile, we'll handle new requirements as they come ... but oh by the way, we already promised a VP a huge set of requirements, none of which can be changed, and we've already committed to a date, and ..."
posted by tocts at 10:31 AM on August 31, 2015 [21 favorites]
Yeah, unfortunately, this.
I think if anything, agile isn't so much stealth union as it is stealth anti-big-corporation -- because my experience has been that it does actually work pretty well in a small shop, but it falls apart badly in a big one. Once a company gets over a certain size, you inevitably have people in the management structure who view agile as justification why they can change requirements all the time, any time, while conveniently forgetting that while that's true to a degree, it's supposed to come with the understanding that if the product owner decides Feature X is now the top priority, Feature Y might not get done this sprint (or ever).
Agile in a big org is basically signing up for the worst of both worlds -- "we're agile, we'll handle new requirements as they come ... but oh by the way, we already promised a VP a huge set of requirements, none of which can be changed, and we've already committed to a date, and ..."
posted by tocts at 10:31 AM on August 31, 2015 [21 favorites]
I have worked a lot under agile. At one place, I discovered that strict agile methodology could be used to waste tremendous amounts of time. For example, someone who with several other people had unnecessarily wasted my time a couple weeks earlier asked me to do a particular task which, quite honestly, would take 5 minutes. Instead, I replied to the request for me to do it with a simple, "is there a backlog item for this?" and cc'ed the other time wasters. It was astounding how much time these people wasted trying to figure out what color to paint the bike shed. It was such a simple lever to pull and very gratifying to see 4 people arguing over which backlog/sprint it should go in and who would QA the task.
Later, whenever I decided that I need some catharsis, I'll pull that lever again and inside my head I would hear, "PULL THE LEVER KRONK!" (even though I'm not the one who suffers from the lever being pulled).
posted by plinth at 10:36 AM on August 31, 2015 [17 favorites]
Later, whenever I decided that I need some catharsis, I'll pull that lever again and inside my head I would hear, "PULL THE LEVER KRONK!" (even though I'm not the one who suffers from the lever being pulled).
posted by plinth at 10:36 AM on August 31, 2015 [17 favorites]
I agree that Agile does not work for larger projects. I've worked in both large and small software development projects for 16 years, and have yet to see a faithful implementation of any agile process, unfortunately. It has tended to be pick-and-choose, and most often "self-organized" has fallen by the wayside.
posted by Harald74 at 10:39 AM on August 31, 2015
posted by Harald74 at 10:39 AM on August 31, 2015
I feel like this entire thread is going to be me checking people's profiles after I favorite their comments to see if I can get any clue if we've worked at the same place.
posted by MCMikeNamara at 10:40 AM on August 31, 2015 [4 favorites]
posted by MCMikeNamara at 10:40 AM on August 31, 2015 [4 favorites]
tocts - my experience has been that [agile] does actually work pretty well in a small shop, but it falls apart badly in a big one
The problem is that the reference implementations, so to speak, of the agile principles (e.g, scrum, kanban) all focus on processes at the most basic level. Creating an agile organization is tough.
posted by tippiedog at 10:42 AM on August 31, 2015 [4 favorites]
The problem is that the reference implementations, so to speak, of the agile principles (e.g, scrum, kanban) all focus on processes at the most basic level. Creating an agile organization is tough.
posted by tippiedog at 10:42 AM on August 31, 2015 [4 favorites]
The first part of the article was very interesting, by the way. I feel it falls a bit apart in the second half, at least as far as my perception of Lean production methodologies go. The workers are supposed to have their say through the Daily Management practice, not be overlooked all the time as the author seems to be implying. Many of his other criticisms seem to be on the nose, though.
posted by Harald74 at 10:42 AM on August 31, 2015
posted by Harald74 at 10:42 AM on August 31, 2015
I don't think he's quite got the point of Agile - in that in my experience (as well as others above), it's used to turn the screw just a bit tighter every spiral on the engineers. Or, complete chaos is simply regarded as 'agile' by management.
The nice thing that Agile added was more frequent customer feedback - although it does need more customer management to ensure you don't end up in a death-spiral of ever-changing requirements.
I have an especially powerful dislike of Agile and UCD's refusal to accept proper user stories - go ahead and go to the trouble of defining the roles that will be able to perform some action, identify (clearly) the inputs and outputs, define the common workflow through the story and enumerate the alternate work flows - failure to do that (as user stories in both approaches are wont to do because 'documentation isn't important' usually results in horrible things being done to the code base to cram in functionality that wasn't well thought out initially.
posted by combinatorial explosion at 10:43 AM on August 31, 2015 [3 favorites]
The nice thing that Agile added was more frequent customer feedback - although it does need more customer management to ensure you don't end up in a death-spiral of ever-changing requirements.
I have an especially powerful dislike of Agile and UCD's refusal to accept proper user stories - go ahead and go to the trouble of defining the roles that will be able to perform some action, identify (clearly) the inputs and outputs, define the common workflow through the story and enumerate the alternate work flows - failure to do that (as user stories in both approaches are wont to do because 'documentation isn't important' usually results in horrible things being done to the code base to cram in functionality that wasn't well thought out initially.
posted by combinatorial explosion at 10:43 AM on August 31, 2015 [3 favorites]
So, from a certain perspective, the Waterfall process can be seen as a factory production line, and Agile methodologies as undermining the role of specialisation, which enables deskilling. Specialisation reduces software engineers to mere “code monkeys” who simply crank out code in highly repetitive and routinised ways, and lack any decision making power over the higher order architectural and requirements work that is reserved for managers and the most senior developers.
I think Agile has real value in preventing projects from going completely off the rails by providing a tight feedback loop. But for me personally, it feels like an endless grind. It's a group of purposely interchangeable engineers focusing on one purposely small task after another. I can see why the process might be appealing to people at the beginning of their careers who don't want to get stuck with the shit work. But over the course of a project, I'd much rather have the responsibility for something end-to-end than a random collection of one-day tasks.
posted by Combustible Edison Lighthouse at 10:45 AM on August 31, 2015 [6 favorites]
I think Agile has real value in preventing projects from going completely off the rails by providing a tight feedback loop. But for me personally, it feels like an endless grind. It's a group of purposely interchangeable engineers focusing on one purposely small task after another. I can see why the process might be appealing to people at the beginning of their careers who don't want to get stuck with the shit work. But over the course of a project, I'd much rather have the responsibility for something end-to-end than a random collection of one-day tasks.
posted by Combustible Edison Lighthouse at 10:45 AM on August 31, 2015 [6 favorites]
The waterfall model is pretty much a strawman model, and I'd like authors to make that clear when they write about it. Nobody has ever had any ambitions to run any non-trivial project in strict waterfall. The alternative to agile is mostly iterative processes with defined phases, not strict waterfall.
posted by Harald74 at 10:45 AM on August 31, 2015 [14 favorites]
posted by Harald74 at 10:45 AM on August 31, 2015 [14 favorites]
Agile is, as implemented most places, a way to get rid of project managers, dump project management work on developers, skip documentation and blame the resulting chaos on developers, and generally shove a lot of extra tasks into the developer role or pretend they don't exist. It is not a union.
posted by Artw at 10:46 AM on August 31, 2015 [48 favorites]
posted by Artw at 10:46 AM on August 31, 2015 [48 favorites]
Creating an agile organization is tough.
Ain't that the truth. I work on the infrastructure side and have interacted with lots of teams doing Agile who felt that they could use the word Agile to beat on us to get what they needed whenever they needed it.
What they didn't understand was that we were hired, measured and incentivized in a way that doesn't line up with Agile. We could certainly work that way but it would require changing contracts and setting up different measurements for SLAs and the like. In the end there are always too many stakeholders and too much inertia to get all of the alignment needed to make the process be true end to end Agile.
posted by mmascolino at 10:49 AM on August 31, 2015 [1 favorite]
Ain't that the truth. I work on the infrastructure side and have interacted with lots of teams doing Agile who felt that they could use the word Agile to beat on us to get what they needed whenever they needed it.
What they didn't understand was that we were hired, measured and incentivized in a way that doesn't line up with Agile. We could certainly work that way but it would require changing contracts and setting up different measurements for SLAs and the like. In the end there are always too many stakeholders and too much inertia to get all of the alignment needed to make the process be true end to end Agile.
posted by mmascolino at 10:49 AM on August 31, 2015 [1 favorite]
I'm actually a fan of agile and currently working as a scrum-master but I'm not really getting this article at all. Yeah, we're self-powered to figure out how to build the required features that the product owner requests that doesn't have damn thing to do with any kind of real worker organization.
posted by octothorpe at 10:52 AM on August 31, 2015 [4 favorites]
posted by octothorpe at 10:52 AM on August 31, 2015 [4 favorites]
Nobody has ever had any ambitions to run any non-trivial project in strict waterfall.
I guess that you haven't worked where I've worked. I've been involved in quite a few multi-year pretty strict waterfall projects where no real testing is done until the feature's been in development for 18 months.
posted by octothorpe at 10:55 AM on August 31, 2015 [8 favorites]
I guess that you haven't worked where I've worked. I've been involved in quite a few multi-year pretty strict waterfall projects where no real testing is done until the feature's been in development for 18 months.
posted by octothorpe at 10:55 AM on August 31, 2015 [8 favorites]
To those that think Agile or Scrum is about getting someone to work harder or change on a whim ... Sorry, it's just not being doing right. So you should either change how you're engaging with it, revolt against a bad manager, or find another job.
This is not a "no true Scotsman" argument. There's literally no other way to spin it. If you're overworked in your sprint, you committed to too much. If you don't get to choose your commitment, yeah, you're being fucked with, and that's not Agile.
But saying Agile is just about working harder? That's like saying a toaster is a deadly weapon -- sure, if you throw it into a bathtub, it's dangerous, but that's not exactly a best practice.
posted by Cool Papa Bell at 11:00 AM on August 31, 2015 [23 favorites]
This is not a "no true Scotsman" argument. There's literally no other way to spin it. If you're overworked in your sprint, you committed to too much. If you don't get to choose your commitment, yeah, you're being fucked with, and that's not Agile.
But saying Agile is just about working harder? That's like saying a toaster is a deadly weapon -- sure, if you throw it into a bathtub, it's dangerous, but that's not exactly a best practice.
posted by Cool Papa Bell at 11:00 AM on August 31, 2015 [23 favorites]
Is this that thing where they do 'stand up'?
posted by colie at 11:02 AM on August 31, 2015 [3 favorites]
posted by colie at 11:02 AM on August 31, 2015 [3 favorites]
Agile is, as implemented most places, a way to get rid of project managers, dump project management work on developers, skip documentation and blame the resulting chaos on developers, and generally shove a lot of extra tasks into the developer role or pretend they don't exist. It is not a union.
It is not a union. But re: the rest, I've actually heard and seen the opposite.
Agile, like the article says, started as a way to protect developers and make things more sane from their perspective. But after it caught on, it because a sellable thing among project managers, who then ran with it and made it into its own self-hunting-and-feeding entity. Now there's a whole industry built around it. There's Agile consultants to hire and trainers to pay. Huge corporations spend years "moving over to Agile," while at the same time, as mentioned above, their top-level executives still insist on waterfall-style fixed deliverables.
posted by ignignokt at 11:11 AM on August 31, 2015 [6 favorites]
It is not a union. But re: the rest, I've actually heard and seen the opposite.
Agile, like the article says, started as a way to protect developers and make things more sane from their perspective. But after it caught on, it because a sellable thing among project managers, who then ran with it and made it into its own self-hunting-and-feeding entity. Now there's a whole industry built around it. There's Agile consultants to hire and trainers to pay. Huge corporations spend years "moving over to Agile," while at the same time, as mentioned above, their top-level executives still insist on waterfall-style fixed deliverables.
posted by ignignokt at 11:11 AM on August 31, 2015 [6 favorites]
All the problems that have, thus far in these responses, been identified with Agile are, in fact, not the fault of Agile. They are human problems, caused by humans. Agile is the poor bystander, just like waterfall.
You have to separate the cultural issues of a company from the methods used in that company to get work done. If management is using Agile as a cudgel to make the codemonkeys work harder, then it's because management is populated with crazy people who have taken on contracts with impossible demands. Any method is going to fail in that environment.
posted by gsh at 11:12 AM on August 31, 2015 [7 favorites]
You have to separate the cultural issues of a company from the methods used in that company to get work done. If management is using Agile as a cudgel to make the codemonkeys work harder, then it's because management is populated with crazy people who have taken on contracts with impossible demands. Any method is going to fail in that environment.
posted by gsh at 11:12 AM on August 31, 2015 [7 favorites]
Agile is, as implemented most places, a way to ... skip documentation
Yup, being a technical writer in an Agile environment gives me lots of opportunities to hone my telepathy skills. I miss specs.
posted by diogenes at 11:19 AM on August 31, 2015 [22 favorites]
Yup, being a technical writer in an Agile environment gives me lots of opportunities to hone my telepathy skills. I miss specs.
posted by diogenes at 11:19 AM on August 31, 2015 [22 favorites]
Agile is the poor bystander, just like waterfall.
So if it succeeds, it's because agile is great, but if it fails, it's because people did it wrong?
I mean, look, I really do think agile can be a good option ... sometimes. But, by way of analogy: let's say I built a kitchen gadget that makes the most amazing pies if used properly, but makes pies that taste like dog shit otherwise. If 95% of the time the pies come out tasting like dog shit, it seems like it would be rather disingenuous to claim that the problem is clearly the users, and not the fact that my theoretically great contraption is, in practice, often significantly worse for the user than if they'd just had to make a pie the old-fashioned way.
posted by tocts at 11:21 AM on August 31, 2015 [4 favorites]
So if it succeeds, it's because agile is great, but if it fails, it's because people did it wrong?
I mean, look, I really do think agile can be a good option ... sometimes. But, by way of analogy: let's say I built a kitchen gadget that makes the most amazing pies if used properly, but makes pies that taste like dog shit otherwise. If 95% of the time the pies come out tasting like dog shit, it seems like it would be rather disingenuous to claim that the problem is clearly the users, and not the fact that my theoretically great contraption is, in practice, often significantly worse for the user than if they'd just had to make a pie the old-fashioned way.
posted by tocts at 11:21 AM on August 31, 2015 [4 favorites]
Agile is, as implemented most places, a way to get rid of project managers, dump project management work on developers, skip documentation and blame the resulting chaos on developers, and generally shove a lot of extra tasks into the developer role or pretend they don't exist. It is not a union.
Well put. You need to understand the technology to plan things out in a Waterfall or other planned approach. Instead, Agile just means programmers handle all planning, and project managers just check in on status during scrum.
posted by destro at 11:22 AM on August 31, 2015 [4 favorites]
Well put. You need to understand the technology to plan things out in a Waterfall or other planned approach. Instead, Agile just means programmers handle all planning, and project managers just check in on status during scrum.
posted by destro at 11:22 AM on August 31, 2015 [4 favorites]
their top-level executives still insist on waterfall-style fixed deliverables.
We do keep having to remind them that they can dictate either the content of a release or its due date but not both. We're mostly successful at that but they usually manage to forget that the next time.
posted by octothorpe at 11:26 AM on August 31, 2015 [5 favorites]
We do keep having to remind them that they can dictate either the content of a release or its due date but not both. We're mostly successful at that but they usually manage to forget that the next time.
posted by octothorpe at 11:26 AM on August 31, 2015 [5 favorites]
While this is very much not how these methodologies are "supposed to" work, Agile can easily be co-opted by toxic management into...
Yeah, if you want to understand agile-as-practiced, don't reference the manifesto. Where I work, management made compromises that broke key trade-offs and made the whole thing pretty nonsensical (e.g. a waterfall-y commitment to deliver defined functionality at a defined date, with an agile-inspired lack of up-front requirements gathering and analysis). Fortunately existing company culture softened the blow of that on my development team, so we just let story after story roll until we got to them.
Also, weirdly, it was management that championed agile. They even hired long-haired consultant.
Agile is, as implemented most places, a way to get rid of project managers*, dump project management work on developers, skip documentation and blame the resulting chaos on developers, and generally shove a lot of extra tasks into the developer role or pretend they don't exist.
Actually, at my workplace, they hired several more project managers for agile, further supplemented by turning a significant number of development leads into project managers in all but name. How else would they be able to manage the never-ending planning ritual that agile requires?
Also, management, no the development team, got the blame in the end for the project's problems.
* I don't in fact know what people with the job title of "project manager" are really supposed to do. I just think of them as general-purposes bureaucrats.
posted by cosmic.osmo at 11:26 AM on August 31, 2015 [1 favorite]
Yeah, if you want to understand agile-as-practiced, don't reference the manifesto. Where I work, management made compromises that broke key trade-offs and made the whole thing pretty nonsensical (e.g. a waterfall-y commitment to deliver defined functionality at a defined date, with an agile-inspired lack of up-front requirements gathering and analysis). Fortunately existing company culture softened the blow of that on my development team, so we just let story after story roll until we got to them.
Also, weirdly, it was management that championed agile. They even hired long-haired consultant.
Agile is, as implemented most places, a way to get rid of project managers*, dump project management work on developers, skip documentation and blame the resulting chaos on developers, and generally shove a lot of extra tasks into the developer role or pretend they don't exist.
Actually, at my workplace, they hired several more project managers for agile, further supplemented by turning a significant number of development leads into project managers in all but name. How else would they be able to manage the never-ending planning ritual that agile requires?
Also, management, no the development team, got the blame in the end for the project's problems.
* I don't in fact know what people with the job title of "project manager" are really supposed to do. I just think of them as general-purposes bureaucrats.
posted by cosmic.osmo at 11:26 AM on August 31, 2015 [1 favorite]
I've never been a developer in an agile environment, but I've worked closely with projects that are and have also documentented its mutant offspring, devops. (I nearly got a project where a large software company which was agile had bought a smaller company that wasn't, and I'dve been covering in various angles the introduction of agile from the former to the latter. Both were famous, both had extremely widely used and often controversial household-name products, but one was American and the other European. I SO wanted to see that process from the inside: there is literally no way, except through legal pressure of the NDA sort, that it couldn't have turned into a compelling story...)
I'm impressed with agile - and devops - because they solve long-standing problems that I observed everywhere when I was a developer. But they're also heavily dependent - devops more than agile, I think - on cultural acceptance, and here the problems of changing the way a large company thinks and behaves are much greater than for a small one.
Devops in particular is capable of producing spectacular productivity improvements, and that through the 'smarter not harder' principle. It's also capable of foundering catastrophically on the rocks of "we need to know in advance the path this project will take, with delivery and costing milestones' - which, although these can be largely fictional in traditional dev, can at least be presented with a straight face. You also can't buy a devops, which seems to confuse and repel.
I remain convinced that the cultural side of business in general, and in dev in particular, remains infinitely more interesting, harder to engineer and more important to get right, than any particular methodology.
posted by Devonian at 11:28 AM on August 31, 2015 [7 favorites]
I'm impressed with agile - and devops - because they solve long-standing problems that I observed everywhere when I was a developer. But they're also heavily dependent - devops more than agile, I think - on cultural acceptance, and here the problems of changing the way a large company thinks and behaves are much greater than for a small one.
Devops in particular is capable of producing spectacular productivity improvements, and that through the 'smarter not harder' principle. It's also capable of foundering catastrophically on the rocks of "we need to know in advance the path this project will take, with delivery and costing milestones' - which, although these can be largely fictional in traditional dev, can at least be presented with a straight face. You also can't buy a devops, which seems to confuse and repel.
I remain convinced that the cultural side of business in general, and in dev in particular, remains infinitely more interesting, harder to engineer and more important to get right, than any particular methodology.
posted by Devonian at 11:28 AM on August 31, 2015 [7 favorites]
As far as doing agile the right way goes, it's easier said than done. In 2007 I was at an organization that decided to go agile and went big in doing so, including a week long offsite training seminar with one of the biggest names in scrum training. They reorganized the business, hired consultants and trainers, invested significantly in training, and within a year entirely devolved into a soup involving "scrums of scrums" and constant bickering over what was "really meant" by a one-sentence user story. Lots of people got scrum master certificates, though, which helped in their job searches when they started quitting. This was a product company, too. In the cases where I've seen it rolled out in consulting, it crashed and burned even faster, pretty much out of the gate, basically after the first sprint that changed and required a re-planning meeting which revealed a substantial underestimate made on the basis of misunderstood user stories. I'd love to see some numbers on how many successful agile organizations started out that way vs. how many evolved into it from a background in waterfall. I think if you start out with an agile organization on day one and completely bake all of the ramifications into your business then, you have a much greater chance of success than you do retrofitting it.
posted by feloniousmonk at 11:29 AM on August 31, 2015 [1 favorite]
posted by feloniousmonk at 11:29 AM on August 31, 2015 [1 favorite]
It's hard to imagine a group as readily hostile to the idea as developers
No kidding. I wish I had a dollar for every programmer who told me in the 90s that they would never need a union because their skills would always be in demand and they were such smart people that they would always negotiate the best contracts for themselves ever.
Would have kept me in beer and skittles all throughout the dotcom crash, that's for sure.
posted by fifteen schnitzengruben is my limit at 11:39 AM on August 31, 2015 [5 favorites]
No kidding. I wish I had a dollar for every programmer who told me in the 90s that they would never need a union because their skills would always be in demand and they were such smart people that they would always negotiate the best contracts for themselves ever.
Would have kept me in beer and skittles all throughout the dotcom crash, that's for sure.
posted by fifteen schnitzengruben is my limit at 11:39 AM on August 31, 2015 [5 favorites]
With this agenda, it is possible to characterize the Agile movement as a labour union.
Unimpeachable logic.
As a completely unrelated aside, this 3x5 index card printed with a recipe for meat loaf sandwiches promotes sustainable development, describes successful starting and ending states, and empowers users to self-organize around a shared goal. Thus, it is possible to characterize this recipe card as a software manifesto.
posted by Mayor West at 11:44 AM on August 31, 2015 [13 favorites]
Unimpeachable logic.
As a completely unrelated aside, this 3x5 index card printed with a recipe for meat loaf sandwiches promotes sustainable development, describes successful starting and ending states, and empowers users to self-organize around a shared goal. Thus, it is possible to characterize this recipe card as a software manifesto.
posted by Mayor West at 11:44 AM on August 31, 2015 [13 favorites]
Diogenes: Yup, being a technical writer in an Agile environment gives me lots of opportunities to hone my telepathy skills. I miss specs.
I dunno. Working from specs is often a good opportunity to hone one's fictional chops.
This is actually another fascinating cultural angle, in that because the product isn't nearly as fixed as its (again, often fictional) counterpart in waterfall, it becomes necessary (and, indeed, in devops, is made very explicitly so) for visibility of the project to be hugely greater across the whole cycle. It doesn't matter what your role is (or roles are), there's nothing going on which isn't your business. For a lot of people, that's really quite threatening - the notion that others are not only allowed, but expected, to look at your work pretty much as you do it seems very uncomfortable. A technical author, or a test scripter, or a security specialist, just cannot operate in a silo where Stuff Appears, is with them for x weeks, and afterwards Stuff is shipped out. You have to know what's happening, with some degree of practical knowledge, up and down the line.
This is antithetical to the way things have worked in many ways. It most certainly needs good communication between people (not that engineers are particularly challenged here, goodness me no) that isn't mediated through process, it needs a much lighter approach to explicit or implicit status, and it needs people to be open to ideas, willing to ask and answer questions, and prepared to demonstrate ignorance and error.
This... isn't going to work after all, is it?
posted by Devonian at 11:51 AM on August 31, 2015 [4 favorites]
I dunno. Working from specs is often a good opportunity to hone one's fictional chops.
This is actually another fascinating cultural angle, in that because the product isn't nearly as fixed as its (again, often fictional) counterpart in waterfall, it becomes necessary (and, indeed, in devops, is made very explicitly so) for visibility of the project to be hugely greater across the whole cycle. It doesn't matter what your role is (or roles are), there's nothing going on which isn't your business. For a lot of people, that's really quite threatening - the notion that others are not only allowed, but expected, to look at your work pretty much as you do it seems very uncomfortable. A technical author, or a test scripter, or a security specialist, just cannot operate in a silo where Stuff Appears, is with them for x weeks, and afterwards Stuff is shipped out. You have to know what's happening, with some degree of practical knowledge, up and down the line.
This is antithetical to the way things have worked in many ways. It most certainly needs good communication between people (not that engineers are particularly challenged here, goodness me no) that isn't mediated through process, it needs a much lighter approach to explicit or implicit status, and it needs people to be open to ideas, willing to ask and answer questions, and prepared to demonstrate ignorance and error.
This... isn't going to work after all, is it?
posted by Devonian at 11:51 AM on August 31, 2015 [4 favorites]
There was an earlier utopia for engineers in relation to capitalism; not that they would form labour unions in reaction to it, but that they would be, sooner or later, running the thing.
I wonder what happened to that.
posted by clawsoon at 12:01 PM on August 31, 2015
I wonder what happened to that.
posted by clawsoon at 12:01 PM on August 31, 2015
This... isn't going to work after all, is it?
Heh.
It can work, I swear: in an organization that's serious about it, and that doesn't gut it by "adapting" it to their existing workflow. But, oftentimes it doesn't. And as previously mentioned in this thread: oh lord, the bikeshedding that occurs ...
(Some of the longest, most painful meetings I have ever had have been centered on things as trivial as what to name a couple of private member variables in a class, because everyone's got to be up in everyone else's shit and nothing is too small to have a Serious Opinion about and OH GOD OH GOD ABORT ABORT ABORT ...)
posted by tocts at 12:04 PM on August 31, 2015 [1 favorite]
Heh.
It can work, I swear: in an organization that's serious about it, and that doesn't gut it by "adapting" it to their existing workflow. But, oftentimes it doesn't. And as previously mentioned in this thread: oh lord, the bikeshedding that occurs ...
(Some of the longest, most painful meetings I have ever had have been centered on things as trivial as what to name a couple of private member variables in a class, because everyone's got to be up in everyone else's shit and nothing is too small to have a Serious Opinion about and OH GOD OH GOD ABORT ABORT ABORT ...)
posted by tocts at 12:04 PM on August 31, 2015 [1 favorite]
Agile is largely bullshit. Whenever someone tells me they are a scrum-master, I secretly cackle inside -- reminds me of A+ certification. How many deadlines did you slip to earn that badge? How much useless jargon did you memorize? How many condescending planning poker sessions did you run? How many post-it's have you written? How many times have you made people stand in a room like they were recalcitrant high schoolers.
Fucking awful...
How about focusing on software quality, or indeed, producing something useful -- rather than desperately clinging to the raft while people who don't know what they want push you to and fro...
posted by smidgen at 12:04 PM on August 31, 2015 [16 favorites]
Fucking awful...
How about focusing on software quality, or indeed, producing something useful -- rather than desperately clinging to the raft while people who don't know what they want push you to and fro...
posted by smidgen at 12:04 PM on August 31, 2015 [16 favorites]
clawsoon: The Roads Must Roll?
posted by growli at 12:12 PM on August 31, 2015 [1 favorite]
posted by growli at 12:12 PM on August 31, 2015 [1 favorite]
"Agile" in my experience has merely been a more trendy moniker for the crunch-time-all-the-time style of management.
posted by Thorzdad at 12:15 PM on August 31, 2015 [7 favorites]
posted by Thorzdad at 12:15 PM on August 31, 2015 [7 favorites]
Agile is one of those things like communism which is never actually done 100% anywhere because it's too limiting in practise.
Management still demands a new build for tomorrow with a feature they've just thought of, management still cancels features (sorry "stories") during the sprint or even while they are being implemented.
I've found that sprints give the powers that be a very short-termist view of everything, makes them much more eager to randomly hire and fire engineers as it's like the project is constantly ending and starting again, and everything is broken up into small enough chunks that they can imagine redistributing them to other people.
That doesn't make for a stable coherent team dynamic or a happy workplace.
posted by w0mbat at 12:28 PM on August 31, 2015 [3 favorites]
Management still demands a new build for tomorrow with a feature they've just thought of, management still cancels features (sorry "stories") during the sprint or even while they are being implemented.
I've found that sprints give the powers that be a very short-termist view of everything, makes them much more eager to randomly hire and fire engineers as it's like the project is constantly ending and starting again, and everything is broken up into small enough chunks that they can imagine redistributing them to other people.
That doesn't make for a stable coherent team dynamic or a happy workplace.
posted by w0mbat at 12:28 PM on August 31, 2015 [3 favorites]
My take has always been, if your project requires crunch time, then you are either involved in a land grab or you hate your engineers and/or can't plan your way out of a paper bag.
I've seen organizations where the management gets shipping bonuses and this is where any kind of project management will go wrong because there is an inherent conflict of interest at play. Any justification to push for crunch time as opposed to better planning at the outset and better process for the times when you justifiably need more time to ensure that the requested features are shipped with appropriate quality.
posted by plinth at 12:36 PM on August 31, 2015 [2 favorites]
I've seen organizations where the management gets shipping bonuses and this is where any kind of project management will go wrong because there is an inherent conflict of interest at play. Any justification to push for crunch time as opposed to better planning at the outset and better process for the times when you justifiably need more time to ensure that the requested features are shipped with appropriate quality.
posted by plinth at 12:36 PM on August 31, 2015 [2 favorites]
That's not Agile. That's a 2-week waterfall cycle death-march.
The methodology certainly has drawbacks, but my experience has been that the 2-week time horizon is extremely realistic in terms of how far in advance you can effectively plan.
If you're constantly being whipped into finishing an unrealistic number of tasks before the end of a sprint so the following sprint can be executed as-planned, your manager has entirely missed the point of having that 2-week window.
posted by schmod at 12:38 PM on August 31, 2015 [5 favorites]
The methodology certainly has drawbacks, but my experience has been that the 2-week time horizon is extremely realistic in terms of how far in advance you can effectively plan.
If you're constantly being whipped into finishing an unrealistic number of tasks before the end of a sprint so the following sprint can be executed as-planned, your manager has entirely missed the point of having that 2-week window.
posted by schmod at 12:38 PM on August 31, 2015 [5 favorites]
I guess that I've had better experiences with agile that you all have had. I just finished last month as QA lead on a nine month agile project that went better than any waterfall project that I've worked on. It started out with 3 developers and one QA but once we did a rough scoping of all the must-have features, management agreed to add two more devs and two more QA engineers. We worked hard but mostly within 40 hour weeks with a normal amount of engineer vacation time/sick days/personal days. We had the same team the whole way through and released pretty close to when we said we would with a pretty solid application. So far in the month and a half that it's been deployed, there's only been one minor production bug reported.
We're a non-profit so no bonuses, though.
posted by octothorpe at 12:49 PM on August 31, 2015 [2 favorites]
We're a non-profit so no bonuses, though.
posted by octothorpe at 12:49 PM on August 31, 2015 [2 favorites]
I've worked on one successful Agile project and several that have failed. The failures can all be attributed to the reality that the client (business owner, product management, etc) was, in fact, beholden to dates in the future.
On the project that went well, we dropped code Fridays and had bugs reported by the client on Monday, and these would be addressed/fixed by next Friday's drop, repeat ad infinitum.
In my experience it's very rare that the receiver of the software is really agile (even when the say they did cause they spoke to your PM on the golf course and yah, everyone's going agile, we should too).
A magic merge of real world delivery dates and story points doesn't work.
posted by parki at 12:55 PM on August 31, 2015 [6 favorites]
On the project that went well, we dropped code Fridays and had bugs reported by the client on Monday, and these would be addressed/fixed by next Friday's drop, repeat ad infinitum.
In my experience it's very rare that the receiver of the software is really agile (even when the say they did cause they spoke to your PM on the golf course and yah, everyone's going agile, we should too).
A magic merge of real world delivery dates and story points doesn't work.
posted by parki at 12:55 PM on August 31, 2015 [6 favorites]
Agile cannot fail, it can only be failed.
posted by murphy slaw at 1:04 PM on August 31, 2015 [6 favorites]
posted by murphy slaw at 1:04 PM on August 31, 2015 [6 favorites]
I know this will come as a shock, but there is a lot of software out there that has features that cannot be implemented in 2 weeks.
posted by smidgen at 1:07 PM on August 31, 2015 [7 favorites]
posted by smidgen at 1:07 PM on August 31, 2015 [7 favorites]
I know this will come as a shock, but there is a lot of software out there that has features that cannot be implemented in 2 weeks.
Sure, but that's kind of beside the point - nearly all of those features can be reasonably broken down into smaller tasks that fit in two weeks just fine.
Not that I'm an Agile fan, mind you, I just don't think that's actually one of its big failings.
posted by atbash at 1:08 PM on August 31, 2015 [2 favorites]
Sure, but that's kind of beside the point - nearly all of those features can be reasonably broken down into smaller tasks that fit in two weeks just fine.
Not that I'm an Agile fan, mind you, I just don't think that's actually one of its big failings.
posted by atbash at 1:08 PM on August 31, 2015 [2 favorites]
We had a storage vendor pitch to us that they're taking an Agile approach to development. New features and bug fixes are coming out every two weeks. It'll be great!
Our storage server is the centre of our business. Everybody stops if the storage stops.
We went with the vendor who said they'd been testing their current code release for the last five years or so.
Sure, but that's kind of beside the point - nearly all of those features can be reasonably broken down into smaller tasks that fit in two weeks just fine.
However, no feature can be tested against an infinitude of failure modes in two weeks.
posted by clawsoon at 1:11 PM on August 31, 2015 [2 favorites]
Our storage server is the centre of our business. Everybody stops if the storage stops.
We went with the vendor who said they'd been testing their current code release for the last five years or so.
Sure, but that's kind of beside the point - nearly all of those features can be reasonably broken down into smaller tasks that fit in two weeks just fine.
However, no feature can be tested against an infinitude of failure modes in two weeks.
posted by clawsoon at 1:11 PM on August 31, 2015 [2 favorites]
No feature can ever be tested against an infinitude of failure modes.
posted by parki at 1:16 PM on August 31, 2015 [2 favorites]
posted by parki at 1:16 PM on August 31, 2015 [2 favorites]
In fairness, most implementations of Afile are fucking terrible. If it's done properly it's a lot better. Still not the magic bullet it is sold as though.
posted by Artw at 1:17 PM on August 31, 2015
posted by Artw at 1:17 PM on August 31, 2015
In my experience, agile sprint cycles fail due to the difficulty of estimating the amount of time needed to complete development tasks. Engineers tend to underestimate, leading to many unnecessary moments of stress and rushed, low-quality work.
I like the core philosophical goals of agile. Teamwork, regular manager-developer checkups, testing, and flexibility are all necessary for successful software development. But I do not think sprints and scrum are an effective means of reaching those goals. I found that when the team is composed of talented, experienced people with large amount of mutual respect, empathy, and devotion to product quality, methodology pretty much falls into place. Scrum feels like a failed attempt to codify the practices of such a team in an effort to impose them on a less skilled, lower paid group of people with reduced freedom.
posted by scose at 1:18 PM on August 31, 2015 [8 favorites]
I like the core philosophical goals of agile. Teamwork, regular manager-developer checkups, testing, and flexibility are all necessary for successful software development. But I do not think sprints and scrum are an effective means of reaching those goals. I found that when the team is composed of talented, experienced people with large amount of mutual respect, empathy, and devotion to product quality, methodology pretty much falls into place. Scrum feels like a failed attempt to codify the practices of such a team in an effort to impose them on a less skilled, lower paid group of people with reduced freedom.
posted by scose at 1:18 PM on August 31, 2015 [8 favorites]
No feature can ever be tested against an infinitude of failure modes.
Indeed. But you hope the testing process is at least asymptotic.
posted by clawsoon at 1:19 PM on August 31, 2015 [2 favorites]
Indeed. But you hope the testing process is at least asymptotic.
posted by clawsoon at 1:19 PM on August 31, 2015 [2 favorites]
Agile is not suited for "must not fail" situations. Its suited for situations where its more important to get functionality deployed, even if that functionality still requires iterations. Now you can get from Agile to rock-solid functionality, but it requires a solid QA process and management buy in that shipping is gated by QA standards and not a date some dev engineer pulled out of their ass at some planning meeting months ago.
posted by forforf at 1:28 PM on August 31, 2015 [4 favorites]
posted by forforf at 1:28 PM on August 31, 2015 [4 favorites]
I've work in mostly agile environments. Under the right manager/pm/po/sm it works wonderfully. Developers have a say in what they can deliver, self-imposed deadlines are the kinds of deadlines that people adhere to more closely, and the continuous feedback loop rocks. I worked on a small team in a quasi-academic setting and we busted ass to make things work. In my current position things don't go down so smoothly. We have a director sitting in on planning. That individual will argue with team estimates when estimates don't jibe with delivery timelines. It's the worst of both worlds. Agile-like continuous reporting and requirement churn with waterfall-like deadlines and browbeating. Every day is an emergency. Code never gets refactored. The continuous reorgs and training in the new agile flavor of the month are just the icing on the cake. Yet I'd still rather organize in some agile fashion. It gets closer than the other options to the sort of inversion of control that unions traditionally provide.
posted by Fezboy! at 1:38 PM on August 31, 2015 [6 favorites]
posted by Fezboy! at 1:38 PM on August 31, 2015 [6 favorites]
The waterfall model is pretty much a strawman model, and I'd like authors to make that clear when they write about it. Nobody has ever had any ambitions to run any non-trivial project in strict waterfall.
Hhahahahahahahah no.
Strict waterfall is absolutely used in large companies. I've worked on several projects where you DO NOT, FULL STOP even consider start coding (for example), on pain of termination, until tens of thousands of pages of requirements documents specifying what each function is going to do are written, complete with flowcharts.
And then you write code which conforms to that spec.
And then you send it off to testing.
And then if anything is wrong with it after that, there are meetings upon meetings about whose fault it is, and the whole process has to start over from the top - you're not allowed to change the code without changing the spec first, and having it go through change control, and having that change control go up through management, come back down, and finally get an Engineering Change Order approved so you can fix, say, the length of a field.
Not everyone works in a startup in the valley.
posted by dmd at 2:06 PM on August 31, 2015 [28 favorites]
Hhahahahahahahah no.
Strict waterfall is absolutely used in large companies. I've worked on several projects where you DO NOT, FULL STOP even consider start coding (for example), on pain of termination, until tens of thousands of pages of requirements documents specifying what each function is going to do are written, complete with flowcharts.
And then you write code which conforms to that spec.
And then you send it off to testing.
And then if anything is wrong with it after that, there are meetings upon meetings about whose fault it is, and the whole process has to start over from the top - you're not allowed to change the code without changing the spec first, and having it go through change control, and having that change control go up through management, come back down, and finally get an Engineering Change Order approved so you can fix, say, the length of a field.
Not everyone works in a startup in the valley.
posted by dmd at 2:06 PM on August 31, 2015 [28 favorites]
atbash: "I know this will come as a shock, but there is a lot of software out there that has features that cannot be implemented in 2 weeks.
Sure, but that's kind of beside the point - nearly all of those features can be reasonably broken down into smaller tasks that fit in two weeks just fine."
scose: "In my experience, agile sprint cycles fail due to the difficulty of estimating the amount of time needed to complete development tasks. Engineers tend to underestimate, leading to many unnecessary moments of stress and rushed, low-quality work."
That's basically the entire point of the 2-week window. It helps manage complexity, and ensures that you're at least taking baby-steps towards the end goal. Incremental progress is better than no progress.
It also helps to ensure that you're actually discussing the merits of your actual end goal itself by getting continuous feedback. Agile has a much higher tolerance for the "Oh, this isn't working and we need to change course" scenario, and helps to dispense with the sunk cost fallacy.
I'm probably coming across as defending Agile a bit too strongly -- I've definitely seen bad implementations, and as I mentioned, it doesn't necessarily fit well with many businesses (including the one I currently work in). However, unless you've got the staff to write the thousands of lines of documentation that dmd described above, the 2-week window is a good way to ensure that everybody on the team has a good idea of what they're working on at any given point.
posted by schmod at 2:12 PM on August 31, 2015 [3 favorites]
Sure, but that's kind of beside the point - nearly all of those features can be reasonably broken down into smaller tasks that fit in two weeks just fine."
scose: "In my experience, agile sprint cycles fail due to the difficulty of estimating the amount of time needed to complete development tasks. Engineers tend to underestimate, leading to many unnecessary moments of stress and rushed, low-quality work."
That's basically the entire point of the 2-week window. It helps manage complexity, and ensures that you're at least taking baby-steps towards the end goal. Incremental progress is better than no progress.
It also helps to ensure that you're actually discussing the merits of your actual end goal itself by getting continuous feedback. Agile has a much higher tolerance for the "Oh, this isn't working and we need to change course" scenario, and helps to dispense with the sunk cost fallacy.
I'm probably coming across as defending Agile a bit too strongly -- I've definitely seen bad implementations, and as I mentioned, it doesn't necessarily fit well with many businesses (including the one I currently work in). However, unless you've got the staff to write the thousands of lines of documentation that dmd described above, the 2-week window is a good way to ensure that everybody on the team has a good idea of what they're working on at any given point.
posted by schmod at 2:12 PM on August 31, 2015 [3 favorites]
I have been doing "Agile" for about 9 years as a coder, Scrum trainer, manager, etc. I'm a fan of Scrum, and the devs I've worked with have been too. It's intended as a humane and reasonable way to approach things that gives devs agency and respects people. I think one of the issues is that "Agile" is an umbrella for empirical processes in development, but it isn't a specific process itself. Scrum, Kanban, different XP processes - those are specific Agile methods or development processes. So if someone says they did Agile and hated it, I push back and ask about the specific methodologies. If they don't know, or it's a mish-mash, there's your issue right there. If you pick a process (say Scrum) and do all the parts, and adhere to the spirit, it works WAYYYYYYYYYYYYYYY better than something like waterfall for most of the types of projects people are doing out there. But you have to do the whole thing.
I don't blame devs who have fallen victim to "bad Agile", because that's an organizational failure. But I lot of what I hear sounds like "We did baseball, but no, we only had 3 people per side, and we didn't agree on how to keep score, and we practiced a couple of times but the manager thought we were playing football ... BASEBALL SUCKS!!!" No, you worked somewhere where they had no idea what Scrum was or what the fuck the point of doing it even is. Agile as a buzzword seems to be killing agile, which is a drag.
Also just to get this in there, you totally do documentation in agile ... you just value it less in relation to stuff actually working. "Working software over comprehensive documentation". Not "yay we don't have to write anything down!!!"
posted by freecellwizard at 2:46 PM on August 31, 2015 [2 favorites]
I don't blame devs who have fallen victim to "bad Agile", because that's an organizational failure. But I lot of what I hear sounds like "We did baseball, but no, we only had 3 people per side, and we didn't agree on how to keep score, and we practiced a couple of times but the manager thought we were playing football ... BASEBALL SUCKS!!!" No, you worked somewhere where they had no idea what Scrum was or what the fuck the point of doing it even is. Agile as a buzzword seems to be killing agile, which is a drag.
Also just to get this in there, you totally do documentation in agile ... you just value it less in relation to stuff actually working. "Working software over comprehensive documentation". Not "yay we don't have to write anything down!!!"
posted by freecellwizard at 2:46 PM on August 31, 2015 [2 favorites]
One of the largest problems I've come across in software development is the 'I don't know'. These are things which have either never been done before, have never been done by anyone in the company or have never been done by the dev doing the item.
Managament can't seem to deal with an honest "I have no fucking clue! I'll know more in a few days or a week, but even that might be wrong. I'll know better when I've actual started codingh what I've drawn up, but I might then halfway through think/figure out it can't be done or can't be done the way I thought it could, so I have to do the whole thing over and then ... well, goto the start of everything I've written from the first parenthesis".
Because that is really software develepment: research and planning based on what you think is needed/wanted, then trying to make it. And yeah, you can chunk everything into managable pieces you think you can estimate times for, but you can only really estimate/specify things you (or someone on the team) has done before. But all those other chunks can go wrong and either expand or cause whole other chunks or even the whole fucking collection of chunks to be invalidated and then all that has to be re-thought.
It's like a multi-level parralel/sequential accordion, where each chamber can screw itself, what follows, everything before (and thus after) it or screw with a parralel track-of-chambers in all those ways.
A multi-dimensional Gant-chart, if you will, where a lot of tracks are connected and you only know the length of some of the units.
And sometimes you discover thatwhat you really need to do, either do to now actually understanding the requirements or the engineering needed is to refactor a bit of it, or chuck the whole fucking thing and start anew.
That is what management needs to realise and what they should tell anyone who buys software.
Yeah, as if that's gonna happen.
So, failing that? Management has to know that software development is inherently flexible (both in expansion and sometimes in contraction) and charge their customers taking into account the statistics of sometimes having to completely re-do a project. And they need to sign contracts which insist the client acknowledge that sometimes, to get a working thing, it will have to be past the schedule, because deadlines only work for things which, in their entirety, have been done before by the team.
Wow, that's all kind a offtopic ;) So: deadlines and software don't mix, waterfall and agile are antagonistic, and better working hours depend on what deal management and client strike, whilst better pay depends on what deal you yourself AND your collegueas strike with your managemnt. Methodology has nothing to do with pay and working-hours depend on what management agrees to with clients, which doesn't depend on methodology so much as preparing (and charging!) the client for what can go wrong with THIS project with THIS team.
posted by MacD at 2:47 PM on August 31, 2015 [17 favorites]
Managament can't seem to deal with an honest "I have no fucking clue! I'll know more in a few days or a week, but even that might be wrong. I'll know better when I've actual started codingh what I've drawn up, but I might then halfway through think/figure out it can't be done or can't be done the way I thought it could, so I have to do the whole thing over and then ... well, goto the start of everything I've written from the first parenthesis".
Because that is really software develepment: research and planning based on what you think is needed/wanted, then trying to make it. And yeah, you can chunk everything into managable pieces you think you can estimate times for, but you can only really estimate/specify things you (or someone on the team) has done before. But all those other chunks can go wrong and either expand or cause whole other chunks or even the whole fucking collection of chunks to be invalidated and then all that has to be re-thought.
It's like a multi-level parralel/sequential accordion, where each chamber can screw itself, what follows, everything before (and thus after) it or screw with a parralel track-of-chambers in all those ways.
A multi-dimensional Gant-chart, if you will, where a lot of tracks are connected and you only know the length of some of the units.
And sometimes you discover thatwhat you really need to do, either do to now actually understanding the requirements or the engineering needed is to refactor a bit of it, or chuck the whole fucking thing and start anew.
That is what management needs to realise and what they should tell anyone who buys software.
Yeah, as if that's gonna happen.
So, failing that? Management has to know that software development is inherently flexible (both in expansion and sometimes in contraction) and charge their customers taking into account the statistics of sometimes having to completely re-do a project. And they need to sign contracts which insist the client acknowledge that sometimes, to get a working thing, it will have to be past the schedule, because deadlines only work for things which, in their entirety, have been done before by the team.
Wow, that's all kind a offtopic ;) So: deadlines and software don't mix, waterfall and agile are antagonistic, and better working hours depend on what deal management and client strike, whilst better pay depends on what deal you yourself AND your collegueas strike with your managemnt. Methodology has nothing to do with pay and working-hours depend on what management agrees to with clients, which doesn't depend on methodology so much as preparing (and charging!) the client for what can go wrong with THIS project with THIS team.
posted by MacD at 2:47 PM on August 31, 2015 [17 favorites]
One of the largest problems I've come across in software development is the 'I don't know'. These are things which have either never been done before, have never been done by anyone in the company or have never been done by the dev doing the item.
And that should be the case most of the time, right? If we have done X before, then instead of doing X again, why not re-use our already-built X. (If there's a good reason not to, then the porting/refactoring/hardening etc. effort for X-prime is going to involve some unknowns.)
posted by kurumi at 3:07 PM on August 31, 2015 [1 favorite]
And that should be the case most of the time, right? If we have done X before, then instead of doing X again, why not re-use our already-built X. (If there's a good reason not to, then the porting/refactoring/hardening etc. effort for X-prime is going to involve some unknowns.)
posted by kurumi at 3:07 PM on August 31, 2015 [1 favorite]
Something something patterns?
posted by Artw at 3:08 PM on August 31, 2015 [1 favorite]
posted by Artw at 3:08 PM on August 31, 2015 [1 favorite]
I'm in Ops running Agile sprints (yes, the dreaded DevOps!). We use a weird mix of Agile and Waterfall. The architects give us an end goal, and want to have some say in the expensive tooling. But it is up to us in the trenches to get us there for the most part.
We get a bunch of feedback every week, visibility up the chain on how we're spending our time and their money, and protection from aholes that come up and want "Just a couple of minutes of your time to help with something."
Now if we could just get our second party "partners" to tell us wtf they're doing.
posted by mfu at 3:14 PM on August 31, 2015
We get a bunch of feedback every week, visibility up the chain on how we're spending our time and their money, and protection from aholes that come up and want "Just a couple of minutes of your time to help with something."
Now if we could just get our second party "partners" to tell us wtf they're doing.
posted by mfu at 3:14 PM on August 31, 2015
Saying that the company "didn't do proper Agile" doesn't seem like a sufficient answer. Or at least it's an answer to the wrong question. Certainly, Agile can be done successfully. Projects can be done without any organizational strategy whatsoever. The problem is when things fail. And with Agile, there's no documentation to point to and say "here's where things went off the rails."
The last person to touch what went wrong owns it, and works through the night fixing it.
posted by destro at 3:21 PM on August 31, 2015 [3 favorites]
The last person to touch what went wrong owns it, and works through the night fixing it.
posted by destro at 3:21 PM on August 31, 2015 [3 favorites]
The funny thing about all the crazy variety of reports of failures (as well as successes) in this thread is that they are all probably accurate, especially the seemingly contradictory observations.
For those that have not seen the Agile Manifesto, take a quick look, it's really short.
It's pretty grounded and obvious and mainly what smart reasonable people will just do if given the chance. But I think perhaps the founders were just too smart and reasonable and assumed or pretended that others would be reasonable. But that just is not always the case and agile is used for various agendas and excuses.
"Scrum" is an attempt to enforce that reasonableness, which may not be a reasonable thing to do.
posted by sammyo at 6:41 PM on August 31, 2015 [3 favorites]
For those that have not seen the Agile Manifesto, take a quick look, it's really short.
It's pretty grounded and obvious and mainly what smart reasonable people will just do if given the chance. But I think perhaps the founders were just too smart and reasonable and assumed or pretended that others would be reasonable. But that just is not always the case and agile is used for various agendas and excuses.
"Scrum" is an attempt to enforce that reasonableness, which may not be a reasonable thing to do.
posted by sammyo at 6:41 PM on August 31, 2015 [3 favorites]
The waterfall model is pretty much a strawman model, and I'd like authors to make that clear when they write about it. Nobody has ever had any ambitions to run any non-trivial project in strict waterfall. The alternative to agile is mostly iterative processes with defined phases, not strict waterfall.I think you've been lucky. Waterfall in all seriousness is a stable of big projects in many large organizations, particularly non-IT focused ones. I've seen it in .edu, with months of work on massive requirements docs to be delivered to a vendor well before anyone writes a line of code, and it's been the default mode in government where the managers are under strict time and budget limits and it's politically safer to actually deliver a project for 2+X than it is to try for 1X and need to ask for more time/money to finish it, even if the total would be significantly lower.
Contracted projects have similar trade-offs: if you're going to have to spend years working with the results from whatever is written into a signed contract, spending so much time up front similarly makes sense from the perspective of a non-technical senior manager who doesn't understand why software development is different than buying new office space. A large part of the agile education I've heard people having to do is figuring out how to change their purchasing and contracting practice to be compatible with iteration without vendors simply padding the price to ludicrous levels.
This isn't always a failure, either – e.g. NASA somewhat famously used that kind of process for many years because the cost of a mistake on a space-craft is so much higher than the extra engineering time:
At the on-board shuttle group, about one-third of the process of writing software happens before anyone writes a line of code. NASA and the Lockheed Martin group agree in the most minute detail about everything the new code is supposed to do — and they commit that understanding to paper, with the kind of specificity and precision usually found in blueprints. Nothing in the specs is changed without agreement and understanding from both sides. And no coder changes a single line of code without specs carefully outlining the change. Take the upgrade of the software to permit the shuttle to navigate with Global Positioning Satellites, a change that involves just 1.5% of the program, or 6,366 lines of code. The specs for that one change run 2,500 pages, a volume thicker than a phone book. The specs for the current program fill 30 volumes and run 40,000 pages.Obviously that's not the same set of trade-offs which make sense for, say, a public website and I've heard that even the aerospace people have become more agile.
"Our requirements are almost pseudo-code," says William R. Pruett, who manages the software project for NASA. "They say, you must do exactly this, do it exactly this way, given this condition and this circumstance."
The real problem that I've seen is that, just as with Agile, companies don't actually follow their stated process: they'll structure it for waterfall but allow last minute changes or fail to talk with the actual users, skimp on staffing at key points, etc. NASA is a rare example of the process working fairly well because they found the safety benefits compelling enough that they were willing to actually spend the gobs of cash required to make it work.
posted by adamsc at 6:44 PM on August 31, 2015 [6 favorites]
I had a conversation today with a Project Manager about a project where, as usual, I am the only person doing everything.
PM: When do you estimate Task XYZ will be complete?
Me: If everything I need to design & code works perfectly, it'll be the end of the week. But if I run into something I cannot figure out how to do, then who knows?
PM: So ... 2 weeks?
Me: Sure, as an average between "one week" and "INFINITY", two weeks sounds perfectly sensible.
posted by Harvey Kilobit at 7:16 PM on August 31, 2015 [15 favorites]
PM: When do you estimate Task XYZ will be complete?
Me: If everything I need to design & code works perfectly, it'll be the end of the week. But if I run into something I cannot figure out how to do, then who knows?
PM: So ... 2 weeks?
Me: Sure, as an average between "one week" and "INFINITY", two weeks sounds perfectly sensible.
posted by Harvey Kilobit at 7:16 PM on August 31, 2015 [15 favorites]
Maybe I have been lucky, but I've worked in one large aerospace project with a 10 years+ horizon, and even there the requirements were revisited periodically.
And other than the now-defunct Shuttle software, I can't really think of anyone I've read about that has a committed-to-stone-tablets set of requirements as part of the methodology.
posted by Harald74 at 7:18 PM on August 31, 2015
And other than the now-defunct Shuttle software, I can't really think of anyone I've read about that has a committed-to-stone-tablets set of requirements as part of the methodology.
posted by Harald74 at 7:18 PM on August 31, 2015
Not that set in stone. From the NASA History Office:
NASA planned that PASS would be a continuing development process. After the first flight programs were produced, new functions needed to be added and adapted to changing payload and mission requirements. For instance, over 50% of PASS modules changed during the first 12 flights in response to requested enhancements.
Quite the change control board, tho:
Suggestions for changes to improve the system are unusually welcome. Anyone, astronaut, flight trainer, IBM programmer, or NASA manager, can submit a change request ... Due to the careful review of changes, it takes an average of 2 years for a new requirement to get implemented, tested, and into the field. Generally, requests for extra functions that would push out current software due to memory restrictions are turned down.
posted by RobotVoodooPower at 7:50 PM on August 31, 2015 [2 favorites]
NASA planned that PASS would be a continuing development process. After the first flight programs were produced, new functions needed to be added and adapted to changing payload and mission requirements. For instance, over 50% of PASS modules changed during the first 12 flights in response to requested enhancements.
Quite the change control board, tho:
Suggestions for changes to improve the system are unusually welcome. Anyone, astronaut, flight trainer, IBM programmer, or NASA manager, can submit a change request ... Due to the careful review of changes, it takes an average of 2 years for a new requirement to get implemented, tested, and into the field. Generally, requests for extra functions that would push out current software due to memory restrictions are turned down.
posted by RobotVoodooPower at 7:50 PM on August 31, 2015 [2 favorites]
Heck, in waterfall shops, I've been required to spend months writing test plans, test strategy, requirement coverage matrixes and test design documents before ever having anything to actually test. My last job wanted me to write these fifty to seventy-five page documents describing every test case for every bullet item in the PRD in detail long before any product code was actually written or delivered. I spent way more time preparing to test then I actually did testing the product. It didn't really matter though since testing was pointless because by the time QA got the product to test, there was never time left to fix any bugs we found.
As a QA person, I much prefer agile development which lets me actually see and test the pieces of the product while it's being developed instead of having it dropped whole on me after waiting for a year while the development team did its thing. At least I have a chance to get something fixed before it goes out the door instead of just finding bugs, filing reports and then getting frustrated because none of them ever got fixed.
posted by octothorpe at 7:58 PM on August 31, 2015 [5 favorites]
As a QA person, I much prefer agile development which lets me actually see and test the pieces of the product while it's being developed instead of having it dropped whole on me after waiting for a year while the development team did its thing. At least I have a chance to get something fixed before it goes out the door instead of just finding bugs, filing reports and then getting frustrated because none of them ever got fixed.
posted by octothorpe at 7:58 PM on August 31, 2015 [5 favorites]
Won't anyone speak up for the waterfall method? I will, tepidly: like Agile, it works when it's done well, only it's normally not done at all!
The main problem is that programmers hate writing English. When I was at SPSS, this was handled by making design a separate department. Designers wrote full design documents, in extensive consultation with management, programmers, QA, tech writers, etc. One advantage was that QA and tech writers could get to work while the code was being written; another was that there was a real roadblock to managers demanding last-minute changes.
It worked well for smallish projects that took a year or so. Huge or long projects were another story... but there the problem is that though everyone's read The Mythical Man-Month, we persist in making the same mistakes Brooks described 50 years ago.
Other places I worked can't be said to follow the waterfall method, because there was no design step-- beyond a few days of meetings at the start of the project. If allowed, devs would much rather make it up as they go along, and to managers, design seems to be considered wasted time.
posted by zompist at 8:52 PM on August 31, 2015 [1 favorite]
The main problem is that programmers hate writing English. When I was at SPSS, this was handled by making design a separate department. Designers wrote full design documents, in extensive consultation with management, programmers, QA, tech writers, etc. One advantage was that QA and tech writers could get to work while the code was being written; another was that there was a real roadblock to managers demanding last-minute changes.
It worked well for smallish projects that took a year or so. Huge or long projects were another story... but there the problem is that though everyone's read The Mythical Man-Month, we persist in making the same mistakes Brooks described 50 years ago.
Other places I worked can't be said to follow the waterfall method, because there was no design step-- beyond a few days of meetings at the start of the project. If allowed, devs would much rather make it up as they go along, and to managers, design seems to be considered wasted time.
posted by zompist at 8:52 PM on August 31, 2015 [1 favorite]
In almost 20 years of programming I've seen no correlation between "methodology" and success or enjoyment. Its about the people/management and how they fundamentally behave and act, not about waterfall vs agile vs whatever. The best project I've ever been on was waterfall-ish, but I've also been on good agile-ish projects. The unquestionably worst project was also agile. The stricter the agile or waterfall model, the worse the project.
(And usually, defenders of a methodology -- particularly prevent in agile -- will essentially No True Agile anything that fails)
If I was interviewing at a company that was super excited about their development methodology, that would be an automatic decline. The more passionate people are about it the worse it is, since strict adherence to any philosophy is a sign that people won't be flexible enough to do what works (what works for the project, but also what works for the developers in the sense of not driving them to madness/illness/mutiny).
posted by thefoxgod at 8:59 PM on August 31, 2015 [11 favorites]
(And usually, defenders of a methodology -- particularly prevent in agile -- will essentially No True Agile anything that fails)
If I was interviewing at a company that was super excited about their development methodology, that would be an automatic decline. The more passionate people are about it the worse it is, since strict adherence to any philosophy is a sign that people won't be flexible enough to do what works (what works for the project, but also what works for the developers in the sense of not driving them to madness/illness/mutiny).
posted by thefoxgod at 8:59 PM on August 31, 2015 [11 favorites]
And other than the now-defunct Shuttle software, I can't really think of anyone I've read about that has a committed-to-stone-tablets set of requirements as part of the methodology.
Then you have never developed code for pharmaceutical manufacturing process control.
It was a huge shock to go from that to a small SaaS web development shop that does a super laid back version of agile fairly well.
My solution to overly vague requirements is pretty simple. When I get a one sentence story, I go find the person who wrote it and tell them they need to tell me what the fuck they want the code to do before I can write code that does that.
posted by double block and bleed at 9:07 PM on August 31, 2015 [3 favorites]
Then you have never developed code for pharmaceutical manufacturing process control.
It was a huge shock to go from that to a small SaaS web development shop that does a super laid back version of agile fairly well.
My solution to overly vague requirements is pretty simple. When I get a one sentence story, I go find the person who wrote it and tell them they need to tell me what the fuck they want the code to do before I can write code that does that.
posted by double block and bleed at 9:07 PM on August 31, 2015 [3 favorites]
Any methodology or combination of methodologies will work if it snaps well into the culture and context of the organization and the type of software being developed. It also helps if you have leaders who understand people and have read Brooks and Demarco. Bring on WaterScrumBan!!!!
posted by jasondigitized at 9:20 PM on August 31, 2015 [2 favorites]
posted by jasondigitized at 9:20 PM on August 31, 2015 [2 favorites]
IT IS TIME FOR A WALL WALK LADIES AND GENTLEMEN. I AM THE WALL-MASTER. DO YOU HAVE YOUR PROJECT UPDATES? GIVE THEM TO ME NOW. HOW BIG IS THE T-SHIRT FOR THIS PROJECT CARD? WHY HAVEN'T YOU UPDATED YOUR T-SHIRTS? MOVE YOUR T-SHIRT TO THE APPROPRIATE COLUMN. NO NO NO, STOP TALKING. IF YOU HAVE SOMETHING TO DISCUSS, DO IT OUTSIDE OF THIS MEETING: THIS IS A WALL WALK. WALL WALKS ARE FOR CLOSERS. THIS DAILY WALL WALK IS NOW COMPLETE.
posted by turbid dahlia at 9:42 PM on August 31, 2015 [6 favorites]
posted by turbid dahlia at 9:42 PM on August 31, 2015 [6 favorites]
Like so, so many things in the software world, agile is a useful tool that has been ridiculously oversold by people trying to use its cachet to pad resumes, climb corporate ladders, and move product. It slices, it dices, it spontaneously forms programmers into labor unions! GMAFB. No one methodology fits every situation in terms of the problem domain, the makeup of the team, or the size of the organization, and no process can provide the kind of bulwark against management overreach that a strong labor union can.
I love what I do, but god does my field love its buzzwords and flavors of the week.
posted by tonycpsu at 10:01 PM on August 31, 2015 [3 favorites]
I love what I do, but god does my field love its buzzwords and flavors of the week.
posted by tonycpsu at 10:01 PM on August 31, 2015 [3 favorites]
All the problems that have, thus far in these responses, been identified with Agile are, in fact, not the fault of Agile. They are human problems, caused by humans.
so it's like communism. or perhaps Roman Catholicism. Or like those guns that don't kill people, other people do. Except the guns make it easier.
I'm not here to dump on Agile. I don't know enough about it. But if it has a noted tendency to play to certain negative aspects of human nature, then this human starts to see it as dangerous.
posted by philip-random at 10:23 PM on August 31, 2015
so it's like communism. or perhaps Roman Catholicism. Or like those guns that don't kill people, other people do. Except the guns make it easier.
I'm not here to dump on Agile. I don't know enough about it. But if it has a noted tendency to play to certain negative aspects of human nature, then this human starts to see it as dangerous.
posted by philip-random at 10:23 PM on August 31, 2015
Virtually everyone I've worked with uses "agile" as a curse word, considers it somewhere between managerial sadism and a kind of hemorrhagic fever an organization sometimes catches. In either case, to be avoided at all costs. Stuff of nightmares.
I think the "no true Scotsman" response falls to appreciate that things are judged, and responsibility is assigned, not only by intent, but by consequences. The consequences of bringing "agile" into the workplace have been, on balance, an increase in developer suffering, resentment, burnout, mismanagement; in short: harm.
posted by ead at 10:59 PM on August 31, 2015 [2 favorites]
I think the "no true Scotsman" response falls to appreciate that things are judged, and responsibility is assigned, not only by intent, but by consequences. The consequences of bringing "agile" into the workplace have been, on balance, an increase in developer suffering, resentment, burnout, mismanagement; in short: harm.
posted by ead at 10:59 PM on August 31, 2015 [2 favorites]
I feel like I can't fit in with the kids with their scrums and their sprints and whatnot. I started with Yourdon and Booch back in the day, with a dash of Brooks and McConnell. I bought all the XP books when they first came out and spent a lot of time hanging around Ward's wiki. I devoured The Pragmatic Programmer and Fowler's books. I wound up without a project management methodology per se. It's more of a philosophy: Be like water and never forget Hofstadter's Law.
posted by ob1quixote at 11:54 PM on August 31, 2015 [2 favorites]
posted by ob1quixote at 11:54 PM on August 31, 2015 [2 favorites]
My Agile day.
I get in and check my queue of development jobs in Jira.
We have to say what we did yesterday and what we will do today.
I sit down and start or continue work on whatever the top job in my queue is, remembering to click the timer for that Jira ticket.
When the code is complete I move it into the testing column and start my next ticket.
Conveyor belt of misery.
posted by fernbritton at 12:03 AM on September 1, 2015 [4 favorites]
I get in and check my queue of development jobs in Jira.
We have to say what we did yesterday and what we will do today.
I sit down and start or continue work on whatever the top job in my queue is, remembering to click the timer for that Jira ticket.
When the code is complete I move it into the testing column and start my next ticket.
Conveyor belt of misery.
posted by fernbritton at 12:03 AM on September 1, 2015 [4 favorites]
I've been coding for a living for a while, and I think a software methodology is a bit like a set of kitchen implements.
It's perfectly possible to cook a delicious meal with stuff you bought at the dollar store. It's also possible to cook a terrible meal with Le Creuset saucepans and hi-tech ceramic knives. There are also quite a few idiots who think buying the right stuff will magically make them a good cook. But having the right stuff can make your life a bit easier.
I've worked in places using strict waterfall with four different sets of forms to fill out with each Change Request. I've worked in anarchic startups where the requirements are what your alcholic boss slurred at you in the pub last night. At the moment though I'm using Scrum, and I do find it's a fairly reasonable balance between bureaucracy and chaos.
The problems we have with it are partly the size of the product (a few million lines of code) and partly senior managers who are effectively demanding lists of features on a predetermined schedule. Agile doesn't really scale that well for huge products as all the original Agile texts always said. But at small scales as Shane said, it's as good a way as any and better than most.
posted by TheophileEscargot at 12:43 AM on September 1, 2015 [2 favorites]
It's perfectly possible to cook a delicious meal with stuff you bought at the dollar store. It's also possible to cook a terrible meal with Le Creuset saucepans and hi-tech ceramic knives. There are also quite a few idiots who think buying the right stuff will magically make them a good cook. But having the right stuff can make your life a bit easier.
I've worked in places using strict waterfall with four different sets of forms to fill out with each Change Request. I've worked in anarchic startups where the requirements are what your alcholic boss slurred at you in the pub last night. At the moment though I'm using Scrum, and I do find it's a fairly reasonable balance between bureaucracy and chaos.
The problems we have with it are partly the size of the product (a few million lines of code) and partly senior managers who are effectively demanding lists of features on a predetermined schedule. Agile doesn't really scale that well for huge products as all the original Agile texts always said. But at small scales as Shane said, it's as good a way as any and better than most.
posted by TheophileEscargot at 12:43 AM on September 1, 2015 [2 favorites]
fernbritton: "My Agile day.
I get in and check my queue of development jobs in Jira.
We have to say what we did yesterday and what we will do today.
I sit down and start or continue work on whatever the top job in my queue is, remembering to click the timer for that Jira ticket.
When the code is complete I move it into the testing column and start my next ticket.
Conveyor belt of misery."
Funny, I read through this up until the last line thinking, "hey that sounds great." I guess that YMMV.
posted by octothorpe at 4:14 AM on September 1, 2015 [2 favorites]
I get in and check my queue of development jobs in Jira.
We have to say what we did yesterday and what we will do today.
I sit down and start or continue work on whatever the top job in my queue is, remembering to click the timer for that Jira ticket.
When the code is complete I move it into the testing column and start my next ticket.
Conveyor belt of misery."
Funny, I read through this up until the last line thinking, "hey that sounds great." I guess that YMMV.
posted by octothorpe at 4:14 AM on September 1, 2015 [2 favorites]
One group of people I've found pretty resistant to Scrum is the senior people who want to work mostly alone and aren't following any process at all. Most agile-y processes are very, very lightweight compared to waterfall, but they aren't weightless. Also you have to be able to work with a team of developers, and not be territorial about magic code sections that only you understand. Hero genius developers are great for a while, but in the long run they are an anti-pattern if they won't share the knowledge.
On the business side, everyone who says those folks must buy in to agile are totally correct. If they aren't willing to get, for example, 2 week increments of work and take the time to inspect it and adjust the plan, it doesn't work. Getting the non-technical business units to align with incremental delivery is definitely harder than getting the dev team on board.
posted by freecellwizard at 6:26 AM on September 1, 2015
On the business side, everyone who says those folks must buy in to agile are totally correct. If they aren't willing to get, for example, 2 week increments of work and take the time to inspect it and adjust the plan, it doesn't work. Getting the non-technical business units to align with incremental delivery is definitely harder than getting the dev team on board.
posted by freecellwizard at 6:26 AM on September 1, 2015
My Agile day.
I get in and check my queue of development jobs in Jira.
We have to say what we did yesterday and what we will do today.
I sit down and start or continue work on whatever the top job in my queue is, remembering to click the timer for that Jira ticket.
When the code is complete I move it into the testing column and start my next ticket.
Conveyor belt of misery.
Christ, I wish I had that. We're on the Agile variant where the team is responsible for coming up with tasks based on the stories that are assigned to the team as a whole, so if those stories are out of your area of expertise or not defined enough for you to know what to do with them you end up spinning in the wind not knowing what the fuck to do.
posted by Artw at 9:32 AM on September 1, 2015 [2 favorites]
I get in and check my queue of development jobs in Jira.
We have to say what we did yesterday and what we will do today.
I sit down and start or continue work on whatever the top job in my queue is, remembering to click the timer for that Jira ticket.
When the code is complete I move it into the testing column and start my next ticket.
Conveyor belt of misery.
Christ, I wish I had that. We're on the Agile variant where the team is responsible for coming up with tasks based on the stories that are assigned to the team as a whole, so if those stories are out of your area of expertise or not defined enough for you to know what to do with them you end up spinning in the wind not knowing what the fuck to do.
posted by Artw at 9:32 AM on September 1, 2015 [2 favorites]
Sure, but that's kind of beside the point - nearly all of those features can be reasonably broken down into smaller tasks that fit in two weeks just fine.
I have a collection of natural language processing code that very much disagrees with that opinion. There are not a lot of complex scientific computing algorithms that fit neatly into that bucket - attempting to neatly chunk them up into features in a two week sprint usually ends in tears.
posted by combinatorial explosion at 3:15 PM on September 1, 2015 [1 favorite]
I have a collection of natural language processing code that very much disagrees with that opinion. There are not a lot of complex scientific computing algorithms that fit neatly into that bucket - attempting to neatly chunk them up into features in a two week sprint usually ends in tears.
posted by combinatorial explosion at 3:15 PM on September 1, 2015 [1 favorite]
Pro Tip: for 4 week tasks call the first two weeks "discovery" and the last two "execution".
(Does not matter that you actually pay attention to those labels)
posted by Artw at 3:42 PM on September 1, 2015 [1 favorite]
(Does not matter that you actually pay attention to those labels)
posted by Artw at 3:42 PM on September 1, 2015 [1 favorite]
If you have good developers and good requirements and give them enough time and don't crunch, you'll get a good product. People like to blame poor hiring decisions and internal politics on methodology - if your software team is dysfunctional, just fire all the assholes (they're likely the ones shifting the blame to the methodology.)
posted by Veritron at 6:19 PM on September 1, 2015 [2 favorites]
posted by Veritron at 6:19 PM on September 1, 2015 [2 favorites]
People like to blame poor hiring decisions and internal politics on methodology
I would argue that often, people also do the opposite -- that is, they ascribe successes to their poor methodology when it was really the result of having hired good developers who are able to do well despite the impediments imposed on them by the process.
That's not to say process is bad, but simply that the inability of people in charge to identify the direct cause of success or failure is not at all limited to misunderstanding the role of the process.
posted by tocts at 8:14 AM on September 2, 2015 [3 favorites]
I would argue that often, people also do the opposite -- that is, they ascribe successes to their poor methodology when it was really the result of having hired good developers who are able to do well despite the impediments imposed on them by the process.
That's not to say process is bad, but simply that the inability of people in charge to identify the direct cause of success or failure is not at all limited to misunderstanding the role of the process.
posted by tocts at 8:14 AM on September 2, 2015 [3 favorites]
« Older The Temporary Autonomous Zone, Ontological Anarchy... | ...helpless cogs in a corporate profit machine? Newer »
This thread has been archived and is closed to new comments
posted by spikeleemajortomdickandharryconnickjrmints at 10:13 AM on August 31, 2015