4 ms·

Agile is barely different to how teams I worked on in the 90s operated, naturally, without trying to implement and enforce a new holy grail, chase the rainbow r

Agile is barely different to how teams I worked on in the 90s operated, naturally, without trying to implement and enforce a new holy grail, chase the rainbow routine of machinic efficiency. I find it really is much ado about nothing, the emperors new clothes. An anal retentive formalising and trumpeting of common sense. I recall only one project which was waterfall, and the rest were used as soon as they were useful. I have an agile coach at my current job. As far as I can tell his job is to be the expert at drag and drop in Jira, and peeling post it notes. The only good thing I can say about agile is that it fills a space that will otherwise be filled with the next holy grail gimmick which management won't be able to resist as they sell themselves and their new magic power up the corporate ladder. I'm neck deep in this farce at the moment.

mcv 10y ago
If your agile coach is dragging and dropping in Jira, they're doing it wrong. That's more likely the PO's job. And agile coach, at least as I know them, guides several teams in their use of agile, without being part of the team. They have to be experts at recognizing whether a team functions well, which aspects need improving, and handing the team the tools to improve. It's a bit more distant from a team than a scrum master is.
vidarh 10y ago
> I recall only one project which was waterfall That's because even my Software Engineering textbook first published in the early 80's warned about it, and presented iterative, agile-like, models and referenced the article by Royce that first described waterfall (without naming it) as an example of a broken model in the early 70's... Iterative processes have been widely taught since the late 70's at least.
kpil 10y ago
Sure. A lot of "Agile" is actually cargo-cult agile, used as a vehicle for self-promotion: The daily scrum, the sticky-notes or the Jira.board, and all that other ceremony. Typically retrofitted on top of a defunct process, with separate requirement analysts, "software architects" whatever that means, and a lot of control functions and processes inherited from the manufacturing industry. What makes that work is probably the few people that actually understands software development - typically a low percentage of the massive overhead in a typical business software development center. But you've got to start somewhere. The Agile ceremonies are not bad, but relatively useless if there is no "real Agile" beneath. Unfortunately, they are easy to implement whereas "real" agile is not. And what is "real" agile: The core agile ideas (the manifesto), the focus on flow-control, the incremental analysis-build-analysis cycle, continuous improvement, multi-disciplined teams, knowledge sharing, analysis methods that involves multiple people (like story mapping), empowerment (self governing teams, but also product owners). Perhaps above all, the idea that software development processes should not be defined by business administrators, but instead by people that are actually qualified. I guess it could be labeled as "common sense", but a few things are typically hard to reason about for a lot of people, for instance the flow-control part (such as kanban), as dynamic efficiency is harder to "see" than static efficiency. But getting good at that is actually hard. Adding 1000 fields and workflows to Jira is easy.
- Retric 10y ago
  Process is not going to fix a toxic work environment. But, it can make a positive difference over time. Many teams start out productive, but they also tend to degrade over time. How many 10 year old projects have you been happy to start working on? How about 20? Those are the places most in need of someone to cut the bullshit.
- aphextron 10y ago
  >cargo-cult agile You just described my last job...
rm_-rf_slash 10y ago
The reason development methodologies exist even in the face of common sense is the same reason management metrics have been around for ages: they aren't for the people doing the work, they're for the managers to quantify the work their team does for the sake of their managers. Not every manager can understand every facet of the operation two levels down. Methodologies not only give them an understandable metric of what is going on, they also have something to point to when upper-upper management is considering a lower manager for a promotion or trying to figure out why things are taking too long or not working as expected. Development methodologies have a place, that's for sure, but structure for structure's sake - in my experience - tends to exist primarily for the benefit of the managers, rather than the engineers.

mcv 10y ago

If your agile coach is dragging and dropping in Jira, they're doing it wrong. That's more likely the PO's job. And agile coach, at least as I know them, guides several teams in their use of agile, without being part of the team. They have to be experts at recognizing whether a team functions well, which aspects need improving, and handing the team the tools to improve. It's a bit more distant from a team than a scrum master is.

vidarh 10y ago

> I recall only one project which was waterfall That's because even my Software Engineering textbook first published in the early 80's warned about it, and presented iterative, agile-like, models and referenced the article by Royce that first described waterfall (without naming it) as an example of a broken model in the early 70's... Iterative processes have been widely taught since the late 70's at least.

kpil 10y ago

Sure. A lot of "Agile" is actually cargo-cult agile, used as a vehicle for self-promotion: The daily scrum, the sticky-notes or the Jira.board, and all that other ceremony. Typically retrofitted on top of a defunct process, with separate requirement analysts, "software architects" whatever that means, and a lot of control functions and processes inherited from the manufacturing industry. What makes that work is probably the few people that actually understands software development - typically a low percentage of the massive overhead in a typical business software development center. But you've got to start somewhere. The Agile ceremonies are not bad, but relatively useless if there is no "real Agile" beneath. Unfortunately, they are easy to implement whereas "real" agile is not. And what is "real" agile: The core agile ideas (the manifesto), the focus on flow-control, the incremental analysis-build-analysis cycle, continuous improvement, multi-disciplined teams, knowledge sharing, analysis methods that involves multiple people (like story mapping), empowerment (self governing teams, but also product owners). Perhaps above all, the idea that software development processes should not be defined by business administrators, but instead by people that are actually qualified. I guess it could be labeled as "common sense", but a few things are typically hard to reason about for a lot of people, for instance the flow-control part (such as kanban), as dynamic efficiency is harder to "see" than static efficiency. But getting good at that is actually hard. Adding 1000 fields and workflows to Jira is easy.

Retric 10y ago
Process is not going to fix a toxic work environment. But, it can make a positive difference over time. Many teams start out productive, but they also tend to degrade over time. How many 10 year old projects have you been happy to start working on? How about 20? Those are the places most in need of someone to cut the bullshit.
aphextron 10y ago
>cargo-cult agile You just described my last job...

rm_-rf_slash 10y ago

The reason development methodologies exist even in the face of common sense is the same reason management metrics have been around for ages: they aren't for the people doing the work, they're for the managers to quantify the work their team does for the sake of their managers. Not every manager can understand every facet of the operation two levels down. Methodologies not only give them an understandable metric of what is going on, they also have something to point to when upper-upper management is considering a lower manager for a promotion or trying to figure out why things are taking too long or not working as expected. Development methodologies have a place, that's for sure, but structure for structure's sake - in my experience - tends to exist primarily for the benefit of the managers, rather than the engineers.