6 ms·

To me, Scrum has always been something of a paradox. The whole point of agile is to adapt the process to the team's needs - if you're doing dogmatic agile, you'

by m12k 4y ago

To me, Scrum has always been something of a paradox. The whole point of agile is to adapt the process to the team's needs - if you're doing dogmatic agile, you're not actually doing agile. But what Scrum seems to add on top of the agile manifesto seems to be mainly dogma. I like the term "just-in-time process". A team should have only the processes in exactly the amounts that provide value to the team, and no more. If a daily standup is found to waste people's time, don't do it, or do it less often. If team members are found to need to do more coordination, maybe other avenues of communication could be encouraged?

tomohawk 4y ago
I was trained by the originator of scrum. In the training, this was repeatedly stated as one of the main dangers to avoid. What I got out of it is that scrum is a model, and it is up to a team to iteratively figure out how to apply that model to their situation. It gives a team a framework to manage change. For example, the scrum model talks about a product owner. The cargo cultists insist that this needs to be a single person, with title of Product Owner. Yeech! The reality is that the product owner could be a single person, or could model an entire organization that is developing requirements. What the scrum team needs is for these requirements to be made known to them in an orderly manner, and enough autonomy to have a reasonable discussion about them (how realistic they are, the cost, etc). I've seen a lot of cargo cult scrum failures, and I've seen a lot of actual scrum successes. Over time, the cargo cultists have become the majority, though. That is a shame.
kkfx 4y ago
IMVHO the whole point is that someone have badly misunderstood Toyoda method and have hoped we can do creative work like an industrial production in the assembly line, so someone have adapted assembly line methods from '900 mechanical industry to modern IT and made much of the mess we see around with crap layered on crap layered on other crap and no one have a clue of what's up in general. That's is. SCRUM is an emergency mode operation technique that might work to sort out standard things, definitively not creating something new.
aryehof 4y ago
> The whole point of agile is to adapt the process to the team's needs I would argue that’s not the point at all. Instead I would argue that its point is short iterative simple process development based on constant stakeholder feedback. I suggest that many undertaking “Scrum” are simply kidding themselves that their modern day process focussed development is “agile” at all. Heavy process iterative development preceded the “agile” movement and is back under a new name… “Scrum”.
adrianmsmith 4y ago
> To me, Scrum has always been something of a paradox. The whole point of agile is to adapt the process to the team's needs - if you're doing dogmatic agile, you're not actually doing agile. It seems to me that Scrum has "no true Scotsman" built right in to the model. If you criticize it, a Scrum practitioner can just reply "well, just adapt it to your needs then". Or if you hear of something too crazy a team is doing with Scrum because they adapted "well, they're not doing Scrum right".
- synu 4y ago
  They called it “scrum but”
deanCommie 4y ago
In an age where tech workers have massive autonomy and respect, it might be difficult to remember WHY the original Agile manifesto was written. Sure it talks about delivery, working software, and the like. But a big motivator wasn't just "Craftsmen who want to do their craft more effectively", it was "Employees who are being abused by project managers, Gantt charts, and top-down waterfall death marches, who want to have sanity" The part of 2-week sprints that says "deliver working software at the end" is just as important as the part that says "PMs can't introduce new scope into the sprint". So the reality is It Depends on the company. If you're lucky enough to be in a place where you have full control over your process to deliver software, Bottoms Up, Just-In-Time Process is the perfect attitude. But if management is enforcing archaic practices for no seemingly clear reason, the "rigid" nature of Scrum actually helps enforce a good way of doing things in a way that "traditional" management can reason about.
- Arcanum-XIII 4y ago
  And now we’re abused by velocity chart, retrospective about our failings, continuous change because we’re agile, under pressure all the time because of the two weeks « sprint » which end being a disguised death march… So how is it any better?
  - icedchai 4y ago
    I worked at a place where the managers did everything they could to close out all the points by end of sprint, no matter what. A co-worker is taking longer than expected, says there is no way he'll be done in couple of days... so we close out his story, declare it done, and open a new one in the next sprint for "testing", "deployment", or whatever it takes to claim the points and move something into the next sprint. I found this truly sad. If you want accurate "velocity", you need to track it accurately. Our estimates were wrong.
    - Too 4y ago
      Seen exactly the same, sadly not just in one shop. Half completed stories would be split into part 1,2,3, or worse: renamed to "Attempt to implement...", just to make the burndown chart align at closure of sprint and give people the pleasure of dragging items to the done-column. Didn't get better when some higher up scrum master once had the brilliant idea that all stories should be max 2 story point large, otherwise need to be refined further. Together with a company-wide policy that a story point is roughly equal to one day, for all teams, because it made the high level jira dashboards easier to aggregate. Not sure what it was meant for, since with this practice it would tautologically just show headcount * days in a sprint. More like time reporting rather than measure of progress.
synu 4y ago
The Kanban book by David Anderson was all about this, but it never caught on like Scrum did. If I’m feeling cynical I think its because there were no certifications to charge for and no strange new roles for middle managers.
- Silhouette 4y ago
  That is unfortunate indeed. The basic idea that you can run a software team by collecting a set of useful and moderately sized projects to do and then picking the most important ones to do first is reasonable enough. It's the extra process that goes way too far, full of formulaic time-wasting meetings and participants whose roles need silly names because no-one can explain or justify them on merit alone. But it's hard to sell tickets to a conference where the keynote speech is five minutes long and the same as last year.
- cupofpython 4y ago
  i dont think that is cynicism. ideas need to be commodified for corporate use or else HR / recruiting does not know what to do with it.
  - avs733 4y ago
    it has nothing to do with corporate use, it has to do with human use. Deep understanding of ideology just doesn't scale. You can look at any topic in nearly any field and the majority of users will reduce it to a set of heuristics and simple actions rather than understanding the foundational ideas from the most basic principles and building up to the why of actions - and then undertaking them within the an authentic respect for those principles. Dealing with anything social, the rules don't self enforce - they aren't gravity.
- jacobr1 4y ago
  We tried kanban with a few teams at my last startup. It worked great for a team with a clear direction, but was really hard from a management/planning/accountability standpoint. It didn't mesh well with the quarterly planning cycle the rest of the company aligned on. So we took some of the key tools (like WIP limits) but otherwise moved to scrumban type process. It was a bummer, because we had some solid data on increased productivity, but couldn't really deliver increased predictability (not that scrum was more predictable in-practice, it just seems that way)
mxuribe 4y ago
I see it similarly! A team should leverage only what helps it, and no more. In fact, i have quoted to teams (that are thinking how to adopt agile, scrum, whatever) some lines from Bruce Lee's Jeet Kune Do: "...I hope to free my followers from clinging to styles, patterns, or molds. Remember that Jeet Kune Do is merely a name used, a mirror in which to see "ourselves"...Jeet Kune Do is not an organized institution that one can be a member of...Again let me remind you Jeet Kune Do is just a name used, a boat to get one across, and once across it is to be discarded and not to be carried on one's back..." Some teams get it, while others just follow what a paid consultant suggested (based on tech zeitgeist).
myth2018 4y ago
The biggest problem is not in Agile itself, but indeed in the dogmatism of its practitioners. I believe that stems from the fact that agile methods became too "productized": there's a whole market of books, lectures, certifications, courses etc and lots of people willing to profit from it. Eventually it became a sort of a religion. If you question it, it's because you don't understand it; if it yields bad results, it's because you did it wrong; if it doesn't fit the dynamics of the rest of the company, it's because the company is immature. All the methods have known limitations and prerequisites. All but Agile, which is perfect. It's a ridiculous lack of empiricism for a discipline like software engineering.
- capableweb 4y ago
  Most of the consultants/junior developers/managers and others who try to shoehorn "agile" into every process and team doesn't seem to have actually read the original "agile manifesto", which is: > Individuals and interactions over processes and tools > Working software over comprehensive documentation > Customer collaboration over contract negotiation > Responding to change over following a plan
  - xg15 4y ago
    But couldn't this "ossification" of agile be a sign that the manifesto is actually wrong? A lot of the criticism seems to form around the fact that people actually develop processes around agile, even though agile discourages processes. (And that those processes in the end become empty rituals that hinder development more than support it) But couldn't this actually be a sign that people in fact need processes to get some kind of routine and system into their work?
  - myth2018 4y ago
    I agree with you. But even the Manifesto has some points that make it impractical in many circumstances. To stick with a single example: is it safe to favor customer collaboration over contract negotiation when dealing with high budget projects? Changes in requirements, delays, reprioritizing in client's side, those are all things we know that may happen. How are we going to deal with them after you favored customer collaboration, and that collaboration doesn't exist anymore? Agile requires Trust. But trust is a fluid thing, and we must cope with its fluctuations. The client is cooperating? Good, let's get a bit liberal about some rules, but let's keep monitoring the situation. The team is mature enough to self-manage? Good, let the team manage itself, but keep an eye to see if things are still running smoothly as the time goes by. The biggest problem of Agile is that it takes Trust for granted and assumes that every single stakeholder wants the project to succeed, and shares the exact same definition of success.
Jenk 4y ago
One near constant thing I notice is that hardly anyone (_especially_ scrum certified folk) recognises that scrum, by design, makes it self redundant. Most think scrum is a final-state. A goal line. It's not. Scrum is a training/introductory agile framework. There is an evolution to scrum built right into the framework that transforms it into not-scrum. The framework encourages moving from the initial (and what most orgs think is the final state of scrum) "Type A" where the team work in isolated timeboxes, with downtime between for planning etc. through "Type B" with preparation(s) for upcoming sprints, and feedback from previous sprints, overlapping the current sprint, to "Type C" with complete "just-in-time process" transformation where doing any given ceremony is done on-demand. And, crucially, it encourages evolving _beyond_ this. Type C will be familiar to anyone practicing Kanban. Or dare I say, anyone with experience with "doing agile right" will have an experience matching what Type C describes.
- civilized 4y ago
  This helps me understand why this widely reviled thing, Scrum, might be useful. It separates planning and execution and tells you to do one at a time. Maybe that's useful for teams that are struggling to adaptively interweave the two. And maybe by mastering them separately, they could get a step closer to juggling them together.
  - cuddlybacon 4y ago
    When I started my career, most teams at my company were doing waterfall. The team I was hired onto was one of a couple guinea pigs for scrum. The other teams would spend 6 weeks doing nothing but planning activities. After the planning was done, they'd do a 12 month dev cycle. Once that was done they would throw what they have over the fence for the QA cycle. That is the world scrum was introduced to. People already thought planning and separate and couldn't be mixed. Scrum dragged them closer to interweaving them. People resisted, saying it was reckless and unprofessional. They looked at this and thought "so the plan is we don't plan anymore? we just wing it?". I think Agile has won enough that perhaps many specific processes meant to bridge the gap are now dragging people away from being more Agile.
ignoramous 4y ago
> ...team should have only the processes in exactly the amounts that provide value to the team, and no more. It is interesting to go to the origins of scrum and its emphasis on the team and team-work for high-quality, low-cost product development. > ...companies in Japan and the United States are using a holistic method — as in rugby, the ball gets passed within the team as it moves as a unit up the field. This holistic approach has six characteristics: built-in instability, self-organizing project teams, overlapping development phases, 'multilearning,' subtle control, and organizational transfer of learning. The six pieces fit together like a jigsaw puzzle, forming a fast flexible process for new product development. A radical scruffy setup that challenges both the status quo and the leadership of an org rather than confirm to any set processes and workflows. https://hbr.org/2016/04/the-secret-history-of-agile-innovation https://hbr.org/2016/04/the-secret-history-of-agile-innovati... --- Some more snipped excerpts: > ...under the new approach (in its extreme form) nonexperts undertake product development. They are encouraged to acquire the necessary knowledge and skills on the job. Unlike the experts, who cannot tolerate mistakes even 1% of the time, the nonexperts are willing to challenge the status quo. But to do so, they must accumulate knowledge from across all areas of management, across different levels of the organization, functional specializations, and even organizational boundaries. Such learning in breadth serves as the necessary condition for shared division of labor to function effectively. > A project team consisting of members with varying functional specializations, thought processes, and behavior patterns carries out new product development. While selecting a diverse team is crucial, it isn’t until the members start to interact that cross-fertilization actually takes place. > Selecting the right people for the project team while monitoring shifts in group dynamics and adding or dropping members when necessary. Creating an open work environment. Encouraging engineers to go out into the field and listen to what customers and dealers have to say. Establishing an evaluation and reward system based on group performance. Managing the differences in rhythm throughout the development process. Tolerating and anticipating mistakes. Encouraging suppliers to become self-organizing. Involving them early during design is a step in the right direction. But the project team should refrain from telling suppliers what to do. > Headquarters' involvement is limited to providing guidance, money, and moral support at the outset. On a day-to-day basis, top management seldom intervenes; the team is free to set its own direction. In a way, top management acts as a venture capitalist. Or as one executive said, 'We open up our purse but keep our mouth closed.' > Top management kicks off the development process by signaling a broad goal or a general strategic direction. It rarely hands out a clear-cut new product concept or a specific work plan. > Starting with the guidelines set forth by top management, [the team begins] to establish their own goals and keep on elevating them throughout the development process. By pursuing what appear at first to be contradictory goals, they devise ways to override the status quo and make the big discovery.
apocalyptic0n3 4y ago
> The whole point of agile is to adapt the process to the team's needs - if you're doing dogmatic agile, you're not actually doing agile. But what Scrum seems to add on top of the agile manifesto seems to be mainly dogma. I oversee (i.e. just making sure they're running well and on schedule) a bunch of different project teams and this is a frequent debate I have with the leads on those projects. If x and y is working for you, but z isn't, why don't you meet with your team and adjust z to make it work with the project and, more specifically, your personnel better? The response is almost always "But then it's not Scrum." They get in this mindset that if they don't follow the Scrum workflow to a T, then they're failing as leaders. That the workflow should be a rock that you beat your team against until they conform to it. It's a struggle backing them down from that edge and convincing them that Scrum doesn't work in all (many) cases, but a few minor tweaks to it will make your team function more effectively pretty easily. A lot of them struggle to accept that the "few minor tweaks" is always different between projects and teams, too. Retros are essential for running an effective agile workflow, whether it be Scrum, Kanban, near-Scrum, or something else. You need to take a step back, view the process from the outside with your team, and figure out how to more effectively function going forward. Trying to appease the Scrum gods or your manager by adhering to every single character of Scrum as if it is scripture doesn't make any project better, in my opinion. Everything has to be flexible to some extent, including you, your team, and your processes.
- andrekandre 4y ago
  > Retros are essential for running an effective agile workflow retros are very difficult to get right: many issues brought up cant be fixed by those attending (company policies, group okrs, platform issues, immovable deadlines etc), so the result many times is either self-flagellation or "improvement plans" that don't go anywhere... the end result being even more demotivating for a team.... if retros arent going to be effective at real improvement, then its better not to do them imo* *there are other ways to improve teamwork/processes anyways
  - bluGill 4y ago
    My team always puts a 'general complainy pants' column on our retros so we can acknowledge things we have no control over and move to things we can.
rmrk 4y ago
in 5 years we'll see the posts titled "Just-In-Time Process is awful, terrible and inflexible"

by m12k 4y ago

tomohawk 4y ago

I was trained by the originator of scrum. In the training, this was repeatedly stated as one of the main dangers to avoid. What I got out of it is that scrum is a model, and it is up to a team to iteratively figure out how to apply that model to their situation. It gives a team a framework to manage change. For example, the scrum model talks about a product owner. The cargo cultists insist that this needs to be a single person, with title of Product Owner. Yeech! The reality is that the product owner could be a single person, or could model an entire organization that is developing requirements. What the scrum team needs is for these requirements to be made known to them in an orderly manner, and enough autonomy to have a reasonable discussion about them (how realistic they are, the cost, etc). I've seen a lot of cargo cult scrum failures, and I've seen a lot of actual scrum successes. Over time, the cargo cultists have become the majority, though. That is a shame.

kkfx 4y ago

IMVHO the whole point is that someone have badly misunderstood Toyoda method and have hoped we can do creative work like an industrial production in the assembly line, so someone have adapted assembly line methods from '900 mechanical industry to modern IT and made much of the mess we see around with crap layered on crap layered on other crap and no one have a clue of what's up in general. That's is. SCRUM is an emergency mode operation technique that might work to sort out standard things, definitively not creating something new.

aryehof 4y ago

> The whole point of agile is to adapt the process to the team's needs I would argue that’s not the point at all. Instead I would argue that its point is short iterative simple process development based on constant stakeholder feedback. I suggest that many undertaking “Scrum” are simply kidding themselves that their modern day process focussed development is “agile” at all. Heavy process iterative development preceded the “agile” movement and is back under a new name… “Scrum”.

adrianmsmith 4y ago

> To me, Scrum has always been something of a paradox. The whole point of agile is to adapt the process to the team's needs - if you're doing dogmatic agile, you're not actually doing agile. It seems to me that Scrum has "no true Scotsman" built right in to the model. If you criticize it, a Scrum practitioner can just reply "well, just adapt it to your needs then". Or if you hear of something too crazy a team is doing with Scrum because they adapted "well, they're not doing Scrum right".

synu 4y ago
They called it “scrum but”

deanCommie 4y ago

In an age where tech workers have massive autonomy and respect, it might be difficult to remember WHY the original Agile manifesto was written. Sure it talks about delivery, working software, and the like. But a big motivator wasn't just "Craftsmen who want to do their craft more effectively", it was "Employees who are being abused by project managers, Gantt charts, and top-down waterfall death marches, who want to have sanity" The part of 2-week sprints that says "deliver working software at the end" is just as important as the part that says "PMs can't introduce new scope into the sprint". So the reality is It Depends on the company. If you're lucky enough to be in a place where you have full control over your process to deliver software, Bottoms Up, Just-In-Time Process is the perfect attitude. But if management is enforcing archaic practices for no seemingly clear reason, the "rigid" nature of Scrum actually helps enforce a good way of doing things in a way that "traditional" management can reason about.

Arcanum-XIII 4y ago
And now we’re abused by velocity chart, retrospective about our failings, continuous change because we’re agile, under pressure all the time because of the two weeks « sprint » which end being a disguised death march… So how is it any better?
- icedchai 4y ago
  I worked at a place where the managers did everything they could to close out all the points by end of sprint, no matter what. A co-worker is taking longer than expected, says there is no way he'll be done in couple of days... so we close out his story, declare it done, and open a new one in the next sprint for "testing", "deployment", or whatever it takes to claim the points and move something into the next sprint. I found this truly sad. If you want accurate "velocity", you need to track it accurately. Our estimates were wrong.
  - Too 4y ago
    Seen exactly the same, sadly not just in one shop. Half completed stories would be split into part 1,2,3, or worse: renamed to "Attempt to implement...", just to make the burndown chart align at closure of sprint and give people the pleasure of dragging items to the done-column. Didn't get better when some higher up scrum master once had the brilliant idea that all stories should be max 2 story point large, otherwise need to be refined further. Together with a company-wide policy that a story point is roughly equal to one day, for all teams, because it made the high level jira dashboards easier to aggregate. Not sure what it was meant for, since with this practice it would tautologically just show headcount * days in a sprint. More like time reporting rather than measure of progress.

synu 4y ago

The Kanban book by David Anderson was all about this, but it never caught on like Scrum did. If I’m feeling cynical I think its because there were no certifications to charge for and no strange new roles for middle managers.

Silhouette 4y ago
That is unfortunate indeed. The basic idea that you can run a software team by collecting a set of useful and moderately sized projects to do and then picking the most important ones to do first is reasonable enough. It's the extra process that goes way too far, full of formulaic time-wasting meetings and participants whose roles need silly names because no-one can explain or justify them on merit alone. But it's hard to sell tickets to a conference where the keynote speech is five minutes long and the same as last year.
cupofpython 4y ago
i dont think that is cynicism. ideas need to be commodified for corporate use or else HR / recruiting does not know what to do with it.
- avs733 4y ago
  it has nothing to do with corporate use, it has to do with human use. Deep understanding of ideology just doesn't scale. You can look at any topic in nearly any field and the majority of users will reduce it to a set of heuristics and simple actions rather than understanding the foundational ideas from the most basic principles and building up to the why of actions - and then undertaking them within the an authentic respect for those principles. Dealing with anything social, the rules don't self enforce - they aren't gravity.
jacobr1 4y ago
We tried kanban with a few teams at my last startup. It worked great for a team with a clear direction, but was really hard from a management/planning/accountability standpoint. It didn't mesh well with the quarterly planning cycle the rest of the company aligned on. So we took some of the key tools (like WIP limits) but otherwise moved to scrumban type process. It was a bummer, because we had some solid data on increased productivity, but couldn't really deliver increased predictability (not that scrum was more predictable in-practice, it just seems that way)

mxuribe 4y ago

I see it similarly! A team should leverage only what helps it, and no more. In fact, i have quoted to teams (that are thinking how to adopt agile, scrum, whatever) some lines from Bruce Lee's Jeet Kune Do: "...I hope to free my followers from clinging to styles, patterns, or molds. Remember that Jeet Kune Do is merely a name used, a mirror in which to see "ourselves"...Jeet Kune Do is not an organized institution that one can be a member of...Again let me remind you Jeet Kune Do is just a name used, a boat to get one across, and once across it is to be discarded and not to be carried on one's back..." Some teams get it, while others just follow what a paid consultant suggested (based on tech zeitgeist).

myth2018 4y ago

The biggest problem is not in Agile itself, but indeed in the dogmatism of its practitioners. I believe that stems from the fact that agile methods became too "productized": there's a whole market of books, lectures, certifications, courses etc and lots of people willing to profit from it. Eventually it became a sort of a religion. If you question it, it's because you don't understand it; if it yields bad results, it's because you did it wrong; if it doesn't fit the dynamics of the rest of the company, it's because the company is immature. All the methods have known limitations and prerequisites. All but Agile, which is perfect. It's a ridiculous lack of empiricism for a discipline like software engineering.

capableweb 4y ago
Most of the consultants/junior developers/managers and others who try to shoehorn "agile" into every process and team doesn't seem to have actually read the original "agile manifesto", which is: > Individuals and interactions over processes and tools > Working software over comprehensive documentation > Customer collaboration over contract negotiation > Responding to change over following a plan
- xg15 4y ago
  But couldn't this "ossification" of agile be a sign that the manifesto is actually wrong? A lot of the criticism seems to form around the fact that people actually develop processes around agile, even though agile discourages processes. (And that those processes in the end become empty rituals that hinder development more than support it) But couldn't this actually be a sign that people in fact need processes to get some kind of routine and system into their work?
- myth2018 4y ago
  I agree with you. But even the Manifesto has some points that make it impractical in many circumstances. To stick with a single example: is it safe to favor customer collaboration over contract negotiation when dealing with high budget projects? Changes in requirements, delays, reprioritizing in client's side, those are all things we know that may happen. How are we going to deal with them after you favored customer collaboration, and that collaboration doesn't exist anymore? Agile requires Trust. But trust is a fluid thing, and we must cope with its fluctuations. The client is cooperating? Good, let's get a bit liberal about some rules, but let's keep monitoring the situation. The team is mature enough to self-manage? Good, let the team manage itself, but keep an eye to see if things are still running smoothly as the time goes by. The biggest problem of Agile is that it takes Trust for granted and assumes that every single stakeholder wants the project to succeed, and shares the exact same definition of success.

Jenk 4y ago

One near constant thing I notice is that hardly anyone (_especially_ scrum certified folk) recognises that scrum, by design, makes it self redundant. Most think scrum is a final-state. A goal line. It's not. Scrum is a training/introductory agile framework. There is an evolution to scrum built right into the framework that transforms it into not-scrum. The framework encourages moving from the initial (and what most orgs think is the final state of scrum) "Type A" where the team work in isolated timeboxes, with downtime between for planning etc. through "Type B" with preparation(s) for upcoming sprints, and feedback from previous sprints, overlapping the current sprint, to "Type C" with complete "just-in-time process" transformation where doing any given ceremony is done on-demand. And, crucially, it encourages evolving _beyond_ this. Type C will be familiar to anyone practicing Kanban. Or dare I say, anyone with experience with "doing agile right" will have an experience matching what Type C describes.

civilized 4y ago
This helps me understand why this widely reviled thing, Scrum, might be useful. It separates planning and execution and tells you to do one at a time. Maybe that's useful for teams that are struggling to adaptively interweave the two. And maybe by mastering them separately, they could get a step closer to juggling them together.
- cuddlybacon 4y ago
  When I started my career, most teams at my company were doing waterfall. The team I was hired onto was one of a couple guinea pigs for scrum. The other teams would spend 6 weeks doing nothing but planning activities. After the planning was done, they'd do a 12 month dev cycle. Once that was done they would throw what they have over the fence for the QA cycle. That is the world scrum was introduced to. People already thought planning and separate and couldn't be mixed. Scrum dragged them closer to interweaving them. People resisted, saying it was reckless and unprofessional. They looked at this and thought "so the plan is we don't plan anymore? we just wing it?". I think Agile has won enough that perhaps many specific processes meant to bridge the gap are now dragging people away from being more Agile.

ignoramous 4y ago

> ...team should have only the processes in exactly the amounts that provide value to the team, and no more. It is interesting to go to the origins of scrum and its emphasis on the team and team-work for high-quality, low-cost product development. > ...companies in Japan and the United States are using a holistic method — as in rugby, the ball gets passed within the team as it moves as a unit up the field. This holistic approach has six characteristics: built-in instability, self-organizing project teams, overlapping development phases, 'multilearning,' subtle control, and organizational transfer of learning. The six pieces fit together like a jigsaw puzzle, forming a fast flexible process for new product development. A radical scruffy setup that challenges both the status quo and the leadership of an org rather than confirm to any set processes and workflows. https://hbr.org/2016/04/the-secret-history-of-agile-innovation https://hbr.org/2016/04/the-secret-history-of-agile-innovati... --- Some more snipped excerpts: > ...under the new approach (in its extreme form) nonexperts undertake product development. They are encouraged to acquire the necessary knowledge and skills on the job. Unlike the experts, who cannot tolerate mistakes even 1% of the time, the nonexperts are willing to challenge the status quo. But to do so, they must accumulate knowledge from across all areas of management, across different levels of the organization, functional specializations, and even organizational boundaries. Such learning in breadth serves as the necessary condition for shared division of labor to function effectively. > A project team consisting of members with varying functional specializations, thought processes, and behavior patterns carries out new product development. While selecting a diverse team is crucial, it isn’t until the members start to interact that cross-fertilization actually takes place. > Selecting the right people for the project team while monitoring shifts in group dynamics and adding or dropping members when necessary. Creating an open work environment. Encouraging engineers to go out into the field and listen to what customers and dealers have to say. Establishing an evaluation and reward system based on group performance. Managing the differences in rhythm throughout the development process. Tolerating and anticipating mistakes. Encouraging suppliers to become self-organizing. Involving them early during design is a step in the right direction. But the project team should refrain from telling suppliers what to do. > Headquarters' involvement is limited to providing guidance, money, and moral support at the outset. On a day-to-day basis, top management seldom intervenes; the team is free to set its own direction. In a way, top management acts as a venture capitalist. Or as one executive said, 'We open up our purse but keep our mouth closed.' > Top management kicks off the development process by signaling a broad goal or a general strategic direction. It rarely hands out a clear-cut new product concept or a specific work plan. > Starting with the guidelines set forth by top management, [the team begins] to establish their own goals and keep on elevating them throughout the development process. By pursuing what appear at first to be contradictory goals, they devise ways to override the status quo and make the big discovery.

apocalyptic0n3 4y ago

> The whole point of agile is to adapt the process to the team's needs - if you're doing dogmatic agile, you're not actually doing agile. But what Scrum seems to add on top of the agile manifesto seems to be mainly dogma. I oversee (i.e. just making sure they're running well and on schedule) a bunch of different project teams and this is a frequent debate I have with the leads on those projects. If x and y is working for you, but z isn't, why don't you meet with your team and adjust z to make it work with the project and, more specifically, your personnel better? The response is almost always "But then it's not Scrum." They get in this mindset that if they don't follow the Scrum workflow to a T, then they're failing as leaders. That the workflow should be a rock that you beat your team against until they conform to it. It's a struggle backing them down from that edge and convincing them that Scrum doesn't work in all (many) cases, but a few minor tweaks to it will make your team function more effectively pretty easily. A lot of them struggle to accept that the "few minor tweaks" is always different between projects and teams, too. Retros are essential for running an effective agile workflow, whether it be Scrum, Kanban, near-Scrum, or something else. You need to take a step back, view the process from the outside with your team, and figure out how to more effectively function going forward. Trying to appease the Scrum gods or your manager by adhering to every single character of Scrum as if it is scripture doesn't make any project better, in my opinion. Everything has to be flexible to some extent, including you, your team, and your processes.

andrekandre 4y ago
> Retros are essential for running an effective agile workflow retros are very difficult to get right: many issues brought up cant be fixed by those attending (company policies, group okrs, platform issues, immovable deadlines etc), so the result many times is either self-flagellation or "improvement plans" that don't go anywhere... the end result being even more demotivating for a team.... if retros arent going to be effective at real improvement, then its better not to do them imo* *there are other ways to improve teamwork/processes anyways
- bluGill 4y ago
  My team always puts a 'general complainy pants' column on our retros so we can acknowledge things we have no control over and move to things we can.

rmrk 4y ago

in 5 years we'll see the posts titled "Just-In-Time Process is awful, terrible and inflexible"