7 ms·

To this day I still don’t understand how one can read the agile manifesto and somehow get to scrum. The whole thing is about processes, and tools (jira)… the c

To this day I still don’t understand how one can read the agile manifesto and somehow get to scrum. The whole thing is about processes, and tools (jira)… the complete opposite. The reason everyone ends up doing waterfall is that it’s not the devs who you need to convince when selling agility, is the chain of command. Being agile means having no long term plan. If the C-suite can’t handle that, you’ll never be agile.

cube00 5y ago
The C-suite only hear "fast delivery" and ignore the other parts while also demanding the waterfall parts that suit the ways they need to work such as committing devs to deadlines one financial year out when funding bids have to be submitted. There is something ironic about being ordered to estimate a 12 month work order while also being told make sure "it's agile" and delivered on time and on budget by ++currrentYear.
- clairity 5y ago
  yes, non-agile organizations try to bolt on agile at the 'bottom' of the hierarchy, and that's a sure recipe for failure because of the significant impedance mismatch that causes. the c-suite wants to hand down directives, and the agile teams want to listen to the customer first, leading to conflicting interests. an organization has to be receptive to turning the marketing function upside down (product being one of the 4 P's of marketing) to be really successful at agile. that's why consulting firms tend to be more successful than ordinary product/service firms at it, because they're already inverting the marketing function (to lead with what the customer wants and then trying to execute on that). executives don't tend to want successfully implemented agile, as it undermines their control of (customer/market) information, and the organizational power derived from that.
  - imbnwa 5y ago
    In my mind, this sorta proves that most companies should not have in-house engineering divisions and instead most of us should be working for software engineering firms much like actual architects. This would likely also solve the career development/engineering pedagogy problem that is so lamented since firms would have better control over time internally.
- MikeDelta 5y ago
  So true, and some even have budget boards that decide on allocation of money to the teams according to the central strategy, so the POs need to follow those priorities and justify what they do based on that instead of 'increasing value of the product'.
- ljf 5y ago
  Faster delivery should always be corrected to 'faster to fail'
iamflimflam1 5y ago
Indeed - the principals of the manifesto are very easy to read: https://agilemanifesto.org/ https://agilemanifesto.org/ and https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html The problem is people take the main points and use them to justify their own wants and needs. These are the main points: * Individuals and interactions over processes and tools This does not say you should not have any processes and tools. * Working software over comprehensive documentation The problem with this is you now have people who don't like writing documentation claiming that agile says "You shouldn't write any documentation" or "I don't need to comment my code as the agile manifesto says you shouldn't"... * Customer collaboration over contract negotiation This does not say "you should not have a contract". * Responding to change over following a plan People interpret this as "We shouldn't plan anything. If you are planning then you aren't doing agile".
- dtech 5y ago
  It's the next paragraph after those bullets: > That is, while there is value in the items on > the right, we value the items on the left more. Also keep in mind the manifesto came as a response to a "document-first" software design method, where basically the complete product was documented, planned and contracted before the first code was written.
  - xondono 5y ago
    * Individuals and interactions over processes and tools * Working software over comprehensive documentation * Customer collaboration over contract negotiation * Responding to change over following a plan And then you grab any Scrum guide and you’ll see: * roles and processes: (Scrum master, product owner,…) * tools: Scrum now is almost synonymous with Jira. * Documentation mandates: “how to write proper user stories”, “how you should name, split and classify tasks”,… I know a lot of people don’t consider it this way, but the backlog IS documentation. The second most popular tool after Jira in Scrum teams is drumroll Confluence. * Contract negotiation: Scrum defines a specific role (PO) with the main task of handling contract negotiations. * Responding to change: Even the tools will complain if you change things mid sprint (because you’ll ruin the all important metrics!).
kinbiko 5y ago
> To this day I still don’t understand how one can read the agile manifesto and somehow get to scrum. It's almost like scrum pre-dates the agile manifesto. (Which it does)
- xondono 5y ago
  I know, but it’s not how it’s sold. The typical presentation is “we need agility => Scrum”. One would assume that if Scrum doesn’t fit the bill, one would discard it.
  - geekbird 5y ago
    But, unfortunately, scrum has become synonymous with "Agile" in the corporate mind. Everything, including SRE and ops work, gets force-fit into Jira "Agile" (really FrAgile) methods and meeting-heavy rituals. But scrum easily devolves to rapid cycle waterfall death marches. This has been going on for at least nine years that I know of. It sucks. When a company says "We do Agile with Scrum" I wince and am very, very skeptical.
    - MikeDelta 5y ago
      And add DevOps to it, because then one can get rid of run == cost savings.
- lupire 5y ago
  Scrune advocates contributed to the Agile Manifesto, though. They are aligned.
- tyingq 5y ago
  But the manifesto was written by many of the same people. The expectation that they would be compatible seems reasonable. And, the "Scrum Alliance" happened very shortly after the manifesto.
Scarblac 5y ago
In Scrum, the team should be self-managing. The Product Owner and Scrum Master are not managers or bosses, they're a customer representative and a secretary. I can see that working with "people over process". But then came certification, existing managers et cetera and that was lost.
- xondono 5y ago
  > In Scrum, the team should be self-managing. The Product Owner and Scrum Master are not managers or bosses, they're a customer representative and a secretary. I can see that working with "people over process". Except those are roles and processes, not people. Putting people before processes and tools means treating people like adults and letting them work how they’re more comfortable.
- WJW 5y ago
  Many (most?) of the early Agile promoters were owners or partners in a consultancy doing work for clients. These clients often couldn't really specify in enough detail what they needed from the software that was to be built. In that scenario, the structures of Agile make a lot more sense. These days, when a company decides to start using some form of Agile methodology (usually scrum) they need to do something with the people who were previously managing the team and so they often assign them the Product Owner role or something similar. Obviously, the power balance between such a manager (who often retains power over raises and promotions as well) and a line employee team member is completely different than the power balance between a Product Owner as representative of a company and a team of consultants who together own their own consultancy business. Doubly so if the consultants have many more clients and don't exclusively depend on this one Product Owner to pay their bills.
  - g051051 5y ago
    > Many (most?) of the early Agile promoters were owners or partners in a consultancy doing work for clients. This is a huge point that people who weren't in the industry back then completely miss: The people behind the Agile manifesto weren't trying to figure out how to improve software development as a whole...they were looking for ways to improve their consulting business. What works for them as consultants selling consulting services doesn't make any sense for a company dev team trying to develop software.
marcus_holmes 5y ago
this. I built a prototype, put it in front of the relevant users, gathered the next set of changes, and... have to wait for the next sprint to implement them (even though they will take about a day, tops) because we can't change a sprint halfway. How is this Agile?
- tharkun__ 5y ago
  There's nothing preventing you from throwing it into the sprint. But then you gotta exchange it for something else you promised the customer at the start of your sprint. And agile doesn't just mean Scrum and sprints. If your primary way of working is what you described and you are able to get this feedback within hours then Kanban (another agile way of doing things) might suit you better.
- globalise83 5y ago
  Fine if you are a one-person team working on a small project, but when you have a team of several people doing uncoordinated frontend and backend changes simultaneously, chaos can often ensue. Also a lot of 'urgently needed' changes don't survive the few days until the start of the new sprint, so you would actually waste a lot of time chasing wild geese if you are just jumping straight in every time. Two weeks maximum wait (with a week or less very likely) seems like a reasonable tradeoff to me.
gumby 5y ago
> Being agile means having no long term plan. Bingo, and there lies its power — but only in the correct domain. For consulting, where the customer doesn’t quite understand what they need and you need to work your way forward in an exploratory fashion (and for a limited period) it’s great. And that was the environment it was designed for! You have a multi year engineering project? Really a waterfall, or a waterfall/spiral approach will work. Subtasks handled by a small group can be agile, and that can make the whole thing more efficient, but that need not be the case. A fetish for One True System is simply a cargo cult.
- oraphalous 5y ago
  > You have a multi year engineering project? Really a waterfall, or a waterfall/spiral approach will work. I'm not sure a long time frame is a necessary condition for a successful waterfall project - but I am certain it is not sufficient. What you need - long term project or not - is a rock solid understanding of business requirements. That means - no vague client demands, or startup style search for product / market fit - but a well established, and documented set of business processes that needs to be mapped to code. I also believe such projects require a leader who has this understanding, but also a talent for product design such that they can recognise and articulate clearly how the product will meet requirements. They need to be able to convince stakeholders. I do think such circumstances are rare for many organisations. But not so rare the prospect should be dismissed out of hand. I agree with your final statement though I think the challenge for many orgs would be in having the self awareness to recognise which approach is best for them.
cmrdporcupine 5y ago
I worked a couple of teams that were using Extreme Programming back in the day (early 2000s) and took a lot of lessons from that. Then in the intervening years I worked on teams that didn't have much of a process at all, and when I came back onto teams that were attempting agile, it was in the form of Scrum, and I just... to me it just doesn't click. It's not the agile I was taught, it's just a formula applied without much thought. Usually just a Pivotal Tracker type system + daily standups, going through the motions. I see no point in it.
endymi0n 5y ago
Fully agree, agile is fine. The real problem is that Scrum is not agile at all: Scrum is a fat "process" that enforces "following a plan" (regular, rigid meeting structure), "creating comprehensive documentation" (user stories, specs, mocks, task board) and "contract negotiation" (estimation meetings, planning poker). In that way, it's the exact opposite of the original agile Manifesto: http://agilemanifesto.org/ http://agilemanifesto.org/ The only thing Scrum has ever been great at (and why it's continually chosen despite proven harmful to development productivity) is that it's great at simulating continuous progress and control to management. Other than that, it's simply fostering architectural mess and a political, dogmatic attitude from and towards everyone. It all starts with a clear product vision from the top and defining how succeeding on it looks like. If you don't know where to go, Scrum will get you there faster and in even more directions at once. Or, to cite one of my all time favorites: "Building intuition on how to make good decisions and cultivating a great relationship with your team will get you 95% of the way there. The plethora of conceptual frameworks for organizing engineering teams won’t make much difference. They make good managers slightly better and bad managers slightly worse." — https://www.defmacro.org/2014/10/03/engman.html https://www.defmacro.org/2014/10/03/engman.html
- the_other 5y ago
  > The real problem is that Scrum is not agile at all: Scrum is a fat "process" that enforces "following a plan" (regular, rigid meeting structure), "creating comprehensive documentation" (user stories, specs, mocks, task board) and "contract negotiation" (estimation meetings, planning poker). In that way, it's the exact opposite of the original agile Manifesto: None of those things are Scrum. Scrum talks about defining bits of work to do on your product, but doesn’t mention User Stories. (But really, what’s the beef with User Stories? They’re short descriptions of what you hope to achieve! You gotta make some kind of plan sometime or you have no cohesion. If you don’t like the formality of User Stories, drop ‘em). The meeting structures are not defined by Scrum. The intent and topics are defined, but the structure (apart from vague suggestions for rhythm and timing). They only exist on a cadence so you can predict some parts of the system (like ensuring the client turns up to see the work done). You can change most of the details. Scrum doesn’t define any planning or estimation practice, it simply recommends you use some system so that the right people are in sync. You have to know if part A takes an order of magnitude longer to make than part B, so that they can hooked up properly. Specs? Mocks? Task board? None of that is Scrum. Scrum has two lists: the backlog, and the sprint backlog. The former grows as you learn what to make; the latter comes into being at the start of a sprint and disappears at the end. If you must put it in swim-lanes, that’s your loss. Don’t blame Scrum.
watwut 5y ago
> The reason everyone ends up doing waterfall is that it’s not the devs who you need to convince when selling agility Nah, agile is pushed from top to bottom, whether developers want OT or not. > Being agile means having no long term plan. If the C-suite can’t handle that, you’ll never be agile. While the devs are mostly OK with no plan, they do tend to want some planning once it is completely absent. What I see now is developers asking for damm analysis and documentation and C-suite not wanting to pay them. But it is really missing and we are wasting a lot of time due to not knowing the system.
- black_13 5y ago
  Yeah right on the „no plan“ what c-suite does love is having no plan .
rawgabbit 5y ago
>>> "Being agile means having no long term plan." I believe the angst against agile is it doesn't have a definitive viewpoint but is a reaction against what it sees as the evils of waterfall. Without definite processes, we get scrum. From my viewpoint, the issue is that scrum has a flawed understanding of Toyota Kaizen which it based itself on. Yes, in a Toyota factory, team members are expected to be able to perform any tasks required on the assembly line. But, the architecture Toyota uses, to enable this agility is limiting. For example, Toyota's TNGA architecture says there will only be five modular platforms to choose from; instead of the 100+ choices in the past [1]. Furthermore, Toyota is known for "boring" but reliable cars. It avoids all bleeding edge technology and prefers to make incremental improvements to its existing tech stack. That is to enable interchangeable workers; Toyota limits its car platforms and standardizes "cross cutting concerns". Toyota Kaizen is diametrically opposite of agile in IT. Toyota standardizes, simplifies, and makes incremental changes to its tech stack. Agile in IT means ditching today's platforms/architecture/frameworks/toolsets and jumping on the latest fad du jour. [1] https://en.wikipedia.org/wiki/Toyota_New_Global_Architecture https://en.wikipedia.org/wiki/Toyota_New_Global_Architecture
- CoolestBeans 5y ago
  The conservative Toyota you're describing is the Toyota that exists today, not the one that developed the Toyota Production System in the first place. Maybe they weren't bleeding edge but their engines had fuel injection, variable valve timing, and were computer controlled. Meanwhile the American automakers' idea of "futuristic" was putting LCD screens in the dash and making the cars talk when you left the door open. Through the 1980s and 1990s Toyota was putting out cars like the original LS 400 which embarrassed the German luxury automakers, the supercharged MR2, the turbocharged Supra, and high revving Celica, all while making cheap but great econoboxes. Its really in the 2000s where Toyota switches to an "only conservative cars" business model when the Toyota developed sports cars disappear, engines start staying mostly the same, and generations get longer.
  - namdnay 5y ago
    > Its really in the 2000s where Toyota switches to an "only conservative cars" business model when the Toyota developed sports cars disappear, engines start staying mostly the same, and generations get longer And then 2020s Toyota came out with the GR Yaris, as if to prove that every rule has an exception :)
the_other 5y ago
> The whole thing is about processes, and tools (jira)… the complete opposite. I don’t know how you can read the Scrum guide and get to that comment. JIRA is not Scrum and vice versa. The Scrum system is barely a system: 2 lists; 3 roles; 4 meetings; an exhortation to continually adjust (aiming at improvement); a recommendation you measure; guidance to include the “client” fairly often. That’s about it. This JIRA thing is just one tool among dozens of optional options. Use scraps of paper if it suits you.
dragonwriter 5y ago
> To this day I still don’t understand how one can read the agile manifesto and somehow get to scrum. You don't. I mean, literally, the relationship is inverted: Scrum predates Agile; the creators of the former later went on to contribute to the Agile Manifesto. > Being agile means having no long term plan No, it doesn't.
- msoad 5y ago
  > No, it doesn't. More like ignoring long term plans when you see something good is in front of you that wasn't planned. Think Slack team working on the video game an noticing their chat app is great...
  - dragonwriter 5y ago
    > More like ignoring long term plans when you see something good is in front of you that wasn't planned. I would say more like “long term plans are not high specificity and all plans are subject to rapid adaptation with new information” (though I admit lots of “agile” workflows have no long term plans but extremely rigid short-term plans.)
rodgerd 5y ago
> If the C-suite can’t handle that, you’ll never be agile. My experience is that the problems are typically: 1. Finance. Market targets, multi-year budget projections, "you promised business benefits from project delivery in Q3." Finance teams do not love Agile. 2. Companies who are collections of warring fiefdoms. You need to have an organisation which is mature enough to have reasonable conversations about changing priorites, delivery timelines, and funding in a reasonably dynamic way.
friendzis 5y ago
Scrum tries to sell a set tools, while the originals (Toyota manufacturing system) were methodologies, a set of processes to build those tools. Scrum is a different abstraction layer

cube00 5y ago

The C-suite only hear "fast delivery" and ignore the other parts while also demanding the waterfall parts that suit the ways they need to work such as committing devs to deadlines one financial year out when funding bids have to be submitted. There is something ironic about being ordered to estimate a 12 month work order while also being told make sure "it's agile" and delivered on time and on budget by ++currrentYear.

clairity 5y ago
yes, non-agile organizations try to bolt on agile at the 'bottom' of the hierarchy, and that's a sure recipe for failure because of the significant impedance mismatch that causes. the c-suite wants to hand down directives, and the agile teams want to listen to the customer first, leading to conflicting interests. an organization has to be receptive to turning the marketing function upside down (product being one of the 4 P's of marketing) to be really successful at agile. that's why consulting firms tend to be more successful than ordinary product/service firms at it, because they're already inverting the marketing function (to lead with what the customer wants and then trying to execute on that). executives don't tend to want successfully implemented agile, as it undermines their control of (customer/market) information, and the organizational power derived from that.
- imbnwa 5y ago
  In my mind, this sorta proves that most companies should not have in-house engineering divisions and instead most of us should be working for software engineering firms much like actual architects. This would likely also solve the career development/engineering pedagogy problem that is so lamented since firms would have better control over time internally.
MikeDelta 5y ago
So true, and some even have budget boards that decide on allocation of money to the teams according to the central strategy, so the POs need to follow those priorities and justify what they do based on that instead of 'increasing value of the product'.
ljf 5y ago
Faster delivery should always be corrected to 'faster to fail'

iamflimflam1 5y ago

Indeed - the principals of the manifesto are very easy to read: https://agilemanifesto.org/ https://agilemanifesto.org/ and https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html The problem is people take the main points and use them to justify their own wants and needs. These are the main points: * Individuals and interactions over processes and tools This does not say you should not have any processes and tools. * Working software over comprehensive documentation The problem with this is you now have people who don't like writing documentation claiming that agile says "You shouldn't write any documentation" or "I don't need to comment my code as the agile manifesto says you shouldn't"... * Customer collaboration over contract negotiation This does not say "you should not have a contract". * Responding to change over following a plan People interpret this as "We shouldn't plan anything. If you are planning then you aren't doing agile".

dtech 5y ago
It's the next paragraph after those bullets: > That is, while there is value in the items on > the right, we value the items on the left more. Also keep in mind the manifesto came as a response to a "document-first" software design method, where basically the complete product was documented, planned and contracted before the first code was written.
- xondono 5y ago
  * Individuals and interactions over processes and tools * Working software over comprehensive documentation * Customer collaboration over contract negotiation * Responding to change over following a plan And then you grab any Scrum guide and you’ll see: * roles and processes: (Scrum master, product owner,…) * tools: Scrum now is almost synonymous with Jira. * Documentation mandates: “how to write proper user stories”, “how you should name, split and classify tasks”,… I know a lot of people don’t consider it this way, but the backlog IS documentation. The second most popular tool after Jira in Scrum teams is drumroll Confluence. * Contract negotiation: Scrum defines a specific role (PO) with the main task of handling contract negotiations. * Responding to change: Even the tools will complain if you change things mid sprint (because you’ll ruin the all important metrics!).

kinbiko 5y ago

> To this day I still don’t understand how one can read the agile manifesto and somehow get to scrum. It's almost like scrum pre-dates the agile manifesto. (Which it does)

xondono 5y ago
I know, but it’s not how it’s sold. The typical presentation is “we need agility => Scrum”. One would assume that if Scrum doesn’t fit the bill, one would discard it.
- geekbird 5y ago
  But, unfortunately, scrum has become synonymous with "Agile" in the corporate mind. Everything, including SRE and ops work, gets force-fit into Jira "Agile" (really FrAgile) methods and meeting-heavy rituals. But scrum easily devolves to rapid cycle waterfall death marches. This has been going on for at least nine years that I know of. It sucks. When a company says "We do Agile with Scrum" I wince and am very, very skeptical.
  - MikeDelta 5y ago
    And add DevOps to it, because then one can get rid of run == cost savings.
lupire 5y ago
Scrune advocates contributed to the Agile Manifesto, though. They are aligned.
tyingq 5y ago
But the manifesto was written by many of the same people. The expectation that they would be compatible seems reasonable. And, the "Scrum Alliance" happened very shortly after the manifesto.

Scarblac 5y ago

In Scrum, the team should be self-managing. The Product Owner and Scrum Master are not managers or bosses, they're a customer representative and a secretary. I can see that working with "people over process". But then came certification, existing managers et cetera and that was lost.

xondono 5y ago
> In Scrum, the team should be self-managing. The Product Owner and Scrum Master are not managers or bosses, they're a customer representative and a secretary. I can see that working with "people over process". Except those are roles and processes, not people. Putting people before processes and tools means treating people like adults and letting them work how they’re more comfortable.
WJW 5y ago
Many (most?) of the early Agile promoters were owners or partners in a consultancy doing work for clients. These clients often couldn't really specify in enough detail what they needed from the software that was to be built. In that scenario, the structures of Agile make a lot more sense. These days, when a company decides to start using some form of Agile methodology (usually scrum) they need to do something with the people who were previously managing the team and so they often assign them the Product Owner role or something similar. Obviously, the power balance between such a manager (who often retains power over raises and promotions as well) and a line employee team member is completely different than the power balance between a Product Owner as representative of a company and a team of consultants who together own their own consultancy business. Doubly so if the consultants have many more clients and don't exclusively depend on this one Product Owner to pay their bills.
- g051051 5y ago
  > Many (most?) of the early Agile promoters were owners or partners in a consultancy doing work for clients. This is a huge point that people who weren't in the industry back then completely miss: The people behind the Agile manifesto weren't trying to figure out how to improve software development as a whole...they were looking for ways to improve their consulting business. What works for them as consultants selling consulting services doesn't make any sense for a company dev team trying to develop software.

marcus_holmes 5y ago

this. I built a prototype, put it in front of the relevant users, gathered the next set of changes, and... have to wait for the next sprint to implement them (even though they will take about a day, tops) because we can't change a sprint halfway. How is this Agile?

tharkun__ 5y ago
There's nothing preventing you from throwing it into the sprint. But then you gotta exchange it for something else you promised the customer at the start of your sprint. And agile doesn't just mean Scrum and sprints. If your primary way of working is what you described and you are able to get this feedback within hours then Kanban (another agile way of doing things) might suit you better.
globalise83 5y ago
Fine if you are a one-person team working on a small project, but when you have a team of several people doing uncoordinated frontend and backend changes simultaneously, chaos can often ensue. Also a lot of 'urgently needed' changes don't survive the few days until the start of the new sprint, so you would actually waste a lot of time chasing wild geese if you are just jumping straight in every time. Two weeks maximum wait (with a week or less very likely) seems like a reasonable tradeoff to me.

gumby 5y ago

> Being agile means having no long term plan. Bingo, and there lies its power — but only in the correct domain. For consulting, where the customer doesn’t quite understand what they need and you need to work your way forward in an exploratory fashion (and for a limited period) it’s great. And that was the environment it was designed for! You have a multi year engineering project? Really a waterfall, or a waterfall/spiral approach will work. Subtasks handled by a small group can be agile, and that can make the whole thing more efficient, but that need not be the case. A fetish for One True System is simply a cargo cult.

oraphalous 5y ago
> You have a multi year engineering project? Really a waterfall, or a waterfall/spiral approach will work. I'm not sure a long time frame is a necessary condition for a successful waterfall project - but I am certain it is not sufficient. What you need - long term project or not - is a rock solid understanding of business requirements. That means - no vague client demands, or startup style search for product / market fit - but a well established, and documented set of business processes that needs to be mapped to code. I also believe such projects require a leader who has this understanding, but also a talent for product design such that they can recognise and articulate clearly how the product will meet requirements. They need to be able to convince stakeholders. I do think such circumstances are rare for many organisations. But not so rare the prospect should be dismissed out of hand. I agree with your final statement though I think the challenge for many orgs would be in having the self awareness to recognise which approach is best for them.

cmrdporcupine 5y ago

I worked a couple of teams that were using Extreme Programming back in the day (early 2000s) and took a lot of lessons from that. Then in the intervening years I worked on teams that didn't have much of a process at all, and when I came back onto teams that were attempting agile, it was in the form of Scrum, and I just... to me it just doesn't click. It's not the agile I was taught, it's just a formula applied without much thought. Usually just a Pivotal Tracker type system + daily standups, going through the motions. I see no point in it.

endymi0n 5y ago

Fully agree, agile is fine. The real problem is that Scrum is not agile at all: Scrum is a fat "process" that enforces "following a plan" (regular, rigid meeting structure), "creating comprehensive documentation" (user stories, specs, mocks, task board) and "contract negotiation" (estimation meetings, planning poker). In that way, it's the exact opposite of the original agile Manifesto: http://agilemanifesto.org/ http://agilemanifesto.org/ The only thing Scrum has ever been great at (and why it's continually chosen despite proven harmful to development productivity) is that it's great at simulating continuous progress and control to management. Other than that, it's simply fostering architectural mess and a political, dogmatic attitude from and towards everyone. It all starts with a clear product vision from the top and defining how succeeding on it looks like. If you don't know where to go, Scrum will get you there faster and in even more directions at once. Or, to cite one of my all time favorites: "Building intuition on how to make good decisions and cultivating a great relationship with your team will get you 95% of the way there. The plethora of conceptual frameworks for organizing engineering teams won’t make much difference. They make good managers slightly better and bad managers slightly worse." — https://www.defmacro.org/2014/10/03/engman.html https://www.defmacro.org/2014/10/03/engman.html

the_other 5y ago
> The real problem is that Scrum is not agile at all: Scrum is a fat "process" that enforces "following a plan" (regular, rigid meeting structure), "creating comprehensive documentation" (user stories, specs, mocks, task board) and "contract negotiation" (estimation meetings, planning poker). In that way, it's the exact opposite of the original agile Manifesto: None of those things are Scrum. Scrum talks about defining bits of work to do on your product, but doesn’t mention User Stories. (But really, what’s the beef with User Stories? They’re short descriptions of what you hope to achieve! You gotta make some kind of plan sometime or you have no cohesion. If you don’t like the formality of User Stories, drop ‘em). The meeting structures are not defined by Scrum. The intent and topics are defined, but the structure (apart from vague suggestions for rhythm and timing). They only exist on a cadence so you can predict some parts of the system (like ensuring the client turns up to see the work done). You can change most of the details. Scrum doesn’t define any planning or estimation practice, it simply recommends you use some system so that the right people are in sync. You have to know if part A takes an order of magnitude longer to make than part B, so that they can hooked up properly. Specs? Mocks? Task board? None of that is Scrum. Scrum has two lists: the backlog, and the sprint backlog. The former grows as you learn what to make; the latter comes into being at the start of a sprint and disappears at the end. If you must put it in swim-lanes, that’s your loss. Don’t blame Scrum.

watwut 5y ago

> The reason everyone ends up doing waterfall is that it’s not the devs who you need to convince when selling agility Nah, agile is pushed from top to bottom, whether developers want OT or not. > Being agile means having no long term plan. If the C-suite can’t handle that, you’ll never be agile. While the devs are mostly OK with no plan, they do tend to want some planning once it is completely absent. What I see now is developers asking for damm analysis and documentation and C-suite not wanting to pay them. But it is really missing and we are wasting a lot of time due to not knowing the system.

black_13 5y ago
Yeah right on the „no plan“ what c-suite does love is having no plan .

rawgabbit 5y ago

>>> "Being agile means having no long term plan." I believe the angst against agile is it doesn't have a definitive viewpoint but is a reaction against what it sees as the evils of waterfall. Without definite processes, we get scrum. From my viewpoint, the issue is that scrum has a flawed understanding of Toyota Kaizen which it based itself on. Yes, in a Toyota factory, team members are expected to be able to perform any tasks required on the assembly line. But, the architecture Toyota uses, to enable this agility is limiting. For example, Toyota's TNGA architecture says there will only be five modular platforms to choose from; instead of the 100+ choices in the past [1]. Furthermore, Toyota is known for "boring" but reliable cars. It avoids all bleeding edge technology and prefers to make incremental improvements to its existing tech stack. That is to enable interchangeable workers; Toyota limits its car platforms and standardizes "cross cutting concerns". Toyota Kaizen is diametrically opposite of agile in IT. Toyota standardizes, simplifies, and makes incremental changes to its tech stack. Agile in IT means ditching today's platforms/architecture/frameworks/toolsets and jumping on the latest fad du jour. [1] https://en.wikipedia.org/wiki/Toyota_New_Global_Architecture https://en.wikipedia.org/wiki/Toyota_New_Global_Architecture

CoolestBeans 5y ago
The conservative Toyota you're describing is the Toyota that exists today, not the one that developed the Toyota Production System in the first place. Maybe they weren't bleeding edge but their engines had fuel injection, variable valve timing, and were computer controlled. Meanwhile the American automakers' idea of "futuristic" was putting LCD screens in the dash and making the cars talk when you left the door open. Through the 1980s and 1990s Toyota was putting out cars like the original LS 400 which embarrassed the German luxury automakers, the supercharged MR2, the turbocharged Supra, and high revving Celica, all while making cheap but great econoboxes. Its really in the 2000s where Toyota switches to an "only conservative cars" business model when the Toyota developed sports cars disappear, engines start staying mostly the same, and generations get longer.
- namdnay 5y ago
  > Its really in the 2000s where Toyota switches to an "only conservative cars" business model when the Toyota developed sports cars disappear, engines start staying mostly the same, and generations get longer And then 2020s Toyota came out with the GR Yaris, as if to prove that every rule has an exception :)

the_other 5y ago

> The whole thing is about processes, and tools (jira)… the complete opposite. I don’t know how you can read the Scrum guide and get to that comment. JIRA is not Scrum and vice versa. The Scrum system is barely a system: 2 lists; 3 roles; 4 meetings; an exhortation to continually adjust (aiming at improvement); a recommendation you measure; guidance to include the “client” fairly often. That’s about it. This JIRA thing is just one tool among dozens of optional options. Use scraps of paper if it suits you.

dragonwriter 5y ago

> To this day I still don’t understand how one can read the agile manifesto and somehow get to scrum. You don't. I mean, literally, the relationship is inverted: Scrum predates Agile; the creators of the former later went on to contribute to the Agile Manifesto. > Being agile means having no long term plan No, it doesn't.

msoad 5y ago
> No, it doesn't. More like ignoring long term plans when you see something good is in front of you that wasn't planned. Think Slack team working on the video game an noticing their chat app is great...
- dragonwriter 5y ago
  > More like ignoring long term plans when you see something good is in front of you that wasn't planned. I would say more like “long term plans are not high specificity and all plans are subject to rapid adaptation with new information” (though I admit lots of “agile” workflows have no long term plans but extremely rigid short-term plans.)

rodgerd 5y ago

> If the C-suite can’t handle that, you’ll never be agile. My experience is that the problems are typically: 1. Finance. Market targets, multi-year budget projections, "you promised business benefits from project delivery in Q3." Finance teams do not love Agile. 2. Companies who are collections of warring fiefdoms. You need to have an organisation which is mature enough to have reasonable conversations about changing priorites, delivery timelines, and funding in a reasonably dynamic way.

friendzis 5y ago

Scrum tries to sell a set tools, while the originals (Toyota manufacturing system) were methodologies, a set of processes to build those tools. Scrum is a different abstraction layer