The age of Scrum is over(chrisjameslennon.medium.com)
chrisjameslennon.medium.com
The age of Scrum is over
https://chrisjameslennon.medium.com/the-age-of-scrum-is-over-185407ad705b
221 comments
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.
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.
> The biggest problem is not in Agile itself, but indeed in the dogmatism of its practitioners.
I feel that most people don't understand that larger corporations don't adopt Agile to benefit product teams, but to add a layer of measurability to the process that is only useful for middle and upper management to establish and track OKRs.
Thus Agile may not be a failed idea, but it arguably fails at the implementation.
Agile apologists seem to be disconnected from this reality.
I feel that most people don't understand that larger corporations don't adopt Agile to benefit product teams, but to add a layer of measurability to the process that is only useful for middle and upper management to establish and track OKRs.
Thus Agile may not be a failed idea, but it arguably fails at the implementation.
Agile apologists seem to be disconnected from this reality.
Totally agree. All these teams down in the weeds are obsessed with following the rituals to a tee thinking that makes them good little devs. When the whole point is so the middle and upper managements can track your activity to the minute and judge your performance.
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
> Individuals and interactions over processes and tools
> Working software over comprehensive documentation
> Customer collaboration over contract negotiation
> Responding to change over following a plan
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.
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.
> To stick with a single example: is it safe to favor customer collaboration over contract negotiation when dealing with high budget projects?
Yes, but note that the client is inside the circle, not an external force, in Agile.
> Changes in requirements, delays, reprioritizing in client's side, those are all things we know that may happen.
Yes, that is specifically what the point deals with, on both sides. Favoring contract negotiation over collaboration is a very poor way of dealing with those things.
(The X over Y statements in the Manifesto are not X instead of Y, but Y must be centered on supporting X; contract negotiation is necessary, but the terms must be framed to support collaboration rather than impede it by being inflexible for the kinds of things that are known to be likely to change over the time of the project development.)
> How are we going to deal with them after you favored customer collaboration, and that collaboration doesn't exist anymore?
If the need for collaboration was centered in contract negotiation, then that will be addressed.
> The biggest problem of Agile is that it takes Trust for granted
The biggest problem (though far from only) problem of Agile is that the authors of the Manifesto underestimated the degree to which people would misread “over” as “instead of”, even given an explicit admonition that that reading was incorrect, making the Manifesto terse and catchy, but ineffective in communicating it's core ideas.
Yes, but note that the client is inside the circle, not an external force, in Agile.
> Changes in requirements, delays, reprioritizing in client's side, those are all things we know that may happen.
Yes, that is specifically what the point deals with, on both sides. Favoring contract negotiation over collaboration is a very poor way of dealing with those things.
(The X over Y statements in the Manifesto are not X instead of Y, but Y must be centered on supporting X; contract negotiation is necessary, but the terms must be framed to support collaboration rather than impede it by being inflexible for the kinds of things that are known to be likely to change over the time of the project development.)
> How are we going to deal with them after you favored customer collaboration, and that collaboration doesn't exist anymore?
If the need for collaboration was centered in contract negotiation, then that will be addressed.
> The biggest problem of Agile is that it takes Trust for granted
The biggest problem (though far from only) problem of Agile is that the authors of the Manifesto underestimated the degree to which people would misread “over” as “instead of”, even given an explicit admonition that that reading was incorrect, making the Manifesto terse and catchy, but ineffective in communicating it's core ideas.
> Yes, but note that the client is inside the circle, not an external force, in Agile
Indeed, and this is one of the points Agile gets furthest from real world.
Anecdote: I've worked for an average-sized bank with users who were cooperative but not that much. One day we were faced by an urgent legal requirement and the bank had to choose: either to halt operations or to adapt the software, otherwise our equivalent of a CFO would be arrested. The customer became an integral part of the team, we had extremely fast iterations and that was my first Agile project, and I didn't know it because I was going to hear first time about Agile only three years after that.
As soon as the legal requirement was met, things got back to normal.
That's what I talk about methodologies having to subject themselves to the environment. Agilists seem to dream about inverting things in this regard.
> The biggest problem (though far from only) problem of Agile is that the authors of the Manifesto underestimated the degree to which people would misread “over” as “instead of”, even given an explicit admonition that that reading was incorrect, making the Manifesto terse and catchy, but ineffective in communicating it's core ideas
I agree, but even avoiding the "instead of" interpretation, I believe the ideas in the Manifesto are only actionable under special conditions.
Each project is a different case and demands a different combination of agile/non-agile variables, it all depends on the environment it presents (customer behavior, team's maturity, project complexity etc)
Indeed, and this is one of the points Agile gets furthest from real world.
Anecdote: I've worked for an average-sized bank with users who were cooperative but not that much. One day we were faced by an urgent legal requirement and the bank had to choose: either to halt operations or to adapt the software, otherwise our equivalent of a CFO would be arrested. The customer became an integral part of the team, we had extremely fast iterations and that was my first Agile project, and I didn't know it because I was going to hear first time about Agile only three years after that.
As soon as the legal requirement was met, things got back to normal.
That's what I talk about methodologies having to subject themselves to the environment. Agilists seem to dream about inverting things in this regard.
> The biggest problem (though far from only) problem of Agile is that the authors of the Manifesto underestimated the degree to which people would misread “over” as “instead of”, even given an explicit admonition that that reading was incorrect, making the Manifesto terse and catchy, but ineffective in communicating it's core ideas
I agree, but even avoiding the "instead of" interpretation, I believe the ideas in the Manifesto are only actionable under special conditions.
Each project is a different case and demands a different combination of agile/non-agile variables, it all depends on the environment it presents (customer behavior, team's maturity, project complexity etc)
> Indeed, and this is one of the points Agile gets furthest from real world.
It's one of the parts the Manifesto gets most right about the real world.
> That's what I talk about methodologies having to subject themselves to the environment. Agilists seem to dream about inverting things in this regard.
I don't know “Agilists” in any general sense, I do know that adapting methodology to the specific (and shifting over time on a single project/product) combination of team, context, and task is the central focus of the Agile Manifesto.
It's one of the parts the Manifesto gets most right about the real world.
> That's what I talk about methodologies having to subject themselves to the environment. Agilists seem to dream about inverting things in this regard.
I don't know “Agilists” in any general sense, I do know that adapting methodology to the specific (and shifting over time on a single project/product) combination of team, context, and task is the central focus of the Agile Manifesto.
If you don’t protect yourself with a contract, another party will screw you 11 times out of 10.
By all means collaborate, but put it in a contract too.
By all means collaborate, but put it in a contract too.
One of the subtleties is how to determine acceptance criteria by the stakeholders/client. You can negotiate upfront a spec, and upon delivery conformance to the spec means success. Or you could negotiate a high-level objective, or a metric to be changed, and every sprint get an on-the-fly approval of the incremental changes delivered.
The key is understanding the upfront spec, while a necessary stating point, is almost certainly wrong, maybe fundamentally so. So how are renegotiations handled?
The key is understanding the upfront spec, while a necessary stating point, is almost certainly wrong, maybe fundamentally so. So how are renegotiations handled?
These are good points, but trust is not a prerequisite only for Agile. IMHO all large-scale software projects require trust to create space for the team to figure out the right path. If trust is lacking, it needs to be established, but the actions and steps that need to be taken are highly contextual and outside the scope of the Agile Manifesto.
I agree it's needed and it must be established if lacking, but 1) sometimes it's too unstable and you need institutional devices to counterbalance, but such devices are dismissed as useless bureaucracy in agile ideology and 2) agile seems to assume an idyllic world in which trust is established a priori and can be safely taken for granted
> consultants/junior developers/managers and others who try to shoehorn "agile" into every process and team
This is in itself a major point. Managers trying to put scrum on everything. This is my main hope for scrum passing away. I have seen it now several times companies deciding to use scrum for research projects, and after a year they all realize how bad of an idea that is.
On the other hand so far I haven't worked for a single company that actually did scrum (despite claiming it). They all started by "adjusting the process" and removing the scrum master. Sure. You totally understood how this works.
This is in itself a major point. Managers trying to put scrum on everything. This is my main hope for scrum passing away. I have seen it now several times companies deciding to use scrum for research projects, and after a year they all realize how bad of an idea that is.
On the other hand so far I haven't worked for a single company that actually did scrum (despite claiming it). They all started by "adjusting the process" and removing the scrum master. Sure. You totally understood how this works.
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?
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?
Rather than becoming this over time, Scrum slotted into existing teams and practices that were already heavily into rigid project management. The same teams that adopted Scrum were previously using Waterfall or 6-Sigma or some other such prescriptive framework. Agile showed up, got a lot of buzz, and then Scrum came along to sell the buzz to big institutions with entire departments of professional project managers.
Were the creators of Scrum hopefully trying to introduce flexibility in the guise of process, or cynically cashing in on a trend? I don't know; all I do know is that Big Software switched from $old_process to Scrum around 2010-2012, and medium-sized companies seemed to follow in the middle of the decade.
Were the creators of Scrum hopefully trying to introduce flexibility in the guise of process, or cynically cashing in on a trend? I don't know; all I do know is that Big Software switched from $old_process to Scrum around 2010-2012, and medium-sized companies seemed to follow in the middle of the decade.
I don't think "eventually" is the right word there. It immediately became dogma, and the one most used description about people's implementation of agile was always "you are doing it wrong".
Somehow the things in the Agile Manifesto never popularized, only those religions did.
Somehow the things in the Agile Manifesto never popularized, only those religions did.
> I believe that stems from the fact that agile methods became too "productized"
While I agree that that’s an issue, I would argue that it stems from the fact that dynamic ideas are opposed to pragmatic ones (at least in the minds of pragmatists).
Inevitably in companies there are voices that say “we should mitigate risk”, “let’s do what worked before”, and other things that boil down to “don’t change things because I’m not good with change”.
It’s those types of people who productize everything that gains momentum as it’s a cycle of “This new thing is a threat”, “They tried it and it worked, I better change my tone or I’ll be ostracized”, “How can this be made rigid and safe?” “Oh excellent, there’s a certification program now: time to crack down now that I have a whip.”. And as they spend more company money on making it “safe”, the market responds and makes more “safe” products.
While I agree that that’s an issue, I would argue that it stems from the fact that dynamic ideas are opposed to pragmatic ones (at least in the minds of pragmatists).
Inevitably in companies there are voices that say “we should mitigate risk”, “let’s do what worked before”, and other things that boil down to “don’t change things because I’m not good with change”.
It’s those types of people who productize everything that gains momentum as it’s a cycle of “This new thing is a threat”, “They tried it and it worked, I better change my tone or I’ll be ostracized”, “How can this be made rigid and safe?” “Oh excellent, there’s a certification program now: time to crack down now that I have a whip.”. And as they spend more company money on making it “safe”, the market responds and makes more “safe” products.
If agile were christianity, scrum would be the catholic church - the institutionalized, rigid, dogmatic and hierarchical instantiation of the original vaguely specified & lovey dovey cult.
I agree.
The process itself is fine.
The issue is that the practitioners are none-too-adept managers and teams.
Making software is simply hard.
No amount of Scrum frameworks solves for staffing a project with a talent-less manager. Although Scrum does help for that scenario I'll be honest.
The process itself is fine.
The issue is that the practitioners are none-too-adept managers and teams.
Making software is simply hard.
No amount of Scrum frameworks solves for staffing a project with a talent-less manager. Although Scrum does help for that scenario I'll be honest.
> 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".
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".
They called it “scrum but”
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.
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.
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)
> (not that scrum was more predictable in-practice, it just seems that way)
I use the phrase “the illusion of predictability” a lot when I talk about Scrum. Sadly, some people really cling to that illusion despite overwhelming evidence that it isn’t real.
I use the phrase “the illusion of predictability” a lot when I talk about Scrum. Sadly, some people really cling to that illusion despite overwhelming evidence that it isn’t real.
Kanban isn't an externally facing interface. Quite honestly Scrum and story mapping isn't that good for a whole of company approach.
You need to use tools like OKRs and good old waterfall to manage multiple team projects.
You need to use tools like OKRs and good old waterfall to manage multiple team projects.
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.
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.
Dealing with anything social, the rules don't self enforce - they aren't gravity.
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.
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.
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.
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.
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.
Really, I don't think that old world approach changed much with Scrum.
The root cause is that most people are honestly not too amazing at this corporate teamwork thing.
External frameworks like Scrum can improve things 10-20%, maybe.
The root cause is that most people are honestly not too amazing at this corporate teamwork thing.
External frameworks like Scrum can improve things 10-20%, maybe.
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.
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.
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?
So how is it any better?
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.
I found this truly sad. If you want accurate "velocity", you need to track it accurately. Our estimates were wrong.
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.
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.
The beautiful thing is there is a built into Scrum solution to this.
You alter estimation.
The fact story points are made up BS numbers means developers have full control over the velocity chart.
My favorite part of Scrum is it makes it IMPOSSIBLE to track velocity.
By making velocity IMPOSSIBLE to track, management MUST pivot to OKR lead management.
And OKR lead management is by far the best approach to software development.
You alter estimation.
The fact story points are made up BS numbers means developers have full control over the velocity chart.
My favorite part of Scrum is it makes it IMPOSSIBLE to track velocity.
By making velocity IMPOSSIBLE to track, management MUST pivot to OKR lead management.
And OKR lead management is by far the best approach to software development.
If your estimates are too crazy, you are forced to break them down into smaller tasks. This means lots of meetings. I think most engineers would rather have a bad estimate and "face the consequences" (generally not much), rather than put up with more meetings.
Can you describe "OKR lead management"? I am familiar with OKRs.
Can you describe "OKR lead management"? I am familiar with OKRs.
And at the very least with waterfall they thought about their requirements, now it's: shove 3 sentences in a JIRA and off you go, clairvoyant developer!
> 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.
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.
> Retros are essential for running an effective agile workflow
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
I've been in software development for just over 25 years. "Scrum" didn't start becoming a major thing until 2010-ish. Since that time, I could count the number of useful "retros" on one hand. It is almost always a waste of time.
"What should we stop doing?" "This." (The retro.)
"What should we stop doing?" "This." (The retro.)
Seems more like you never experienced a good scrum process. The retros were one of the most valuable things that always resulted in concrete actions taken otherwise i agree that it would be a waste of time.
Yeah, that's fair. I guess "Effective retros are essential" would be more accurate. It's just like any other step of the process: if the retro isn't working, figure out a different way to get the feedback. Nothing needs to be set in stone. You pick a starting point (i.e. Scrum + Retros) and make changes until things work as well as you need them to.
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.
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).
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.
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.
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.
That's is. SCRUM is an emergency mode operation technique that might work to sort out standard things, definitively not creating something new.
> 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”.
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”.
in 5 years we'll see the posts titled "Just-In-Time Process is awful, terrible and inflexible"
> ...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-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.
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-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.
This is the link excerpts are from: https://hbr.org/1986/01/the-new-new-product-development-game | https://archive.is/z3MkF
The most important part of scrum and the only part that is important is retrospectives, because it allows the team opportunity to step back and make changes to their processes. Everything else is mostly arbitrary. Want to stop doing stand ups or change how you manage work? Go for it, nobody is stopping you. Do what works for you.
In my experience, most retro meetings I have been in start with the scrum master asking things like "what did we do well this sprint?", followed by complete silence from the team until someone points out a non-point like "we collaborated well...".
One team I worked on decided to not pre-schedule retro meetings. Instead we had a 'retro board', which was just a section of a white board where team members would write down specific things that they think would be worth discussing in a future retro meeting. The team would decide to hold a retro meeting once the board had accumulated a few things to talk about. We found this approach was super effective because we knew what we needed to discuss when we held the meeting, instead of waiting for team members to recall something to talk about.
One team I worked on decided to not pre-schedule retro meetings. Instead we had a 'retro board', which was just a section of a white board where team members would write down specific things that they think would be worth discussing in a future retro meeting. The team would decide to hold a retro meeting once the board had accumulated a few things to talk about. We found this approach was super effective because we knew what we needed to discuss when we held the meeting, instead of waiting for team members to recall something to talk about.
We started playing Counter Strike every retro because all we were doing was bitching against things we have no power over.
That's been my experience of regular retrospectives too. There's rarely anything notable to discuss in a 2 week period (or even a month) so it just makes for useless awkward meetings.
I like your idea.
I like your idea.
That's how it works in well-functioning agile teams, but in "Agile" teams the team can't decide on their own to e.g. totally ditch standups. Management won't allow it, or they've set up the project manager to be God of Agile and they get last say on that kind of thing, and so on.
"Agile" teams outnumber agile teams by a large margin.
"Agile" teams outnumber agile teams by a large margin.
If you have a good team with good people, it doesn't matter much which process you're following, because shit will get done anyway.
Agile was a way of trying to document how some good teams got shit done, but most of the companies and people trying to implement it didn't understand that you actually need good people, they thought it was the process, and thus "Agile" was born.
...and to the complete mystery of everyone involved, "Agile" teams don't get shit done.
Agile was a way of trying to document how some good teams got shit done, but most of the companies and people trying to implement it didn't understand that you actually need good people, they thought it was the process, and thus "Agile" was born.
...and to the complete mystery of everyone involved, "Agile" teams don't get shit done.
Good people but not just that. Good culture, good management, good business model / funding, and a good sprinkle of luck.
And what makes them high performing? What is the metric? Money?
And what makes them high performing? What is the metric? Money?
This is painfully true and also deeply ironic given one of the lines in the Agile Manifesto itself.
That's how it works in well-functioning teams, period. Being "Agile" or "agile" has nothing to do with it.
I've encountered almost zero agile manifesto teams in my time for back-end software.
For 95% of projects, getting non-technical customers & stakeholders to read the manifesto and come demo software fortnightly, in person is impossible.
At best we get an intern or underling.
Interestingly, if the GUI was changed, they usually come racing.
For 95% of projects, getting non-technical customers & stakeholders to read the manifesto and come demo software fortnightly, in person is impossible.
At best we get an intern or underling.
Interestingly, if the GUI was changed, they usually come racing.
I've tried to explain several times to a client that 20-25 people is too many for a standup.
My "favorite" is when they mix teams working on unrelated things in the same standup. That sucks no matter how many people are in the meeting (thought obviously it's worse the larger the attendance)
The advantage if this is you have now 20 bored people waiting their turn to spit out a sentence. As they tune out their subconscious mind figures out an elegant solution to what they were suck on.
I did retrospectives at a job for 2.5 years.
I don't think in those ~60 retros, was there one thing we actually changed or accomplished.
Certainly much griping happened. But ultimately very little couod be accomlished, because our problems were beyond the team.
I would love to see retrospectives that worked, just to know what they are like. But so far I mostly see people forced to contribute to the retro, which results in:
1. Generic pats on the back for every minor thing we did. 'Really good job releasing feature X!' 2. Lot's of social compliments and jokes. 'X joined the team! Yay!' 3. Problems that we know about, but aren't tractable. 'The database schema we made 10 years ago really sucks!' but fixing it isn't practical.
I don't think in those ~60 retros, was there one thing we actually changed or accomplished.
Certainly much griping happened. But ultimately very little couod be accomlished, because our problems were beyond the team.
I would love to see retrospectives that worked, just to know what they are like. But so far I mostly see people forced to contribute to the retro, which results in:
1. Generic pats on the back for every minor thing we did. 'Really good job releasing feature X!' 2. Lot's of social compliments and jokes. 'X joined the team! Yay!' 3. Problems that we know about, but aren't tractable. 'The database schema we made 10 years ago really sucks!' but fixing it isn't practical.
So there probably were some things during that time the team could change, even if it was out of pure pragmatism (i.e., "well, raising this issue led to a bunch of busy work. Let's not raise that kind of issue any more"). But even if not, there certainly was benefit just agreeing "yeah, this is a problem we can't address", since that builds a stronger team.
That said, the situation you describe gets solved by the org adopting a retro itself. The team lead raises the broader issues up at a retro with other stakeholders/higher level management/etc, who -can- fix it.
That said, the situation you describe gets solved by the org adopting a retro itself. The team lead raises the broader issues up at a retro with other stakeholders/higher level management/etc, who -can- fix it.
I disagree... kind of.
Every team is different and will have different strengths and weaknesses. Scrum should act as a framework to get your team to do the things it's not doing, but it should be doing. The most important parts of scrum are the ones that align with your teams weaknesses. If your team is already good about giving feedback to each other and trying new things to improve retros may be completely unnecessary. If your team just carries on doing that same old things because "that's the way it's always been done", then retros could easily be the most important part.
One of my favorite teams I ever worked on was great about giving each other feedback and trying new things. Retros were completely unnecessary because we were great about giving feedback in the moment. Stand ups were super important on that team though because we didn't have an EM and our PM was completely checked out, so everyone just kind of did what they wanted. If we didn't check in regularly it completely possible for stuff to fall through the cracks or get forgotten.
The team I'm on now, retros are super important because everyone is super agreeable and will hold in complaints. Sprint planning on the other hand is almost completely unnecessary since we have a bunch of long running one person projects that will get done when they get done. Each sprint is basically just everyone going, "I'm continuing what I was working on last sprint".
Figure out what the goal of each piece of scrum is. If your team already does that well, throw the process away. Scrum (for your team) should be what is left. Repeat occasionally since teams and people change.
Every team is different and will have different strengths and weaknesses. Scrum should act as a framework to get your team to do the things it's not doing, but it should be doing. The most important parts of scrum are the ones that align with your teams weaknesses. If your team is already good about giving feedback to each other and trying new things to improve retros may be completely unnecessary. If your team just carries on doing that same old things because "that's the way it's always been done", then retros could easily be the most important part.
One of my favorite teams I ever worked on was great about giving each other feedback and trying new things. Retros were completely unnecessary because we were great about giving feedback in the moment. Stand ups were super important on that team though because we didn't have an EM and our PM was completely checked out, so everyone just kind of did what they wanted. If we didn't check in regularly it completely possible for stuff to fall through the cracks or get forgotten.
The team I'm on now, retros are super important because everyone is super agreeable and will hold in complaints. Sprint planning on the other hand is almost completely unnecessary since we have a bunch of long running one person projects that will get done when they get done. Each sprint is basically just everyone going, "I'm continuing what I was working on last sprint".
Figure out what the goal of each piece of scrum is. If your team already does that well, throw the process away. Scrum (for your team) should be what is left. Repeat occasionally since teams and people change.
>If your team just carries on doing that same old things because "that's the way it's always been done", then retros could easily be the most important part.
This tends to happen even with retros. Retros assume a lot of things about a team in order to work which just don't hold for a vast majority of teams.
That's the problem with almost every methodology. They make assumptions on how a team should work in order for the tool to do its job. If the team doesn't work that way, it's the teams fault. You obviously can't blame a tool, but a tool isn't particularly useful when it doesn't solve the problem, either.
Example for retros. They solve agreeableness and bottling things up, in theory. In practice, a lot of people stay agreeable and continue to bottle things up. They don't want to share frustrations. Maybe they try a few times, only to notice what they say doesn't really affect the future, leading to more frustration than just not saying anything. Which then puts the time spent doing the retrospective in question, or worse, it causes frustration because it keeps individuals from burying their problems. There are so many ways retros can be a big nothing burger, none of which are inherently the problem with retros.
Then someone comes along saying "have you tried this". No Captain Obvious, I haven't tried using a coconut to smash against the wall instead. I'm sure it will break now, and I won't risk getting coconut splinters in my face.
This tends to happen even with retros. Retros assume a lot of things about a team in order to work which just don't hold for a vast majority of teams.
That's the problem with almost every methodology. They make assumptions on how a team should work in order for the tool to do its job. If the team doesn't work that way, it's the teams fault. You obviously can't blame a tool, but a tool isn't particularly useful when it doesn't solve the problem, either.
Example for retros. They solve agreeableness and bottling things up, in theory. In practice, a lot of people stay agreeable and continue to bottle things up. They don't want to share frustrations. Maybe they try a few times, only to notice what they say doesn't really affect the future, leading to more frustration than just not saying anything. Which then puts the time spent doing the retrospective in question, or worse, it causes frustration because it keeps individuals from burying their problems. There are so many ways retros can be a big nothing burger, none of which are inherently the problem with retros.
Then someone comes along saying "have you tried this". No Captain Obvious, I haven't tried using a coconut to smash against the wall instead. I'm sure it will break now, and I won't risk getting coconut splinters in my face.
First of all, I hear your frustration. I've been a part of way too many teams that just do things for the sake of doing them. It sucks when it seems like no one else cares or will even acknowledge that it's a waste of time.
I'm not trying to push any particular part of scrum on anyone. My point was that I think teams should look to agile as a bunch of suggestions and should change or remove things as they see fit. If it's not working, scrap it. If retros assume your team works in one way, and your team doesn't work that way, change how your team does retros or don't do them.
Hell, at one company I worked at that was going through a particularly rough transition, we moved our "retros" to 3pm on Friday, brought beers, and by the 15 minute mark it was usually just a bitch-fest about everything that was going wrong at the company. They weren't the most productive retros ever, but it was what the team needed at that time.
> Example for retros. They solve agreeableness and bottling things up, in theory. In practice, a lot of people stay agreeable and continue to bottle things up.
I disagree. From what I've seen, people are a lot more willing to speak up if they know they're not the only one feeling that way. It's easier to "yes and" someone else's complaint that speak up on your own. I just ran our retro today, where one of the more quiet members only had positive things to say until one of the other members of the team mentioned how they were having trouble getting reviews on PRs in a timely manner. Once that was out there the quiet team member was happy to hop in and share her issues around the same thing, but I doubt that would have happened if someone else hadn't "popped the cork".
> Maybe they try a few times, only to notice what they say doesn't really affect the future, leading to more frustration than just not saying anything.
This sounds like the real root of your problems. If nothing is coming from your retros, I can see why you would be frustrated (I would be too). Our retros end with us going over the list of action items and assigning owners. Our next retro then starts with us going over that same list and seeing who got what done. For my current team that works really well and we've actually had some pretty great things come out of our retros because of it. I'm not trying to push that on you, but just giving an example of what works for us.
I hope I don't come off as offensive, but it really sounds to me like your team is pretty dysfunctional. I'm not sure there's really any process to get around that. Saying retros are useless when no one on your team cares is kind of like saying power steering is useless when your car is on fire.
I'm not trying to push any particular part of scrum on anyone. My point was that I think teams should look to agile as a bunch of suggestions and should change or remove things as they see fit. If it's not working, scrap it. If retros assume your team works in one way, and your team doesn't work that way, change how your team does retros or don't do them.
Hell, at one company I worked at that was going through a particularly rough transition, we moved our "retros" to 3pm on Friday, brought beers, and by the 15 minute mark it was usually just a bitch-fest about everything that was going wrong at the company. They weren't the most productive retros ever, but it was what the team needed at that time.
> Example for retros. They solve agreeableness and bottling things up, in theory. In practice, a lot of people stay agreeable and continue to bottle things up.
I disagree. From what I've seen, people are a lot more willing to speak up if they know they're not the only one feeling that way. It's easier to "yes and" someone else's complaint that speak up on your own. I just ran our retro today, where one of the more quiet members only had positive things to say until one of the other members of the team mentioned how they were having trouble getting reviews on PRs in a timely manner. Once that was out there the quiet team member was happy to hop in and share her issues around the same thing, but I doubt that would have happened if someone else hadn't "popped the cork".
> Maybe they try a few times, only to notice what they say doesn't really affect the future, leading to more frustration than just not saying anything.
This sounds like the real root of your problems. If nothing is coming from your retros, I can see why you would be frustrated (I would be too). Our retros end with us going over the list of action items and assigning owners. Our next retro then starts with us going over that same list and seeing who got what done. For my current team that works really well and we've actually had some pretty great things come out of our retros because of it. I'm not trying to push that on you, but just giving an example of what works for us.
I hope I don't come off as offensive, but it really sounds to me like your team is pretty dysfunctional. I'm not sure there's really any process to get around that. Saying retros are useless when no one on your team cares is kind of like saying power steering is useless when your car is on fire.
What's the point of even doing "sprints" then?
Can you elaborate further? I don't understand what part of my response this is directed at.
Edit: Nvm, I figured it out. I assume you're referring to this?
> Sprint planning on the other hand is almost completely unnecessary since we have a bunch of long running one person projects that will get done when they get done. Each sprint is basically just everyone going, "I'm continuing what I was working on last sprint".
Honestly, not a ton. If we worked in isolation, we could probably drop them and little would change for us. The value that I feel like they bring are:
- It forces developers to agree on and commit to a certain amount of work for those two weeks. If a dev says, I'm going to do these three things and two weeks later they're not done with #1 it's a red flag. They may have a totally legitimate reason, but it at least forces us to ask the question.
- Kind of in the same thought process it helps us break month long projects down into smaller deliverables and communicate the status outward. We could easily do this without sprints, but some sort of break down is needed, so why not sprints?
- Other teams are doing more traditional sprint planning, so it gives us all a common language to communicate in. If we need something from another team, being on the same schedule as everyone else is nice.
- Our release schedule is tied to sprints. Without sprints it'd be much harder to keep track of what is going out when.
Just to give more detail, we do have a sprint planning meeting, but it's basically just all of us meeting and saying what we're working on in the next sprint. Like I said in my original comment, we took the parts that worked for our team and threw away the rest.
Edit: Nvm, I figured it out. I assume you're referring to this?
> Sprint planning on the other hand is almost completely unnecessary since we have a bunch of long running one person projects that will get done when they get done. Each sprint is basically just everyone going, "I'm continuing what I was working on last sprint".
Honestly, not a ton. If we worked in isolation, we could probably drop them and little would change for us. The value that I feel like they bring are:
- It forces developers to agree on and commit to a certain amount of work for those two weeks. If a dev says, I'm going to do these three things and two weeks later they're not done with #1 it's a red flag. They may have a totally legitimate reason, but it at least forces us to ask the question.
- Kind of in the same thought process it helps us break month long projects down into smaller deliverables and communicate the status outward. We could easily do this without sprints, but some sort of break down is needed, so why not sprints?
- Other teams are doing more traditional sprint planning, so it gives us all a common language to communicate in. If we need something from another team, being on the same schedule as everyone else is nice.
- Our release schedule is tied to sprints. Without sprints it'd be much harder to keep track of what is going out when.
Just to give more detail, we do have a sprint planning meeting, but it's basically just all of us meeting and saying what we're working on in the next sprint. Like I said in my original comment, we took the parts that worked for our team and threw away the rest.
The whole terminology shows an attitude hostile to employees, just squeezing out the last drop of juiceout of them. Nobody can sprint all the time, sometimes you just need to walk slower.
I think I have seen 3 types of people
* some get cynical and just don't care about the sprint goals. What doesn't get done this sprint gets carried over to the next one
* others really want to get ticked off everything. So they compromise on quality, pile up technical debt. Eventually they hope the project will be closed or they move one.
* 3rd category burns out themselves. This can end badly, I have seen suicide attempts, people disappearing from their family and of course sick leaves and quitting their jobs.
I don't think planning every 2 weeks is a bad thing. It just makes sure that plans get reviewed, updated, and refocussed frquently enough. Whether the goals have been reached or not I don't care that much. Retros are often a waste of time. Yeah, we underestimated something. We forgot a task. Unforeseen customer support suddenly had higher priority. There is always some reason why things went differently, despite all intentions to do it better every time.
Edit: No I don't think all sprints go just completely wrong. But there is always something that didn't work out. Maybe 30% on average? With my current team we try to mostly look at the 70% that we got done reasonably well and then we move on carrying over what still needs to be done.
I think I have seen 3 types of people
* some get cynical and just don't care about the sprint goals. What doesn't get done this sprint gets carried over to the next one
* others really want to get ticked off everything. So they compromise on quality, pile up technical debt. Eventually they hope the project will be closed or they move one.
* 3rd category burns out themselves. This can end badly, I have seen suicide attempts, people disappearing from their family and of course sick leaves and quitting their jobs.
I don't think planning every 2 weeks is a bad thing. It just makes sure that plans get reviewed, updated, and refocussed frquently enough. Whether the goals have been reached or not I don't care that much. Retros are often a waste of time. Yeah, we underestimated something. We forgot a task. Unforeseen customer support suddenly had higher priority. There is always some reason why things went differently, despite all intentions to do it better every time.
Edit: No I don't think all sprints go just completely wrong. But there is always something that didn't work out. Maybe 30% on average? With my current team we try to mostly look at the 70% that we got done reasonably well and then we move on carrying over what still needs to be done.
As for #1, estimates are usually wrong, because people are often extremely optimistic. And requirements are often incredibly vague. To expect to meet 100% of your "sprint goals" is unreasonable. It's not cynicism, it's being realistic.
Retros are a big waste of time about 95% of the time.
Retros are a big waste of time about 95% of the time.
Thanks for your reply.
I find one problem with retros is they violate the principle of "praise in public, criticism in private". People instinctively understand that and thus there tends to be more praise. Everyone hears themselves praising the process and thus start to believe it actually is good. Therefore more Scrum gets done, no matter if it's actually good for the team or company or not.
Recently I went to a retro where the positives were listed as a great team, great accomplishments in the last sprint, thanks to person X for going the extra mile, and so on. When it came to discuss the negatives, the main one was "the meeting room was hard to find".
Recently I went to a retro where the positives were listed as a great team, great accomplishments in the last sprint, thanks to person X for going the extra mile, and so on. When it came to discuss the negatives, the main one was "the meeting room was hard to find".
Never seen anything useful actually come from a retrospective. There are open and interesting conversations about what went wrong/could be done better, but those discussions never materially change the team. Generally people are who they are, the work is what it is. How the team will be is relatively static given the same set of people and projects.
Interesting, I have a very different experience. My team does retrospective once a month (we don't do Scrum, so it's not tied to "sprints") and every month we actually do some improvements.
Sometimes the problems are small, let's say our products have inconsistent CLI interfaces for developers, and that slows us down, so we decide to unify it. Sometimes it's big stuff, for example the team feels that we don't have enough clarity about long term of the product, or there are too many interruptions. Then it's my (EM) or PM's role to figure stuff out.
Some of the good things we changed as a result of retro: we removed stand-ups, we agreed to meet in the office once a week, we introduced a daily support rotation for our users (we build internal tools). We can't fix everything, but every month we get something done, and that keeps the team motivated to bring new ideas to retros.
Sometimes the problems are small, let's say our products have inconsistent CLI interfaces for developers, and that slows us down, so we decide to unify it. Sometimes it's big stuff, for example the team feels that we don't have enough clarity about long term of the product, or there are too many interruptions. Then it's my (EM) or PM's role to figure stuff out.
Some of the good things we changed as a result of retro: we removed stand-ups, we agreed to meet in the office once a week, we introduced a daily support rotation for our users (we build internal tools). We can't fix everything, but every month we get something done, and that keeps the team motivated to bring new ideas to retros.
I have the same experience with retros. Generally they've have been a waste of time. Any useful information that could have been gleaned from them were probably already had in an earlier discussion, tend not to be remembered to be brought up again in retros, and at least in the teams I've been on the minutes from the retro meetings don't get recorded anywhere anyway, so there's nothing to refer back to in the future.
it seems these teams lack(ed) the drive to consciously change.
meetings should have conclusions (action items based on consensus, which are commitments from all members) and it's a typical team dysfunction when members don't honor commitments (someone doesn't do something and then others don't bring this up to hold each other accountable)
if the team is so dysfunctional that it just does the same thing over and over again while constantly promising to change then it should be broken up before the members themselves start to suffer the psychological toll of this cognitive dissonance.
meetings should have conclusions (action items based on consensus, which are commitments from all members) and it's a typical team dysfunction when members don't honor commitments (someone doesn't do something and then others don't bring this up to hold each other accountable)
if the team is so dysfunctional that it just does the same thing over and over again while constantly promising to change then it should be broken up before the members themselves start to suffer the psychological toll of this cognitive dissonance.
>it seems these teams lack(ed) the drive to consciously change.
classic Scrum statement - putting the blame again on teams. A team usually has no power to change anything that matters.
classic Scrum statement - putting the blame again on teams. A team usually has no power to change anything that matters.
what has this has to do with scrum?
I haven't even mentioned it (or even implied that this has something to do with scrum), dysfunctional teams are waaaay more general problem than whatever scrum is/isn't.
Blame implies responsibility, which - like you mentioned - is not that simple. (Depending on personal philosophy maybe each team member has a responsibility toward themselves to get a job where they are not put into the aforementioned loony toones situation, but even with that in mind I honestly think you misinterpreted my comment, because I don't meant to assign blame at the team and its members. You might notice I expressly mentioned that if the team is too dysfunctional it has to be broken up "from above", implying that its not the responsibility of the team.)
I haven't even mentioned it (or even implied that this has something to do with scrum), dysfunctional teams are waaaay more general problem than whatever scrum is/isn't.
Blame implies responsibility, which - like you mentioned - is not that simple. (Depending on personal philosophy maybe each team member has a responsibility toward themselves to get a job where they are not put into the aforementioned loony toones situation, but even with that in mind I honestly think you misinterpreted my comment, because I don't meant to assign blame at the team and its members. You might notice I expressly mentioned that if the team is too dysfunctional it has to be broken up "from above", implying that its not the responsibility of the team.)
Disagree.
After retrospectives we've always had a pretty good idea of what our problems are.
Motivation to fix those issues is a different story. Scrum can't solve for lacking motivation.
After retrospectives we've always had a pretty good idea of what our problems are.
Motivation to fix those issues is a different story. Scrum can't solve for lacking motivation.
This is why Pivotal Labs would rotate people on teams quite often. Nobody gets "stuck" doing the same thing endlessly.
In my several years of experience of participating in retrospectives at two different companies/teams - it's a total waste of time. Just one of the ceremonies for keeping "Agile Coaches" employed.
IMO I think it depends on how the team handles it. The team I'm on tends to oscillate between "useless meeting" and "agent for change". I think if there's nothing to talk about why have yet another meeting? Perhaps we'll implement a straw poll about actually holding retrospective... I'll bring it up in the next retro of course.
I completely agree. I was a certified scrum master, scrum master of a team of 6 for 2 years, and was directly coached by an external (and expensive) scrum consultant. We got pretty deep into the scrum process, even going so far as to estimate and track the number of hours each task would take. After all of that, my takeaway is that thoughtful, engaging retrospectives are the only scrum "event" or process that a team should do. Want to do a stand up meeting only once a week? Go for it. You think pointing stories is a waste of time? Cool, spend that hour coding instead. But you have to regularly check in and make sure your process is actually working, and then put some effort into improving it.
Also, don't forget to retro your retros. Maybe a 2 hour meeting twice a month is a waste of time because your team is already great at providing feedback and trying new things naturally. Getting rid of the meeting might be the best thing as long as there is a viable alternative way for everyone to provide feedback and suggestions.
Also, don't forget to retro your retros. Maybe a 2 hour meeting twice a month is a waste of time because your team is already great at providing feedback and trying new things naturally. Getting rid of the meeting might be the best thing as long as there is a viable alternative way for everyone to provide feedback and suggestions.
how did you estimate hours? do you mean that the team estimated "story points" and it was so precise and the team was so good at meeting the per-sprint point load that it was basically a nice hour estimate? or did you estimate hours directly?
Retrospectives don't help when your problems are external and you do not have influence on them. If you get how much needs to be done and what needs to be done set fixed from outside the team cannot do much about it. And that what scrum often ends up in a lot of companies: all the responsibility when things go bad but none of the autonomy that would be needed.
I've noticed a related effect, where every problem discussed in a retro has a "process" solution, because the team's own processes are the only thing the team can fully control.
This can lead to both a constant churn in processes and a piling on of additional processes, which bog the team down with an explosion of on-call-like rolls that get rotated through team members.
This can lead to both a constant churn in processes and a piling on of additional processes, which bog the team down with an explosion of on-call-like rolls that get rotated through team members.
>The most important part of scrum and the only part that is important is retrospectives
That's funny because my "scrum" team doesn't do retrospectives at all, we just focus on long planning sessions every sprint. We are fully scrumfall.
That's funny because my "scrum" team doesn't do retrospectives at all, we just focus on long planning sessions every sprint. We are fully scrumfall.
That is also the only meeting (or doc; communal collaboration) prescribed by the Agile manifesto.
People get so caught up in the process trappings of "agile" they miss the point.
People get so caught up in the process trappings of "agile" they miss the point.
Everything needs to reflect to the team's needs. I'm a very big advocate of scrum, but I rarely have my teams run pure scrum. One thing I absolutely love is introducing the concepts of sprints and watching conversations switch from bickering about single day deadlines on a multi-week project to "sounds like it'll take X sprints".
There are essentially two times you should try to follow scrum perfectly:
* During a fire/emergency. This should be rare. It helps keep the response moving without unnecessary overhead. Yes, the meetings are overhead - but they often cut out other other head.
* When gelling a new team. Scrum is really helpful in getting the team to mesh quickly. Routine contact, flexibility, small iteration, all good stuff.
Outside of that, roll scrum back to match the team. For us, that's:
* Bi-weekly retrospectives.
* 1 to 3 standups per week (depending on the team's need)
-----
Basically, we ask for 4 hours of people's time over 2 weeks. We find this ends up saving well over 4-hours of 1-off and random meetings.
There are essentially two times you should try to follow scrum perfectly:
* During a fire/emergency. This should be rare. It helps keep the response moving without unnecessary overhead. Yes, the meetings are overhead - but they often cut out other other head.
* When gelling a new team. Scrum is really helpful in getting the team to mesh quickly. Routine contact, flexibility, small iteration, all good stuff.
Outside of that, roll scrum back to match the team. For us, that's:
* Bi-weekly retrospectives.
* 1 to 3 standups per week (depending on the team's need)
-----
Basically, we ask for 4 hours of people's time over 2 weeks. We find this ends up saving well over 4-hours of 1-off and random meetings.
Retrospective is when I turn on my personal computer and start playing video games while listening to the meeting.
It's completely useless, the only stuff we get is useless recognition like "Thanks iLoveOncall for helping me fix that bug" or "Congrats for your first CR NewJoiner4528".
An absolute waste of time.
It's completely useless, the only stuff we get is useless recognition like "Thanks iLoveOncall for helping me fix that bug" or "Congrats for your first CR NewJoiner4528".
An absolute waste of time.
You are right.
I miss Friday's at Pivotal Labs where we went as a team to a conference room and wrote a happy face, meh face and sad face on the board.
We wrote out things that happened during the week under each column. Everyone votes for what they want to talk about and the items with the most votes get discussed first.
Doing this religiously helped with team cohesion and allowed us to develop better products together. Those 30 minutes were a great way to end each week and set us up for a productive new week on Monday.
I miss Friday's at Pivotal Labs where we went as a team to a conference room and wrote a happy face, meh face and sad face on the board.
We wrote out things that happened during the week under each column. Everyone votes for what they want to talk about and the items with the most votes get discussed first.
Doing this religiously helped with team cohesion and allowed us to develop better products together. Those 30 minutes were a great way to end each week and set us up for a productive new week on Monday.
You need measurement too. You need a way to measure the success of the change that was agreed on in the retrospective. Story points, LoC, tickets, whatever.
The most important part is making the changes to processes. Sure, retrospectives are part of it, but when retrospectives become just a place for the team to air their grievances but all suggestions are blocked by management, it is hell on earth.
"Having no process at all" beats "Performative Scrum".
"Having no process at all" beats "Performative Scrum".
I agree. I see retros as the only time, a team as a whole sits/works together for around 2 hours at a time.
My advice: treat retros as a way to check in with your team or the team itself. Sometimes, if there are no pressing topics, just talking and chilling can be the best use of the time.
My advice: treat retros as a way to check in with your team or the team itself. Sometimes, if there are no pressing topics, just talking and chilling can be the best use of the time.
it depends on if the retro itself is rigid or not
many times retros are done in the same fashion:
1. everyone writes their pain points
2. everyone writes what went well (this is usually ignored)
3. everyone votes on the pain points
4. take the top 3 and discuss
5. write up some todo for the top 3
---
the above looks good on paper, but in reality many times a free flowing discussion is much more productive, and this can be done by just normal team meetings to discuss such issues
many times retros are done in the same fashion:
1. everyone writes their pain points
2. everyone writes what went well (this is usually ignored)
3. everyone votes on the pain points
4. take the top 3 and discuss
5. write up some todo for the top 3
---
the above looks good on paper, but in reality many times a free flowing discussion is much more productive, and this can be done by just normal team meetings to discuss such issues
In every new team, on first retrospective I test it with a simple: let's get rid of retrospectives (followed by: let's not make demos). If it passes the manager, this is a true retro - never happened.
Hah! I wish someone like you had been on my last team. I was always thinking this exact thing. Unfortunately, the last manager was a true agile professional, and would keep the Zoom call running until we all contributed something to the "retrospective document" that got shared out.
N Times 'well: great atmosphere and colleagues; no minus points'
As a manager, I’d just think you’re being provocative and short-sighted.
As an IC, I’d think you’re big-mouthed, in a bad way.
In any case, even if you were right, I’d be the kind of colleague you’d have to work your way up to retrieve trust after such a stunt.
As an IC, I’d think you’re big-mouthed, in a bad way.
In any case, even if you were right, I’d be the kind of colleague you’d have to work your way up to retrieve trust after such a stunt.
Really, a stunt?
If I can't change such things what can I change in a retro? It is usually either patting on the back or complaining on things that don't change.(late requirements, we forgot about one more dependency etc.) None of the negative things I have seen on retros in the last 10 years did get changed. So now I see it as a pointless meeting that takes away time to do coding.
Fortunately. With all the WFH in the last 2 years I don't need to really listen to it.
If I can't change such things what can I change in a retro? It is usually either patting on the back or complaining on things that don't change.(late requirements, we forgot about one more dependency etc.) None of the negative things I have seen on retros in the last 10 years did get changed. So now I see it as a pointless meeting that takes away time to do coding.
Fortunately. With all the WFH in the last 2 years I don't need to really listen to it.
> In every new team, on first retrospective I test it with a simple: let's get rid of retrospectives
Trying to get rid of something, in any new context, at first encounter is sending the signal that you think you know better without actually even willing to see for yourself in said new context.
That's why I used the term "stunt".
Do the same thing after a quarter, where you have gained knowledge, experience and feedback, and I'd happily use a much more appreciative term :)
Trying to get rid of something, in any new context, at first encounter is sending the signal that you think you know better without actually even willing to see for yourself in said new context.
That's why I used the term "stunt".
Do the same thing after a quarter, where you have gained knowledge, experience and feedback, and I'd happily use a much more appreciative term :)
This seems obnoxious and anarchical, which in a new team probably won’t fly. People don’t like to be tested in this way.
I’d probably reevaluate what it is you’re trying to achieve from a retrospective and listen to the team.
I’d probably reevaluate what it is you’re trying to achieve from a retrospective and listen to the team.
In my (20y+) experience, as soon as a methodology/process gets a name for itself, it has lost its original meaning and starts undermining the productivity. At that time all sorts of consultants crawl out of the woodwork and start converting companies to that process. Making good money of course. After that, following the process becomes more important than whatever the actual product is. Turning a large corporation into a new process takes years. Lots of documents created and new roles with funny names etc. And then someone invents a new cool process....
In my opinion, the basics is just to plan ahead only as far as realistic, communicate freely and directly in all levels including customer, document what makes sense, learn from mistakes and don't be afraid to throw away and redo things that don't work. Which, in my opinion, is pretty much the core of most of the processes anyway. But please don't start calling it with some name....
A process has no name.
We can only hope. Little makes the good devs I know run faster from a job application than the phrase "Full participant in agile rituals/ceremonies". Everyone knows what the employer who says that is actually going to be like by now.
If you have to tell everyone what you were doing yesterday and they actually need to know your project tracking tool is broken. If you have to wait until the next day to raise a blocking issue your project management process is broken and your team isn't communicating at all. So what is the benefit of a daily standup again? Anything useful that is said there would probably be better said through asynchronous channels in real time. Most of what is said there isn't useful to most of the people attending anyway.
Then there's the planning poker thing. I think that's the one where a possibly large group of people often with conflicting incentives allocate imaginary points based on a mostly-arbitrary-in-practice scale to some tasks they might do in the next few weeks with the general goal of taking on just enough to look like they're doing something useful when management check without risking missing the entirely arbitrary deadline.
We also have retrospectives to consider. Those are where you have yet another meeting to talk about what you could improve in the future based on what you've learned and then don't do any of it because the people leading the meeting aren't developers and miss the point and in any case management has prescribed the One True Process so you can't do things like dumping standups and planning poker even if none of you believe they are helping.
As far as I can tell the Age of Scrum should never have started and the continued remarkably widespread practice of Scrum in the industry is much more due to management who read a book or went to a conference than developers who actually believe it makes them more effective.
If you have to tell everyone what you were doing yesterday and they actually need to know your project tracking tool is broken. If you have to wait until the next day to raise a blocking issue your project management process is broken and your team isn't communicating at all. So what is the benefit of a daily standup again? Anything useful that is said there would probably be better said through asynchronous channels in real time. Most of what is said there isn't useful to most of the people attending anyway.
Then there's the planning poker thing. I think that's the one where a possibly large group of people often with conflicting incentives allocate imaginary points based on a mostly-arbitrary-in-practice scale to some tasks they might do in the next few weeks with the general goal of taking on just enough to look like they're doing something useful when management check without risking missing the entirely arbitrary deadline.
We also have retrospectives to consider. Those are where you have yet another meeting to talk about what you could improve in the future based on what you've learned and then don't do any of it because the people leading the meeting aren't developers and miss the point and in any case management has prescribed the One True Process so you can't do things like dumping standups and planning poker even if none of you believe they are helping.
As far as I can tell the Age of Scrum should never have started and the continued remarkably widespread practice of Scrum in the industry is much more due to management who read a book or went to a conference than developers who actually believe it makes them more effective.
Amen
Truer words have never been spoken.
> Within 5 years Scrum will be largely irrelevant as an influence in modern software companies
I am a senior engineer and I still haven't experienced the mythical "scrum done well". Every single project that attempts scrum ends up burning people out eventually. The main cause is that it's a grossly leaky abstraction that forces people to micromanage themselves. If your company sucks, scrum is not going to save it.
I am a senior engineer and I still haven't experienced the mythical "scrum done well". Every single project that attempts scrum ends up burning people out eventually. The main cause is that it's a grossly leaky abstraction that forces people to micromanage themselves. If your company sucks, scrum is not going to save it.
I've seen it work, but only in very small teams (not teams that were a part of a big corporation, mind you, but small teams in a very small companies). Where there was a thick layer of middle management comprised mostly of social climbers and micromanagers, it all fell apart because all the rituals were in place for all the wrong reasons.
> I've seen it work, but only in very small teams
i think its once managers, pdms, other peer teams (android/ios/backend together) and scrum masters start getting involved, it starts to get convoluted... estimations take too much time, ceremonies start to fossilize, plans become too rigid, and retros are too general...
on the other hand, a team of 2 or 3 people talking about what to do for the next 2 weeks, going over blockers/issues once a day (or so) doesn't seem too bad
idk just my experience
I actually like scrum but would say most people I have worked with have no clue what it is about. My scrum master for example mindlessly follows 'the rules' but does little to actually improve our teams productivity. They just make sure we do the meetings, fill in the right form in the retro, etc. Same with the sprints, we 'plan' our work in two weeks, when it won't fit, we just split it in part 1 & 2. We don't actually have working software at the end of the sprint, but we did it in two weeks right? It's a cargo cult.
To me scrum is a bunch of guidelines that can give you some framework to start from, you try it out, and you see what works, what doesn't. You iterate on the process just as you iterate on the code, no fixed rules, but not too loose neither. But ambiguity, nuance, and context never work well in a corporate setting...
I don't think we need a better process, we need better middle management.
To me scrum is a bunch of guidelines that can give you some framework to start from, you try it out, and you see what works, what doesn't. You iterate on the process just as you iterate on the code, no fixed rules, but not too loose neither. But ambiguity, nuance, and context never work well in a corporate setting...
I don't think we need a better process, we need better middle management.
Completely agree. It's the mindless nature that's the red flag here.
I met a guy who came across as quite fluent in these meetings but quickly you would realise he didn't know what any of it meant - it was like the Chinese Room.
With that little connection with anything it was impossible for people to pick up basic errors, it was just rote learning and soon it spread to others; no one was equipped to make sensible suggestions as they couldn't see the big picture and didn't really know what the things they did were actually for let alone the "why" ("Oh, so we're building a ship... to float on the water? Thanks!", turns back to keyboard, resumes vacant look)
I met a guy who came across as quite fluent in these meetings but quickly you would realise he didn't know what any of it meant - it was like the Chinese Room.
With that little connection with anything it was impossible for people to pick up basic errors, it was just rote learning and soon it spread to others; no one was equipped to make sensible suggestions as they couldn't see the big picture and didn't really know what the things they did were actually for let alone the "why" ("Oh, so we're building a ship... to float on the water? Thanks!", turns back to keyboard, resumes vacant look)
I'm in the same boat. The way my team operates grew mostly organically, with the only 2 things that were more-or-less set were the 2-week sprints and the end-of-sprint retrospectives; and even those were brought up as things we can change if we aren't getting value out of them. When used this way, it's basically setting a cadence for trial and error and figuring out what works and what doesn't. This is especially important when teams grow and scale out, as things that may have worked for a team of 6 won't work for a team of 12.
Just yesterday, my team officially agreed to discard the last vestiges of our ailing Scrum practice. (Corporate requires us to use JIRA, and JIRA forces us to organize things into sprints, so there's that, but, even there, we've agreed to just do what we're going to do and pencil whip things to make JIRA happy.) I'm optimistic. The new plan is a loose high-level structure and a lot more room to experiment with our process and find what feels good. And a renewed commitment to do so. And a fresh morale boost. The transition will be difficult, but we will learn much and be better for it.
I personally tend to defend Scrum as being overly maligned and often blamed for the consequences of misapplications. But that last sentence is a double edged blade. The truth is, the model is brittle and internally unstable, and it's difficult to get good results without constant vigilance to ensure the rituals are being performed correctly.
(There's even an entire role just for doing that. It's the one with Scrum in the name.)
And that's getting tricky in an increasingly distributed world. Online ticketing systems, for example, practically beg you to overload the tickets with extraneous clutter and paperwork that bogs you down. But you can't use the (greatly preferable, for Scrum purposes) sticky notes on a wall if you're not co-located. Story points don't work with distributed teams, either. They need planning poker (or similar) to function properly. But planning poker is exhausting, and videoconferencing is exhausting, and so nobody has much appetite or endurance for the exercise in self flagellation that is Zoom planning poker. So we all mentally and emotionally check out, which completely undercuts the effectiveness of the practice.
Also, Scrum is just too meeting-heavy. We're spread across six time zones. We have precious few hours in the day when we can all meet with each other, and we simply can't afford to continue spending them all on so many synchronous rituals.
I personally tend to defend Scrum as being overly maligned and often blamed for the consequences of misapplications. But that last sentence is a double edged blade. The truth is, the model is brittle and internally unstable, and it's difficult to get good results without constant vigilance to ensure the rituals are being performed correctly.
(There's even an entire role just for doing that. It's the one with Scrum in the name.)
And that's getting tricky in an increasingly distributed world. Online ticketing systems, for example, practically beg you to overload the tickets with extraneous clutter and paperwork that bogs you down. But you can't use the (greatly preferable, for Scrum purposes) sticky notes on a wall if you're not co-located. Story points don't work with distributed teams, either. They need planning poker (or similar) to function properly. But planning poker is exhausting, and videoconferencing is exhausting, and so nobody has much appetite or endurance for the exercise in self flagellation that is Zoom planning poker. So we all mentally and emotionally check out, which completely undercuts the effectiveness of the practice.
Also, Scrum is just too meeting-heavy. We're spread across six time zones. We have precious few hours in the day when we can all meet with each other, and we simply can't afford to continue spending them all on so many synchronous rituals.
> so many synchronous rituals
scrum feels like its from another era where email, slack and git(hub) don't exist yet and assumes we need to "have meetings" for everything
I hear this sort of thing often but I haven't heard a really good alternative.
One thing I question about scrum is "why daily standups"? Why not 3 days a week? Or once a week. It seems like nothing more than a social event when the whole team gets together every seven working hours and says "here's what I did for the past 7 working hours, here's what I'm doing for the next seven working hours".
One thing I question about scrum is "why daily standups"? Why not 3 days a week? Or once a week. It seems like nothing more than a social event when the whole team gets together every seven working hours and says "here's what I did for the past 7 working hours, here's what I'm doing for the next seven working hours".
That's about right. But what I see happening, when done right, is that people are forced to talk about what's holding them up. Without it, people tend to just keep spinning their wheels instead of asking for help. With Scrum, instead of asking for help, they're forced to just state their situation, and someone will jump in and help if they can... Or at least the team lead will know about the situation within a day, instead of finding out a week later when the thing is due.
Done wrong, and it's a grueling 30-60 minute ordeal that wastes everyone's time.
It's important to keep everyone to the 3 talking points. What did you do, what's blocking you, and what will you work on.
It also keeps the team up to date with what's going on, and I know that I personally feel disconnected without that information.
Do we scrum? Nope. But we do have a meeting every morning that also doubles as a time to chat about any random things we like, and it usually runs about an hour. We take care of business stuff some time during the hour, depending on how excited someone is to talk about non-work stuff, but the work stuff can take as little as a few minutes, or as long as the hour, depending on what's happening. Joining the meeting is mandatory for programmers and project manager, but staying in the meeting isn't. That said, I don't think any programmer has ever left early unless there's some emergency. It's optional for sysadmins, and each of them has treated it differently. I think it works best when they at least pop in and say "Hi", but we leave it up to them.
Done wrong, and it's a grueling 30-60 minute ordeal that wastes everyone's time.
It's important to keep everyone to the 3 talking points. What did you do, what's blocking you, and what will you work on.
It also keeps the team up to date with what's going on, and I know that I personally feel disconnected without that information.
Do we scrum? Nope. But we do have a meeting every morning that also doubles as a time to chat about any random things we like, and it usually runs about an hour. We take care of business stuff some time during the hour, depending on how excited someone is to talk about non-work stuff, but the work stuff can take as little as a few minutes, or as long as the hour, depending on what's happening. Joining the meeting is mandatory for programmers and project manager, but staying in the meeting isn't. That said, I don't think any programmer has ever left early unless there's some emergency. It's optional for sysadmins, and each of them has treated it differently. I think it works best when they at least pop in and say "Hi", but we leave it up to them.
An hour each day?!
It must be hell for anybody on your team having ADHD. If it's remote they probably drone the meeting out and play solitaire or something I guess.
Also, the cost...
It must be hell for anybody on your team having ADHD. If it's remote they probably drone the meeting out and play solitaire or something I guess.
Also, the cost...
[deleted]
>But what I see happening, when done right, is that people are forced to talk about what's holding them up.
I bring that up right away to the appropriate person via email or call or walk-over (when all else fails). If I had to wait until the next morning's standup, it would be less efficient.
I bring that up right away to the appropriate person via email or call or walk-over (when all else fails). If I had to wait until the next morning's standup, it would be less efficient.
I wish everyone did. Everyone is certainly encouraged to do that. I've found it to be pretty rare that someone brings it up within a day unless they're prompted somehow.
It is an arbitrary ritual. I never understood why everyone is so dogmatic about planning process. It’s like any other development pattern—it should be adapted to the context it’s in.
The whole point of a standup is to keep the a team coordinated and it’s manager/lead informed. Standup isn’t the only way to do this. It can happen asynchronously. It can happen at end of day. It can happen as often or as infrequently makes sense given the size, maturity, and scope of your team.
Agile and Scrum have a lot of great ideas, but there’s so much dogma and cargo curling I feel like orgs take all of the ritual with none of the insight: iterate quickly and use the delta between plans and reality to gain a sense of predictability. That’s all it really boils down to.
The whole point of a standup is to keep the a team coordinated and it’s manager/lead informed. Standup isn’t the only way to do this. It can happen asynchronously. It can happen at end of day. It can happen as often or as infrequently makes sense given the size, maturity, and scope of your team.
Agile and Scrum have a lot of great ideas, but there’s so much dogma and cargo curling I feel like orgs take all of the ritual with none of the insight: iterate quickly and use the delta between plans and reality to gain a sense of predictability. That’s all it really boils down to.
Engineering management is a culture. Cultures have shared mythologies and values that bind the tribe together, that tell members who they are and their place in the world. Two key commitments of this particular culture are metrics and standardization.
Otherwise rational and pragmatic leaders will either pretend not to hear you or look at you like you have three heads when you make an argument that seriously challenges one of these commitments. Very smart ones have some trite stock answers as defense mechanisms. This is because you are committing a type error. This kind of argumentation is valid with respect to rational strategies adopted instrumentally towards goals. The commitment to uniformity is deeper than that.
Scrum is the recognized best practice; we make sure that all tendrils of the organization follow a standard and that this standard is aligned with recognized best practice because that is the kind of people we are.
Otherwise rational and pragmatic leaders will either pretend not to hear you or look at you like you have three heads when you make an argument that seriously challenges one of these commitments. Very smart ones have some trite stock answers as defense mechanisms. This is because you are committing a type error. This kind of argumentation is valid with respect to rational strategies adopted instrumentally towards goals. The commitment to uniformity is deeper than that.
Scrum is the recognized best practice; we make sure that all tendrils of the organization follow a standard and that this standard is aligned with recognized best practice because that is the kind of people we are.
From my experience the problem is that Scrum guides say (or used to say, it might have changed) that in order to do Scrum, you need to do it all. So all the certified Scrum Masters learn that they have to do daily stand-ups and all the other meetings, and because they believe their job is to implement Scrum (instead of making the team more productive), they enforce it all.
Every time I worked with certified Scrum Masters I had exactly the same struggles.
Every time I worked with certified Scrum Masters I had exactly the same struggles.
You raise a good point, and I’ve seen this in other contexts.
Team wants to be better at X. Y is a tool or process that helps them get there.
At some point, the goal of X is forgotten and Y subsumes everything, sometimes to the detriment of X.
It’s like a weird correlate or inversion of the XY problem and I’ve seen it in a lot of contexts.
Team wants to be better at X. Y is a tool or process that helps them get there.
At some point, the goal of X is forgotten and Y subsumes everything, sometimes to the detriment of X.
It’s like a weird correlate or inversion of the XY problem and I’ve seen it in a lot of contexts.
Good questions. The usual answer is “because it’s a good staring point for teaching the team to talk and coordinate often”. As with most scrum ceremonies, the standup should probably be adapted to match the needs of the team. It doesn’t have to be a reporting circle where you tell your PM “what did you do, what will you do, what is blocking you”.
_edit_: Adapted or removed or reinvented.
_edit_: Adapted or removed or reinvented.
Can there ever be a prescriptive product development framework that works for all software development though? Is such a thing even possible.
> a prescriptive product development framework that works for all software development
I mean if you follow scrum by the book, then change it to 3 days a week. The whole idea is that teams can determine their process.
I agree standups are a ritual, but for me, they help me pace my day. I typically start work for standup and they are great for ad-hoc discussions and team announcements.
As an EM, Scrum notes log of what people have been working on which is helping for reviewing during performance management.
As an EM, Scrum notes log of what people have been working on which is helping for reviewing during performance management.
We've been trying a more "Kanban" approach vs scrum, but who knows if we're actually implementing it correctly, which is perhaps the point of all this.
There's no need to implement any sort of internal process like this "correctly". It's working correctly if it makes your team happier and more productive. It is not working correctly if it does not.
Kanban vs Scrum is not really the issue, but Kanban is certainly more honest. When a server goes down in the middle of the day and someone needs to spend 2 hours debugging the logs to get it back up, do you add a task to do that for next sprint? No, you do it right there and then. At least in Kanban the task has some chance of actually being registered in the issue tracker.
The only thing I will suggest is if you do Kanban (meaning continuous adjustments to the backlog with devs picking the higher priority tasks and doing them as needed), have a synchronization meeting from time to time, almost like a sprint retro meeting, but mainly to have the team talk about how things are going and to make it clear what everyone is working towards. The meeting doesn't need to have a specific goal or structure.
It can feel like a bit of treadmill if all you do is grab task -> do task -> mark task done all day with no larger vision, so having some synchronization moments where the whole team regroups can help with that.
Kanban vs Scrum is not really the issue, but Kanban is certainly more honest. When a server goes down in the middle of the day and someone needs to spend 2 hours debugging the logs to get it back up, do you add a task to do that for next sprint? No, you do it right there and then. At least in Kanban the task has some chance of actually being registered in the issue tracker.
The only thing I will suggest is if you do Kanban (meaning continuous adjustments to the backlog with devs picking the higher priority tasks and doing them as needed), have a synchronization meeting from time to time, almost like a sprint retro meeting, but mainly to have the team talk about how things are going and to make it clear what everyone is working towards. The meeting doesn't need to have a specific goal or structure.
It can feel like a bit of treadmill if all you do is grab task -> do task -> mark task done all day with no larger vision, so having some synchronization moments where the whole team regroups can help with that.
The only process/structure you need for any size software project is a prioritised task list + no interruption of tasks already started. That’s it.
I’m with you on this. One clarification I’ve had to fight for is that it be A prioritized task list, singular.
The age of Scrum never really started, because no one does any agile development properly ever.
At least that's what the proponents say when anyone points out any issue at all with anything agile.
At least that's what the proponents say when anyone points out any issue at all with anything agile.
And scrum is not agile ("people above processes").
Most organizations that I've worked with as a consultant think Jira = Agile/Scrum and fail to do even the most basic actual Agile/Scrum things like proper story writing, filling a product owner role with someone who has even a remote idea of the product owner's responsibility, etc., etc.
> Trend One - the shift to empowered teams that own a business or product domain. Although many feature factories still churn out software, the companies that are able to shift key parts of the product decision making process into the teams producing the software are gaining an edge. Marty Cagen writes about this difference in his classic blog product teams vs feature teams
> Trend Two - DevOps. In addition to working in the left hand side of the software lifecycle, teams are also now beginning to operate the software that resides within their sphere.
If developers are now expected to figure out the business case, design the product, write the code and operate the production servers, what exactly is the rest of the company doing?
> Trend Two - DevOps. In addition to working in the left hand side of the software lifecycle, teams are also now beginning to operate the software that resides within their sphere.
If developers are now expected to figure out the business case, design the product, write the code and operate the production servers, what exactly is the rest of the company doing?
The empowered teams can't be a team of only developers. They need to consist of multi-disciplinary skill-sets from the three main areas (Business, Design, Engineering) based on the related domain.
Scrum and Agile have given us a lot.. of nasty problems.
Don't get me wrong, I think Scrum and Agile may be great tools, but their values are not exclusively intrinsic. There are SEVERAL prerequisites for them to work well. And proponents of Agile methods, either by excess of enthusiasm or economic interests in selling courses, books, lectures etc, have always pushed this arrogant perspective of "if agile is not working for you, you are doing it wrong" and "some organizations are not mature enough for agile". The number of practitioners who bought that truckload of BS is terrifying.
And then MBAs and PMPs finally "embraced" agile. The rest is consequence.
So, yeah, farewell agile, and I fear for what comes next.
Don't get me wrong, I think Scrum and Agile may be great tools, but their values are not exclusively intrinsic. There are SEVERAL prerequisites for them to work well. And proponents of Agile methods, either by excess of enthusiasm or economic interests in selling courses, books, lectures etc, have always pushed this arrogant perspective of "if agile is not working for you, you are doing it wrong" and "some organizations are not mature enough for agile". The number of practitioners who bought that truckload of BS is terrifying.
And then MBAs and PMPs finally "embraced" agile. The rest is consequence.
So, yeah, farewell agile, and I fear for what comes next.
Many of the ideas and practices in "agile" in general seem to me still to be very relevant and useful. It can be used for good or evil (or just given lip-service without even really trying), but I think there is good advice and ideas there for those who are approaching it trying to do well.
But "scrum" specifically has always seemed to me the worst of "agile", a system intentionally designed to turn the developer's experience into a fordist sweatshop cranking out as much productivity as possible, treating the developer like a commodified interchangeable part. It's like as if "economic efficiency over humanity" were part of the agile manifesto (it ain't).
But "scrum" specifically has always seemed to me the worst of "agile", a system intentionally designed to turn the developer's experience into a fordist sweatshop cranking out as much productivity as possible, treating the developer like a commodified interchangeable part. It's like as if "economic efficiency over humanity" were part of the agile manifesto (it ain't).
This reminds me of Dave Thomas' "Agile is Dead" talk:
https://www.youtube.com/watch?v=a-BOSpxYJ9M
https://www.youtube.com/watch?v=a-BOSpxYJ9M
I have more faith in empowered teams at least for companies where software is not the main focus.
For software companies, it makes sense to do more DevOps, how much depends on the company.
Scrum and all the events/meetings that go with it will certainly not be missed. That goes for SAFe as well.
For software companies, it makes sense to do more DevOps, how much depends on the company.
Scrum and all the events/meetings that go with it will certainly not be missed. That goes for SAFe as well.
SAFe has been nothing but a giant timesink for our company, but I guess our managers got certifications out of it. For our org, it added a day and a half of planning each 10 week period plus devs are now in roadmap meetings, which we never were in before.
We haven't increased in productivity. At all.
For our small dev staff, they've added over 1000 man-hours worth of meetings per year.
We haven't increased in productivity. At all.
For our small dev staff, they've added over 1000 man-hours worth of meetings per year.
Same for ours.
Fortunately for me, when I attended first PI planning (of 4 teams that have very slight interactions, and I do not care what they are doing and how, I care only that they give me APIs/deliverables) it was the last one.
My manager doesn't insist on me (or any other dev/qa) to attend those.
My manager doesn't insist on me (or any other dev/qa) to attend those.
scrum works great when it is about the teams getting things done and not letting things fall through the cracks. It fails quick when it becomes about scrum process and making sure the 3000 fields in Jira are filled out correctly and making sure every processes is done correctly.
It fails quick when it becomes about scrum process and making sure the 3000 fields in Jira are filled out correctly and making sure every processes is done correctly.
If management types had to go through the same process to add each field to a task or each step to a process in their tools that they expect their teams to go through to get any real development done the world would probably be a much more efficient place. What specific, immediate, measurable benefit is that extra field going to provide? How important is it compared to the other ones you suggested last month? How much effort will it require for the team to fill it in (measured in arbitrary units that everyone on the team can dispute subjectively)? How will you monitor the performance of the team in using the new field? We can have a retrospective in a couple of weeks scheduled right in the middle of the afternoon when you need to take a call with a potential huge customer to discuss the new field and then if it's not working very well we can ignore that meeting and not change anything anyway.
If management types had to go through the same process to add each field to a task or each step to a process in their tools that they expect their teams to go through to get any real development done the world would probably be a much more efficient place. What specific, immediate, measurable benefit is that extra field going to provide? How important is it compared to the other ones you suggested last month? How much effort will it require for the team to fill it in (measured in arbitrary units that everyone on the team can dispute subjectively)? How will you monitor the performance of the team in using the new field? We can have a retrospective in a couple of weeks scheduled right in the middle of the afternoon when you need to take a call with a potential huge customer to discuss the new field and then if it's not working very well we can ignore that meeting and not change anything anyway.
> What specific, immediate, measurable benefit is that extra field going to provide?
As more people turn to automation, I've seen people triggering actions based on field values or changes. And... the ever popular "reporting". It won't have an immediate benefit to you to have another 3 fields, but someone else can measure and chart and report some other set of data points because of those 3 fields. Usually there's not any real actionable benefits to come from that info, but you won't know for 3-6 months until you have a baseline then some comparison data, and by then - who wants to remove those fields?
As more people turn to automation, I've seen people triggering actions based on field values or changes. And... the ever popular "reporting". It won't have an immediate benefit to you to have another 3 fields, but someone else can measure and chart and report some other set of data points because of those 3 fields. Usually there's not any real actionable benefits to come from that info, but you won't know for 3-6 months until you have a baseline then some comparison data, and by then - who wants to remove those fields?
So no demonstrable advantage or actionable information then?
(This whole thread is - I hope - obviously /s. But the point behind it is real and serious. Far too often things like improving tooling or refactoring messy code at the end of a project that is now "working" don't get the time they should because bad management fails to realise that not everything is about immediate results. Meanwhile the same bad management has no problem steadily growing their own tools and processes - and using up ever more of their technical team's available time as a result - when there may be little or no demonstrable advantage to the business from doing so. Scrum is a textbook example of this problem.)
(This whole thread is - I hope - obviously /s. But the point behind it is real and serious. Far too often things like improving tooling or refactoring messy code at the end of a project that is now "working" don't get the time they should because bad management fails to realise that not everything is about immediate results. Meanwhile the same bad management has no problem steadily growing their own tools and processes - and using up ever more of their technical team's available time as a result - when there may be little or no demonstrable advantage to the business from doing so. Scrum is a textbook example of this problem.)
Most of the meetings for the SAFe process aren’t team oriented but collaboration oriented, to empower the team to work the way that’s best for them.
Teams within SAFe can use any methodology that they want, scrum, kanban, lean, etc.
The world outside of your dev team is what the other meetings are for: keeping business side informed of progress, checking in on cross team dependencies, deciding whether a change in plan needs to happen based on some unexpected problem, etc. That’s one of the reasons that SAFe insists on PI planning, it’s to consolidate as many meetings as possible into 2 days per quarter so they don’t invade every week as a back and forth.
When the business side and dev side of the house are communicating and on the same page, there’s a lot less friction in the work relationship.
Teams within SAFe can use any methodology that they want, scrum, kanban, lean, etc.
The world outside of your dev team is what the other meetings are for: keeping business side informed of progress, checking in on cross team dependencies, deciding whether a change in plan needs to happen based on some unexpected problem, etc. That’s one of the reasons that SAFe insists on PI planning, it’s to consolidate as many meetings as possible into 2 days per quarter so they don’t invade every week as a back and forth.
When the business side and dev side of the house are communicating and on the same page, there’s a lot less friction in the work relationship.
Looking at one software development agency I worked with for a large corporate client, everyone wanted to use Scrum, but there was massive inefficiency (maybe it was just the way they were doing it, although I've seen such things a few different companies now). The project managers at the customer were bright and competent, as were the team. Nobody was lazy. So why did they decide to work that way, and why did they put up with it?
I came to the conclusion Scrum offers two key advantages to the stakeholders on each side of a client/agency relationship:
- In a large company, mistakes are punished more harshly than successes are celebrated. (Mainly because your competition for the next promotion are going to promote your failures.) So it's important not to get things wrong. The most certain way to not get decisions wrong is to not decide anything at all. By using Scrum and planning only a sprint ahead, and not having any long-term vision, they achieve that.
- The agency is billing by time. The longer things take the better. If all their team spend 30% of their time on Scrum meetings (the amount I currently spend at my current employer), the manager of the agency sees that and isn't unhappy about the situation. Soon progress slows down and the customer requests more people get put on the project, the manager of the agency isn't unhappy about that either.
So both parties want to use Scrum, therefore of course an agreement is reached and Scrum is used.
It's not about delivering great software, or delivering it quickly, etc. Neither the middle manager at the customer nor the boss of an agency directly benefit from those things.
I came to the conclusion Scrum offers two key advantages to the stakeholders on each side of a client/agency relationship:
- In a large company, mistakes are punished more harshly than successes are celebrated. (Mainly because your competition for the next promotion are going to promote your failures.) So it's important not to get things wrong. The most certain way to not get decisions wrong is to not decide anything at all. By using Scrum and planning only a sprint ahead, and not having any long-term vision, they achieve that.
- The agency is billing by time. The longer things take the better. If all their team spend 30% of their time on Scrum meetings (the amount I currently spend at my current employer), the manager of the agency sees that and isn't unhappy about the situation. Soon progress slows down and the customer requests more people get put on the project, the manager of the agency isn't unhappy about that either.
So both parties want to use Scrum, therefore of course an agreement is reached and Scrum is used.
It's not about delivering great software, or delivering it quickly, etc. Neither the middle manager at the customer nor the boss of an agency directly benefit from those things.
> In a large company, mistakes are punished more harshly than successes are celebrated.
But isn't it always the case? The reason being: "we succeeded as we expected - move on, nothing to see here" vs "something failed, we need to discuss and find out who is to blame!"
But isn't it always the case? The reason being: "we succeeded as we expected - move on, nothing to see here" vs "something failed, we need to discuss and find out who is to blame!"
that's the definition of bullshit jobs, let's keep ourselves busy and pretend we are working on something meaningful
Just glancing at some of the comments, can't help but notice many (not all) of the "positive or pro scrum" comments are from what looks like "team-leads/scrum-masters/managers" ?
But, but... where would all the Scrum Masters go?!
They will co-opt the next revolution, just as they did this one.
Preferably, far away from me.
Promoted to Vice President
They just....... die?
Where the pocket calculators do?
So Silicon Heaven, then?
https://youtu.be/lm6YnAqPv4w
https://youtu.be/lm6YnAqPv4w
"I'll give you my HP Prime when you pry it from my cold, dead hands"
I’d argue that the Agile Principles are all you need, and that they are pretty much timeless. Really, please read through them: https://agilemanifesto.org/principles.html
Everything else tends to devolve into ceremony/dogma.
Everything else tends to devolve into ceremony/dogma.
Lucky me. I've ignored all this Agile/Scrum and had managed to live my coding life without all that religious looking "methodologies". In my life teams had always organized their work / communication organically. Whatever works for particular situation.
Anything that gets between me, the user, and the product manager, is a complete waste of time. Scrum masters, project managers, whatever your company calls them. They are the most counterproductive member to any team.
Disregarding the content (with which I mostly agree), this post could have used some more editing and tightening up. The introduction comes off a bit unfocused (it starts with the bold statement "the age of Scrum is over" and ends up with "is it? Time will tell"), the main text uses "its" where it should have used "it's" and vice versa. And "scupper" is "an opening cut through the bulwarks of a ship so that water falling on deck may flow overboard" - the word he was probably looking for is "scuttle"...
I’ve worked in this industry for 12 years and read every comment in this thread and I still have no idea wtf SCRUM is.
I read quite a few comments in this thread and I agree with many of them. For the most part, nobody really knows exactly what scrum is, and most companies equate it with Agile, but then again, there’s no real consensus on what Agile is either, since most of us practice some kind of bastardized and dogmatized version of it anyway. In one of the organizations I work with, it’s become so rigid that I literally just call it “Rigid” in meetings now. Why? Because it’s all about the metrics and what looks good to management, whereas it should be about the product snd the customer. It’s really, really difficult to move a User Story to another sprint or to change/add/delete tasks, or to update a story’s points, etc. because it will somehow disrupt the underpinnings of someone’s world (likely in the form of a spreadsheet). The end result is that we have to “game the system” by doing ridiculous acrobatics with the stories and tasks which in the end has the same net effect (the work either does or does not get done).
But Scrum/Agile is not the problem per se. People will find a way to dogmatize and adulterate any system to the point where it’s unrecognizable from its original form.
But Scrum/Agile is not the problem per se. People will find a way to dogmatize and adulterate any system to the point where it’s unrecognizable from its original form.
The article links to "101 Tactics for Revolutionaries", which wants a Wordpress login. Here it is in the Internet Archive: https://web.archive.org/web/20130413172018/https://thinkpurp...
I came to these conclusions about 6 years ago. But I think scrum has a place for inexperienced teams and managers to learn what processes work.
Apparently it came and went and I never understood what it was.
My team meets regularly are we scrumming? We ship quickly and iteratively, are we agile?
My team meets regularly are we scrumming? We ship quickly and iteratively, are we agile?
Scrum and Agile are like Monads, no one really knows what they are.
What don't you get about a monad in X is just a monoid in the category of endofunctors of X, with product × replaced by composition of endofunctors and unit set by the identity endofunctor.
Monads are when you have more than a single nad... /s
Yes, but you're not "Scrumming" and "Agile" with capital letters. And that's a good thing, because then you wouldn't be "agile" anymore.
I actually like Scrum, but holding onto it too tightly is a big mistake, IMO.
I actually like Scrum, but holding onto it too tightly is a big mistake, IMO.
What alternatives have people come across? I know there is waterfall: months of planning followed by months of implementation, followed by a single deployment at the very end. Then there is the gradient of in-betweens along the line of scrum to waterfall. I've not encountered any other methodologies yet.
There's more than one AGILE methodology. SCRUM is only one of several. Probably if you're doing SCRUM you're using techniques from some of the others, so you might not see the distinction. Look 'em up. KANBAN, for example.
A whole lot of organizations, particularly gelled teams at them, do some variation of "plan, iterate, ship": https://blog.pragmaticengineer.com/project-management-at-big...
AGILE consultants did not invent iterative development, by the way.
I have never seen any process actually followed that looks like the AGILE consultants' caricature of "waterfall". The more serious you get, though, about defining requirements up front and making sure you meet them, the more your process will look like traditional systems engineering and stage gates. This does not preclude iterative work - the buzzword decades ago was the "spiral model".
A whole lot of organizations, particularly gelled teams at them, do some variation of "plan, iterate, ship": https://blog.pragmaticengineer.com/project-management-at-big...
AGILE consultants did not invent iterative development, by the way.
I have never seen any process actually followed that looks like the AGILE consultants' caricature of "waterfall". The more serious you get, though, about defining requirements up front and making sure you meet them, the more your process will look like traditional systems engineering and stage gates. This does not preclude iterative work - the buzzword decades ago was the "spiral model".
Shape Up seems to have been gaining traction: https://basecamp.com/shapeup/webbook
in my opinion, it feels more like agile than Agile™
in my opinion, it feels more like agile than Agile™
XP - http://www.extremeprogramming.org/
ShapeUp, as n42 commented - https://news.ycombinator.com/item?id=31534642
Product Development Flow by Don Reinertsen - http://reinertsenassociates.com/books/
Queueing Theory - https://en.m.wikipedia.org/wiki/Queueing_theory
ShapeUp, as n42 commented - https://news.ycombinator.com/item?id=31534642
Product Development Flow by Don Reinertsen - http://reinertsenassociates.com/books/
Queueing Theory - https://en.m.wikipedia.org/wiki/Queueing_theory
So what will come after Scrum? Is anyone here working in a "post-Scrum" world? What does it look like?
I've been working in a "post-Scrum" world I suppose in that I have not used it prescriptively for software development in a very long time.
It isn't terribly exciting stuff. Simply remove the unnecessary ceremonies and "rituals" and instead focus on practical and effective solutions to the problems you actually have. Continuously try out new ways of building the software better, measure your results, continue to improve. The heart of the agile manifesto I suppose.
It isn't terribly exciting stuff. Simply remove the unnecessary ceremonies and "rituals" and instead focus on practical and effective solutions to the problems you actually have. Continuously try out new ways of building the software better, measure your results, continue to improve. The heart of the agile manifesto I suppose.
> measure your results ... The heart of the agile manifesto I suppose
That's an interesting one. I don't know if Scrum teams I've been part of are doing this wrong, but I have seen a shocking lack of measurement going on. Much less than with even waterfall.
Whereas with a waterfall approach from decades past one might have a deadline and know if one has hit it or not, or a budget and know if one has overrun or not, the product managers at most Scrum teams I've worked with recently wouldn't be able to tell you what % of time is spent in Scrum ritual meetings, whether the project is overrun or not (as we only plan one sprint ahead, and the project is going to take more than one sprint), what % of time was actually spent on what project in the last sprint (or over the last quarter), what % of time was split between requirements, dev, ops, or any other task, etc.
Has your experience with agile been different? Or am I misunderstanding what you mean by measurement?
That's an interesting one. I don't know if Scrum teams I've been part of are doing this wrong, but I have seen a shocking lack of measurement going on. Much less than with even waterfall.
Whereas with a waterfall approach from decades past one might have a deadline and know if one has hit it or not, or a budget and know if one has overrun or not, the product managers at most Scrum teams I've worked with recently wouldn't be able to tell you what % of time is spent in Scrum ritual meetings, whether the project is overrun or not (as we only plan one sprint ahead, and the project is going to take more than one sprint), what % of time was actually spent on what project in the last sprint (or over the last quarter), what % of time was split between requirements, dev, ops, or any other task, etc.
Has your experience with agile been different? Or am I misunderstanding what you mean by measurement?
Sounds about right with my own experience.
I believe that each team is most productive in their own ways. In the pursuit of that, it becomes harder to measure productivity.
While approaches like agile or waterfall won't fit for many people, it does make it easy to track everything since you know what's going to happen.
I believe that each team is most productive in their own ways. In the pursuit of that, it becomes harder to measure productivity.
While approaches like agile or waterfall won't fit for many people, it does make it easy to track everything since you know what's going to happen.
Agile, but reinvented, until it becomes full of gurus, coaches, and certifications, at which point we will declare it dead and continue to reinvent the saming manfucturing system we've had since Deming in the early 1950s.
In my experience, Scrum is something leadership and project managers never really commit to ("agile with a small 'a'") and never really adhere to its principles. When it inevitably fails, they blame agile and go back to waterfall and wonder why engineers are unhappy.
Scrums sucked the life out of creative programing.
Been lucky enough to only be exposed to scrum in training course.
Every team I've been apart of at multiple companies has been a team process around common sense, what works for the team, transparency and openness to suggestions and change.
Every team I've been apart of at multiple companies has been a team process around common sense, what works for the team, transparency and openness to suggestions and change.
Scrum was always very strange, a little package of dogmatic practice as a way (supposedly) to implement a highly adaptive methodology.
This claim probably means we are soon to be at peak scrum. Maybe the earlier adopter companies are will be onto the new thing ... but right now we are just finishing up getting all the trailing firms to finally switch over from waterfall ...
Adoption is 5 years behind thought leadership.
Adoption is 5 years behind thought leadership.
[deleted]
[deleted]
Honest question: Is this worth discussing anymore in the abstract, versus in a place, doing a thing, with the people involved?
> "It’s easier to explain price once than to apologize for quality forever." - Zig Ziglar
What a great quote.
What a great quote.
scrum encourages cult-like behaviours
I never understood the need for these frameworks. Every time I try to read into it, it seems to make the assumption that your team are a bunch of children who can't manage their own tasks and escalate issues as they come up.
Write up a plan, get it approved, build it, release it. Escalate blockers or issues along the way and adjust as needed. I guess it's closest to agile but I just see it as... being an adult and doing your job?
All this process seems to just stress everyone out.
Write up a plan, get it approved, build it, release it. Escalate blockers or issues along the way and adjust as needed. I guess it's closest to agile but I just see it as... being an adult and doing your job?
All this process seems to just stress everyone out.
> it seems to make the assumption that your team are a bunch of children who can't manage their own tasks and escalate issues as they come up
Well, yes. Welcome to the last 150 years of management philosophy.
Well, yes. Welcome to the last 150 years of management philosophy.
[deleted]
lol the monoliths are going nowhere. scrum, rails, mainframes. whatevs.
Scrum is dead. Long line kanban!
Someone should tell my employer
Scrum masters are a disease, rotten to the core.
Scrum Elon Doge to the moon!
I think you should be careful about what you wish for. I've been in the alternative which is "nothing" and "waterfall" and scrum is a thousand years better than those two.
I’ll take “nothing” over scrum anyday.
I will communicate with my colleagues and stakeholders and deal with what needs to be dealt with, vs more meetings with religious fundamentalists who don’t actually appear to code much.
scrum is basically a way to provide fake jobs to many people, this allow them to avoid doing useful work and qualified work, like coding. The same applies to non-technical product owners.
They are absolut frauds and will definitely not got to heaven, if there's one.
There's something even more hellish and that is Scaled Agile Framework.
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?