The age of Scrum is over
chrisjameslennon.medium.com
chrisjameslennon.medium.com
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?
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".
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.
So how is it any better?
I found this truly sad. If you want accurate "velocity", you need to track it accurately. Our estimates were wrong.
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.
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.
Can you describe "OKR lead management"? I am familiar with OKRs.
Dealing with anything social, the rules don't self enforce - they aren't gravity.
You need to use tools like OKRs and good old waterfall to manage multiple team projects.
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.
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.
> Individuals and interactions over processes and tools
> Working software over comprehensive documentation
> Customer collaboration over contract negotiation
> Responding to change over following a plan
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.
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.
By all means collaborate, but put it in a contract too.
The key is understanding the upfront spec, while a necessary stating point, is almost certainly wrong, maybe fundamentally so. So how are renegotiations handled?
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)
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.
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.
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?
Somehow the things in the Agile Manifesto never popularized, only those religions did.
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.
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.
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.
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.
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.
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 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.
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.
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
"What should we stop doing?" "This." (The retro.)
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.
That's is. SCRUM is an emergency mode operation technique that might work to sort out standard things, definitively not creating something new.
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”.
People get so caught up in the process trappings of "agile" they miss the point.
"Agile" teams outnumber agile teams by a large margin.
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.
And what makes them high performing? What is the metric? Money?
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.
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.
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.
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.
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.
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.
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.
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.
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.
Retros are a big waste of time about 95% of the time.
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.
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.
classic Scrum statement - putting the blame again on teams. A team usually has no power to change anything that matters.
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.)
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.
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.
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.
I like your idea.
"Having no process at all" beats "Performative Scrum".
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".
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.
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.
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.
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.
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.
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 :)
I’d probably reevaluate what it is you’re trying to achieve from a retrospective and listen to the team.
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.
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
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.
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.
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
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
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.
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 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
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".
> a prescriptive product development framework that works for all software development
_edit_: Adapted or removed or reinvented.
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.
Every time I worked with certified Scrum Masters I had exactly the same struggles.
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.
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.
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.
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.
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...
As an EM, Scrum notes log of what people have been working on which is helping for reviewing during performance management.
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.
At least that's what the proponents say when anyone points out any issue at all with anything agile.
> 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?
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.
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).
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.
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.
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.
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?
(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.)
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.
My manager doesn't insist on me (or any other dev/qa) to attend those.
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.
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!"
Everything else tends to devolve into ceremony/dogma.
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.
My team meets regularly are we scrumming? We ship quickly and iteratively, are we agile?
I actually like Scrum, but holding onto it too tightly is a big mistake, IMO.
in my opinion, it feels more like agile than Agile™
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".
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
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.
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?
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.
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.
Adoption is 5 years behind thought leadership.
What a great quote.
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.
Well, yes. Welcome to the last 150 years of management philosophy.