I've learned to hate software process. If you have team sizes set sanely and empower devs to do what they need to do in order to accomplish the goal, they'll be fine without the management overhead of arbitrarily imposed productivity flow. Agile et al, along with 99% of the features in ticketing systems, exist to make managers feel like they are justifying their paycheck.
If you are a manager and this makes you angry, you're one of the bad ones.
All of these methodologies (and most formal software architectures as well) have as a their main sales pitch the idea that you can hire average/entry-level developers and build good software with reduced defects and on a defined schedule if you only follow these magic guidelines.
It refuses to learn from The Mythical Man-Month and recognize that building software has an essential complexity that cannot be avoided. You need smart people to implement and manage it, and you'll have to pay them what the market says they are worth.
Building software that's more complicated than a standalone CRUD system is hard, it will always be hard, and unpredictable, and to some degree stressful. No methodology will ever make it anything else because the methodology used doesn't change the nature of the problem.
Just keep in mind that a lot of people equate Agile with Scrum, which is incorrect. Agile is about exactly what you said: empowering devs to get shit done. None of the extra “keep managers happy” crap that Scrum introduces is in any way covered by the Agile manifesto.
From experience i haven’t come across any “agile” organization that runs true to the manifesto.
There’s been plenty of discussions why the “what could have been” got buried in certain people jumping in, creating weird layers and interpretations of some process for their own profit and ego.
We use Agile at our company and let me tell you, it sucks. Maybe straight up scrum would be worse, but honestly agile is invasive and just feels like you’re being babysat and forcing people to give BS updates at standups because they’re afraid of sounding unproductive.
"Keep managers happy" isn't part of Scrum, either. If you read any of the Scrum books by the creators of Scrum, you'll find that the way 95% of companies implement Scrum is nothing like what Scrum was intended to be. They mess it up, essentially in the name of marketing, and not wanting to truly change their ways.
> Agile is about exactly what you said: empowering devs to get shit done.
Sure, that's the goal. In reality, though, that's very nearly never what it does in practice. That's why I have come to view "agile" shops with an extremely skeptical eye.
But what does it mean to "empower devs". Do you give them requirements and say I'll check in on deadline day in 6 months?
Presumably you would still use iterations to track progress, Epics/Features to break down requirements, some kind of estimation to track if you're ahead/behind schedule?
I certainly wouldn't go back to Waterfall days, but I suspect many current devs never experienced that.
- One on Ones to discuss roadblocks and thoughts every week.
- Issue tracking as a common place to describe what needs to be done and thoughts / details on how it is solved. Something lightweight like Trello is ideal
- A Kanban board so people have an organised way to pick up new issues when low on work
- A weekly showoff meeting where there are few 5 minute presentations and a 30 minute "I did something really cool or learned something really cool"
- 6 month task split into 1 month ish deliverables, with a flexible deadline for each. Presentation of finished work each deliverable.
There’s a world of difference between checking back in 6 months and daily standup meetings + a host of weekly meetings.
If you don’t trust your team to be productive for 2 weeks without communication something is deeply wrong. Individuals should be in constant communication, but few things need to be said to everyone. Scrum style management may be useful for highly dysfunctional teams, but it frequently adds a great deal of unnecessary overhead.
That’s no easy feat and often oversimplifies the challenge of building competent teams. I think it’s achievable if you have a large budget to hire only senior/experienced devs and a mature hiring process/team. Plus, if your company has strong tech branding, it becomes easier to attract top talent too.
But if you’re at a startup with limited funding and possibly no branding at all, you’ll likely face this situation:
- Hire inexperienced but honest, motivated people with the potential to grow, and invest in mentoring them.
It seems we go astray when we start defining and evangelizing things that may have worked for some group of people to push them on others.
Somewhere in all this process stuff, I see maybe what some teams were doing but I doubt it was as rigid and I doubt they indulged in it when it made no sense. Once these teams or people are asked what they're doing right - it eventually gets defined into rules and then evangelized to people made to feel they can't deviate or improvise when the framework makes no sense. "Trust the process."
So people start wasting their time going through the process rather than using the process as a framework/tool for getting things done, they 'do' the process.
Their job is standup, their job is scrum, tickets, and points, and as a result their job is only marginally to do the things that need doing.
Company's might take more issue with this inefficiency if the workforce didn't double as something to manipulate pre and post head/tailwind to make the stock rise.
Pizza sized teams that can directly interact with customers don't need management. Management is playing telephone with someone in the middle with their own interpretation of everything which is 99% wrong.
It sounds like you've had bad management (like we all have). Good EMs will unblock you, deal with conflicting priorities from stakeholders, provide you with air cover to have focus time, and help manage your career growth (among other things). If your EM isn't doing that, find another one.
Sounds like you mix up management with product people.
Product people are not management at least not where I worked.
I see how it might be a problem if your manager is talking to the customers.
Product people are or should be equal to dev, engineering. They should indicate priorities but should not in any way evaluate engineers especially if they have no technical expertise.
The reality is even good devs tend to work hard on the wrong thing. Accountability comes from your peers as much as your manager. If this makes you angry you are one of the bad ones.
Everyone tends to work hard on the wrong thing if it what they like to do most currently. Everyone. A conversation is all that is needed to remind them of the team priority, non need to create a creativity carcan with processes.
Give good devs a direct line to the customer and they're apt to always work on the right thing, but will spend a lot more time dealing with the customer and a lot less time in development in order to do so.
Leave good devs to play telephone through a middle-man, what we call the manager, and they almost certainly will work on the wrong things, but will have a lot more time to do it.
I wonder which is actually more productive? Agile (of the Manifesto kind) posits that the former is most productive, but Agile (of the fake kind) seems to always want to revolve around the latter. The general sentiment is that fake Agile is the one that gets it wrong, so presumably cutting out the manager is what is most productive, but more data is welcome.
I've heard a lot of push back against all kinds of process on this forum, and it always surprises me.
But reading the article made something click: it is not about the specific process, the (lack of) autonomy is what really matters. I guess I got lucky to work a lot in teams where we largely controlled our own process, so even if we used bits and pieces of scrum, kanban or other methodologies, it was always of our collective choosing and when it didn't work, we changed it.
I did like to have rules, principles and process. A simple playbook for a daily meeting that made us not forget important things and sped up the meeting. Making things in small increments meant that I didn't have to review thousands of lines of code. Having a visual overview of work neatly spelled out means I don't have to re-think every time I pick up a new item to work on. This also prevents useless work because one of your teammates decides to work on the same thing as you without telling it. All these things make me happier and more productive working together on some big thing.
The key is that the team should be in control of the process, not some manager who isn't part of the team and affected by the process. You need to have a stake in it. The only other factor that undermines this is 'process for the sake of process'. Every part of the process needs to earn the inevitable cost its implementation is bringing. Some people seem to be happy paying the pricing without getting the value.
My first and second experiences with Scrum couldn't be more different. And they were successive. Actually, they happened on the same team, same people, same project.
Before: the team had internally decided to use Scrum. Other teams were not using it, and inter-team coordination used traditional project management methods. It was fantastic; the team worked like a well-oiled machine and I really did feel more productive. We never had crunch time. I did not feel the "end-of-sprint mini crunch" that this post describes; instead the norm was that, by the last couple days of the sprint, people were starting to finish up whatever tickets they had taken and pivoting to helping teammates get the rest of the work done. Oftentimes we'd close out all the user stories a day or so before the end of the sprint, and have all that time for tidying up the codebase, fixing small technical debt items, experimenting with new tools, or planning ahead for the next sprint. So, if anything, it was the opposite of what the article describes: the last few days of every sprint were downright relaxing.
After: The executives got wind of Scrum, and decided to standardize the whole company on it. We stopped work for a week so that we could have a famous Agile coach do an all-hands Scrum workshop. Which was fun, but the middle and senior managers were conspicuously absent. And then, after that, things kind of went to heck. The way our team did Scrum rapidly started to change as our team manager started getting explicit instructions on how to do things. We also started experiencing pressure to keep or maintain velocity. We started getting questions about why our velocity was so much different from other teams'. We could explain that the story point scale is team-specific and you can't compare story points across teams, but that didn't go anywhere. As I said, the middle and upper managers skipped the Scrum training. They weren't interested in being lectured about what I'm sure they perceived as pedantic little bullshit details.
I left that company and went to another where leadership didn't mandate any Agile methodology. My team did a homegrown Kanban-like thing. A team I collaborated closely with used Scrum. It also seemed to work pretty great. Again, possibly because we chose it for ourselves. I don't think the other team would have done as well on Kanban. Scrum wouldn't have worked so well for our team. I didn't see a problem with that. We each had different business domains that warranted very different "rules of engagement" with our stakeholders and ways of organizing the work.
Since then it's been a couple more companies where "Agile" was mandated from the top, and, apologies to Tolstoy, but they were both miserable in the same way that the first one was after the Scrum mandate got handed down from above.
“What kind of runner can run as fast as they possibly can from the very start of a race? Only someone who runs very short distances. But we’re programmers, we’re smarter than runners. We know how to fix that problem, we just fire the starting pistol every hundred yards, and call it a new sprint!”
The Scrum Master is supposed to be part of the team, constantly helping with the Sprint, whether that's getting clarification for you, or pushing back on unrealistic expectations, or getting more resources, or whatever. Sprint was a bad choice of terms. It shouldn't have been related to races at all. If anything, it should be more like walking. It's about figuring out what pace is sustainable for your particular team, and sticking to that pace. Not driving anyone too hard, but delivering value (i.e. working software features and updates) at regular intervals. If a feature is too big to deliver in a single increment of time (Sprint), then it should be broken down into multiple features that build upon one another to eventually be the whole thing.
I think back to the early 2000's, and there are other factors in play as well. Back then, I worked with a team of engineers that stayed together for over 4 years. In that time, we did not have Project Managers telling us to do daily standups. We met as an engineering team.
We often would go days without having a formal meeting.
But, software was different then as well. Everything is interconnected now. One team dropping the ball affects countless other teams. Deployments were whenever we felt a new one was due or at a multi month cadence. Did this introduce problems, yes, but at the same time, they came in controlled release cycles.
Nothing against CI/CD and continuous delivery, but the hamster wheel has gotten to a point where we have to release all the time. Corners are cut on everything, and testing is given lip service.
At this point, I am a manager, and SCRUM stresses me out. Either let us work from a queue, or give us a project with a deadline. Give me back a stupid gant or pert chart. At least then it was, is this done to allow XYZ, not we are going to accomplish this in the next 2 (arbitrary) weeks.
> Nothing against CI/CD and continuous delivery, but the hamster wheel has gotten to a point where we have to release all the time. Corners are cut on everything, and testing is given lip service.
Just to call it out: Having CI/CD doesn't mean you have to do all these things, or do scrum. It's imho just good engineering practice. I have it in my side projects, and I've had it at work on a Kanban-driven team (as well as on scrum).
It removes disputes over build process (eg, nobody can ever say "well, it complies on my machine"). It is a form of build/deploy documentation. It removes bottlenecks ("only Tom knows how to deploy that service, but he's on vacation") and stupid mistakes ("whoever deployed this last did it wrong and left a bunch of old files around").
I also have found deploying regularly is stress-reducing. For one, with CD the development environment is running the same steps, and we know it works because we do it dozens of times a week. The longer it's been since last prod deploy, the less confident we can be it'll go smoothly, whereas when it gets deployed every few days it becomes a non-event.
When something breaks, having only 1 or 3 changes makes it really easy to figure out why. Recovering after a big release with 40 PRs in it is absolutely painful.
None of this means you have to release everything on a regular schedule (like a sprint). You can still do long running branches or feature-flag things off, Just try not to go too long without deploying something.
> When something breaks, having only 1 or 3 changes makes it really easy to figure out why. Recovering after a big release with 40 PRs in it is absolutely painful.
This is, by far, the most important reason to practice continuous deployment. I've been part of enough of these fire fighting sessions following big releases to see that it's not a sustainable way to deploy software. And yet, I've never been able to convince any boss I've ever had to adopt CD because they're worried it'll introduce more regressions into production.
In the nearly 30 years of doing this, I’ve had more success delivering good quality software that meets business requirements under waterfall than any of the SCRUM implementations I’ve worked with, and I am saying that without disagreeing that waterfall has its problems. In the agile space, kanban is the only one I’ve felt is productive, but it has trouble scaling to multiple teams.
In my experience, waterfall forces business to think more about the project and plan accordingly. They have to think about how this feature interacts with this other feature. Business also usually has a better understanding of how the software will work because of the planning phase.
In my experience, with 2 week sprints, the business doesn't really have to think about anything outside of bite sized chunks or even how those bite sized chunks affect later bite sized chunks. They can make a snap decision without thinking about it because it can be rectified in the next sprint. Almost no-one has a "big picture," view of the software.
Before agile, we essentially did 4 releases a month (this was back on the burn a CD days), 2 major releases and 2 minor patch releases. It worked really well and we didn't get the burnout as much by sprinting a marathon. With sprints, I always feel burned out. No sense of accomplishment, no letup, working hard just gets you more work. It's like laying bricks one at a time on a wall with unlimited length.
It's one reason I'm really thankful to work in a certified/regulated industry. It's mandated to effectively prove your work to get the sign off. And since you can't really sell too well in the area without that cert, it's a big part of development.
But holy hell is it still hard to get specific people to test their work. They just don't even think about it.
ex manager here. managers are in an even worse wheel. biz demands managers show up to even _dumber_, less organized meetings than devs think they have to deal with. eng to eng meetings tend to be fine, but the rest of company culture at BigCorp weren’t trained in structured problem solving. it’s negotiating with goldfish half of the time (generally friendly goldfish), and no one actually practices any formalisms or larger cohesive pjm. “just give me a gantt” like the author says would be an absolutely monumental improvement from how i see things get done
I’ve been building software applications for 40 years. No matter how you slice up the work, we all have to demonstrate progress and goal achievement.
Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success.
In a lot of cases there is a client or a customer that requires regular progress reports. Management uses reports to measure team performance.
I’m not sure what planet the OP is from, but this will never change. If you have a small team with a simple codebase, kanban is probably sufficient. In larger teams or complex solutions, the reporting just needs to happen.
The post is fundamentally about all the performance of making stories, assigning points, allocating work and doing standups all the time. None of that is required to actually create software.
If people are judgemental around what stories are left uncompleted or points / week then the situation can become stressful for no benefit to anyone.
>> None of that is required to actually create software.
Agreed. (Assuming you mean "create" as in write, as distinct from create as in get funded.)
>> If people are judgemental around what stories are left uncompleted or points / week then the situation can become stressful for no benefit to anyone.
Clearly no stress is better. But these things create stress in the other direction too. Slower than expected progress, the existence of "intractable problems", work going unfinished creates significant stress up the ladder.
In a perfect world the dev team is given a perfect spec, and a reasonable time to do it in, and after being "left alone" they deliver the finished product on time.
Given that that world doesn't exist, given that the "money we're spending" may turn out to be completely wasted (because the spec was wrong, or because the problem us much harder than anticipated), the ideal case seems unlikely to happen.
I say this not as a defense of crappy management processes, or even less as a defense of crappy managers, but rather in the spirit that understanding the problem goes a long way to solving it.
And yes, many places have bad processes and bad middle managers. I don't envy you that. But finding a way to better solve the manager's problem typically improves the relationship.
Scrum/Agile is basically an answer for things that went wrong in the past. Building software has a long history of delays, running over time, running out of budgets, etc. As a stakeholder/customer, you need certainties up front: how long is it going to take, what is it going to cost? And if you think this isn't reasonable, just consider, would you hire a contractor to work on your house that can't tell you up front cost and duration?
Anybody doing work needs to be able to estimate duration, progress, risk of delays, etc. Other people's work depends on your deadlines. Go/no go of a project depends on cost and duration.
Insight and tracking is required. None of this was done any better before agile.
Assigning Points = Roughly estimating how long it takes you to implement it
Allocating Work = Well... allocating work
Standups = Talking with your colleagues about the current work and clearing problems
Reviews = Showing your results
None of that seems unreasonable. The only thing that kinda sucks are the rigid sprints, because they just cause artificial stress by setting unnecessary deadlines.
I don't feel anything you've said is logical. The deliverable is, in the best case, what communicates progress and success. Short of that, tickets can do that, which is also not what the article is complaining about. The article also specifically attacks Agile/Scrum; Kanban is different and quite explicitly sidesteps a lot of the stress problems the article outlines.
> Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success.
In the agile teams I've been on it's been to produce success. Getting good and useful software fast.
Of course, just like there are hundreds of wildly different Christian sub-religions, there are now any number of "agile" interpretations. In the end belief systems can be pushed to do most anything you want.
Yeah, I totally agree in theory, it doesn't really matter what methodology you use, at the end of the day dev management is just a means to an end.
The real issue comes from middle management folks who conjure up buzzwords whenever they need to justify whatever they think the team should do. Don't know how to structure tasks but want to look like you're in control to the boss's boss? Just throw up a Kanban board with tiny tickets and a burndown chart trending down. Sprinkle in some Agile keywords in the management reports and call it a day. And let's not forget that by 'sprint' they often mean moving unfinished tickets from the last iteration to the current one, plus tacking on surprise urgent tasks that were not planned before because the product owner never shows up to share their vision and priorities.
Out of the 8 companies I've worked at as a product engineer, the most successful framework to deliver tangible results has been Basecamp's Shape Up approach. Engineering managers always ask "how many days" of effort when the real question they should be asking is "how much appetite"/"how long do we want to spend" on the particular product/feature we want to build? The Shape Up framework was the only time I didn't feel constantly stressed and it actually provided time to cooldown between the six week cycles. And the fact is it actually led to very successful product deliveries consistently. For those interested here's a link to it https://basecamp.com/shapeup/0.3-chapter-01.
What I dislike about SCRUM specifically is that if you're having a rough week at home, recovering from illness or you just have things to do outside of work, you can't really just have an easy week and make up for it later on. It's a kind of constant grind and we always have a way of "filling up" our sprint. If we don't meet our target, it always feels like a fail. I know it shouldn't feel like that but it's human nature.
Maybe having "easy" sprints would work?
There are benefits too, just that constant grind aspect is why I believe it's mostly a temporary endeavor. After 6-12 months most teams seem to just do something else then come back to it once a new manager joins.
> The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.
The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
If what you are doing doesn't match that, then it's not a Scrum stand-up.
I just find American corporate culture to be 90% about participation, not really results, but being there, being a "team player" and being really nice to everyone. Not necessarily bad things, but compared to Australian work culture (for example), America is really about "the teaaarrrmm".
> If we don't meet our target, it always feels like a fail. I know it shouldn't feel like that but it's human nature.
It definitely is human nature, and beyond that we're so trained to focus on goals and take them seriously that the "sprint goals" actually feel weaponized to me in order to get people to self-motivate/drive themselves. In the Scrum world engineers are fungible, so if one burns up or stops performing, you just replace them with a new one.
Also that "rough week at home" is going to show up on metrics for a very long time. A good manager understands the ebb and flow, but many do not. It also doesn't help that the Certified ScrumMaster® people will put so much emphasis on smoothness and consistency, and when it doesn't happen there's always someone/something to blame. When you remove the context (like team lead who knows what happened) and put it in a quarterly chart for upper management, you get a lot of bad and counter-productive conclusions.
The sprint goal is a team target. If you're sick that shouldn't endanger the sprint goal because anyone in the team can pick up any work. Of course in mediocre or low-performing teams that's almost never the case but still not the fault of a product framework
What you say works 100% for trivial CRUD applications. Which is also, where SCRUM is still a bad framework, but at least SCRUM works on this trivial level of software development.
When a project is about non trivial projects, people, especially developers can not be easily replaced, because no one can replace a specialist with several years of experience on the spot. What I can archive in one day and what somebody else can archive on a day highly depends on what it is. Write a field to the database? Works. Write a rule engine? I'll probably be a factor of 10x more productive than an average developer. Write some GUI/CSS? A frontend developer is 10x more productive than me.
This seems like a disingenuous answer to me - the rest of the team will take up the slack? And if they can't they must be a low-performing team?
The OP may have some things wrong, but the 'constant grind' aspect of scrum sprints is spot on, there is no slack.
Add to that the 'radical transparency' aspect of scrum. That works great among a tight-knit team, but it can be insidious and actually self-defeating when certain types of manager get involved and weaponize it.
I'm sure there are many people who love programming, but hate being a programmer as a job, and to some extent that has always been true, but scrum seems in many cases to make it much, much worse, IMHO. The attitude displayed here is exactly the problem.
This doesn't apply for pod-based systems though, does it? They were everywhere for years there and are still very common. Basically by definition there's only one or two people that can do each task.
We don't do agile, scrum, standups, etc. We meet 1x week to review where we're at and establish/re-establish priorities for the week if needed, use a ticket system for tasks to track progress, a high-level "weekly goals" shared doc, communicate on Slack as needed, and let the devs actually do the f'ing work the way they know best. If someone can't self-manage and produce without a manager over them, or reach out if they've hit a blocker (due to their own limitations or someone else's) they are not the right fit for us.
IMO, if you're a SWE/dev and spending more time doing other stuff (meetings, TPS reports, etc.) than coding (coding includes the time needed to research, experiment and think of good solutions, not just actual coding), then something is wrong.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Back when Scrum was new I already wondered how it could make sense to make developers be constantly sprinting. I mean it's right there in the word choice. You can't sprint all the time! A sprint is short and fast and then you rest. Making everything in work life be only sprints is madness.
Heh, I say the same thing nearly every time a meta-discussion on Scrum/sprints is had. As a former sprint-runner, it irritates me to no end that nobody sees a problem with sprinting all the time...
Readit News
If you are a manager and this makes you angry, you're one of the bad ones.
It refuses to learn from The Mythical Man-Month and recognize that building software has an essential complexity that cannot be avoided. You need smart people to implement and manage it, and you'll have to pay them what the market says they are worth.
Building software that's more complicated than a standalone CRUD system is hard, it will always be hard, and unpredictable, and to some degree stressful. No methodology will ever make it anything else because the methodology used doesn't change the nature of the problem.
There’s been plenty of discussions why the “what could have been” got buried in certain people jumping in, creating weird layers and interpretations of some process for their own profit and ego.
Chinese whispers then lost in translation.
2) no matter what "agile" was supposed to mean - managers anyway interpret it as devs having to be very agile for them all the time ...
Sure, that's the goal. In reality, though, that's very nearly never what it does in practice. That's why I have come to view "agile" shops with an extremely skeptical eye.
Dead Comment
Presumably you would still use iterations to track progress, Epics/Features to break down requirements, some kind of estimation to track if you're ahead/behind schedule?
I certainly wouldn't go back to Waterfall days, but I suspect many current devs never experienced that.
- Issue tracking as a common place to describe what needs to be done and thoughts / details on how it is solved. Something lightweight like Trello is ideal
- A Kanban board so people have an organised way to pick up new issues when low on work
- A weekly showoff meeting where there are few 5 minute presentations and a 30 minute "I did something really cool or learned something really cool"
- 6 month task split into 1 month ish deliverables, with a flexible deadline for each. Presentation of finished work each deliverable.
If you don’t trust your team to be productive for 2 weeks without communication something is deeply wrong. Individuals should be in constant communication, but few things need to be said to everyone. Scrum style management may be useful for highly dysfunctional teams, but it frequently adds a great deal of unnecessary overhead.
That’s no easy feat and often oversimplifies the challenge of building competent teams. I think it’s achievable if you have a large budget to hire only senior/experienced devs and a mature hiring process/team. Plus, if your company has strong tech branding, it becomes easier to attract top talent too.
But if you’re at a startup with limited funding and possibly no branding at all, you’ll likely face this situation:
- Hire inexperienced but honest, motivated people with the potential to grow, and invest in mentoring them.
Somewhere in all this process stuff, I see maybe what some teams were doing but I doubt it was as rigid and I doubt they indulged in it when it made no sense. Once these teams or people are asked what they're doing right - it eventually gets defined into rules and then evangelized to people made to feel they can't deviate or improvise when the framework makes no sense. "Trust the process."
So people start wasting their time going through the process rather than using the process as a framework/tool for getting things done, they 'do' the process.
Their job is standup, their job is scrum, tickets, and points, and as a result their job is only marginally to do the things that need doing.
Company's might take more issue with this inefficiency if the workforce didn't double as something to manipulate pre and post head/tailwind to make the stock rise.
Product people are not management at least not where I worked.
I see how it might be a problem if your manager is talking to the customers.
Product people are or should be equal to dev, engineering. They should indicate priorities but should not in any way evaluate engineers especially if they have no technical expertise.
Leave good devs to play telephone through a middle-man, what we call the manager, and they almost certainly will work on the wrong things, but will have a lot more time to do it.
I wonder which is actually more productive? Agile (of the Manifesto kind) posits that the former is most productive, but Agile (of the fake kind) seems to always want to revolve around the latter. The general sentiment is that fake Agile is the one that gets it wrong, so presumably cutting out the manager is what is most productive, but more data is welcome.
But reading the article made something click: it is not about the specific process, the (lack of) autonomy is what really matters. I guess I got lucky to work a lot in teams where we largely controlled our own process, so even if we used bits and pieces of scrum, kanban or other methodologies, it was always of our collective choosing and when it didn't work, we changed it.
I did like to have rules, principles and process. A simple playbook for a daily meeting that made us not forget important things and sped up the meeting. Making things in small increments meant that I didn't have to review thousands of lines of code. Having a visual overview of work neatly spelled out means I don't have to re-think every time I pick up a new item to work on. This also prevents useless work because one of your teammates decides to work on the same thing as you without telling it. All these things make me happier and more productive working together on some big thing.
The key is that the team should be in control of the process, not some manager who isn't part of the team and affected by the process. You need to have a stake in it. The only other factor that undermines this is 'process for the sake of process'. Every part of the process needs to earn the inevitable cost its implementation is bringing. Some people seem to be happy paying the pricing without getting the value.
Before: the team had internally decided to use Scrum. Other teams were not using it, and inter-team coordination used traditional project management methods. It was fantastic; the team worked like a well-oiled machine and I really did feel more productive. We never had crunch time. I did not feel the "end-of-sprint mini crunch" that this post describes; instead the norm was that, by the last couple days of the sprint, people were starting to finish up whatever tickets they had taken and pivoting to helping teammates get the rest of the work done. Oftentimes we'd close out all the user stories a day or so before the end of the sprint, and have all that time for tidying up the codebase, fixing small technical debt items, experimenting with new tools, or planning ahead for the next sprint. So, if anything, it was the opposite of what the article describes: the last few days of every sprint were downright relaxing.
After: The executives got wind of Scrum, and decided to standardize the whole company on it. We stopped work for a week so that we could have a famous Agile coach do an all-hands Scrum workshop. Which was fun, but the middle and senior managers were conspicuously absent. And then, after that, things kind of went to heck. The way our team did Scrum rapidly started to change as our team manager started getting explicit instructions on how to do things. We also started experiencing pressure to keep or maintain velocity. We started getting questions about why our velocity was so much different from other teams'. We could explain that the story point scale is team-specific and you can't compare story points across teams, but that didn't go anywhere. As I said, the middle and upper managers skipped the Scrum training. They weren't interested in being lectured about what I'm sure they perceived as pedantic little bullshit details.
I left that company and went to another where leadership didn't mandate any Agile methodology. My team did a homegrown Kanban-like thing. A team I collaborated closely with used Scrum. It also seemed to work pretty great. Again, possibly because we chose it for ourselves. I don't think the other team would have done as well on Kanban. Scrum wouldn't have worked so well for our team. I didn't see a problem with that. We each had different business domains that warranted very different "rules of engagement" with our stakeholders and ways of organizing the work.
Since then it's been a couple more companies where "Agile" was mandated from the top, and, apologies to Tolstoy, but they were both miserable in the same way that the first one was after the Scrum mandate got handed down from above.
“What kind of runner can run as fast as they possibly can from the very start of a race? Only someone who runs very short distances. But we’re programmers, we’re smarter than runners. We know how to fix that problem, we just fire the starting pistol every hundred yards, and call it a new sprint!”
https://youtu.be/liUiRfN9NzQ?si=CRkbMokVLXLIdF42
We often would go days without having a formal meeting.
But, software was different then as well. Everything is interconnected now. One team dropping the ball affects countless other teams. Deployments were whenever we felt a new one was due or at a multi month cadence. Did this introduce problems, yes, but at the same time, they came in controlled release cycles.
Nothing against CI/CD and continuous delivery, but the hamster wheel has gotten to a point where we have to release all the time. Corners are cut on everything, and testing is given lip service.
At this point, I am a manager, and SCRUM stresses me out. Either let us work from a queue, or give us a project with a deadline. Give me back a stupid gant or pert chart. At least then it was, is this done to allow XYZ, not we are going to accomplish this in the next 2 (arbitrary) weeks.
So much more to say, but I am toast.
Just to call it out: Having CI/CD doesn't mean you have to do all these things, or do scrum. It's imho just good engineering practice. I have it in my side projects, and I've had it at work on a Kanban-driven team (as well as on scrum).
It removes disputes over build process (eg, nobody can ever say "well, it complies on my machine"). It is a form of build/deploy documentation. It removes bottlenecks ("only Tom knows how to deploy that service, but he's on vacation") and stupid mistakes ("whoever deployed this last did it wrong and left a bunch of old files around").
I also have found deploying regularly is stress-reducing. For one, with CD the development environment is running the same steps, and we know it works because we do it dozens of times a week. The longer it's been since last prod deploy, the less confident we can be it'll go smoothly, whereas when it gets deployed every few days it becomes a non-event.
When something breaks, having only 1 or 3 changes makes it really easy to figure out why. Recovering after a big release with 40 PRs in it is absolutely painful.
None of this means you have to release everything on a regular schedule (like a sprint). You can still do long running branches or feature-flag things off, Just try not to go too long without deploying something.
This is, by far, the most important reason to practice continuous deployment. I've been part of enough of these fire fighting sessions following big releases to see that it's not a sustainable way to deploy software. And yet, I've never been able to convince any boss I've ever had to adopt CD because they're worried it'll introduce more regressions into production.
In my experience, with 2 week sprints, the business doesn't really have to think about anything outside of bite sized chunks or even how those bite sized chunks affect later bite sized chunks. They can make a snap decision without thinking about it because it can be rectified in the next sprint. Almost no-one has a "big picture," view of the software.
Before agile, we essentially did 4 releases a month (this was back on the burn a CD days), 2 major releases and 2 minor patch releases. It worked really well and we didn't get the burnout as much by sprinting a marathon. With sprints, I always feel burned out. No sense of accomplishment, no letup, working hard just gets you more work. It's like laying bricks one at a time on a wall with unlimited length.
It's one reason I'm really thankful to work in a certified/regulated industry. It's mandated to effectively prove your work to get the sign off. And since you can't really sell too well in the area without that cert, it's a big part of development.
But holy hell is it still hard to get specific people to test their work. They just don't even think about it.
Dead Comment
Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success.
In a lot of cases there is a client or a customer that requires regular progress reports. Management uses reports to measure team performance.
I’m not sure what planet the OP is from, but this will never change. If you have a small team with a simple codebase, kanban is probably sufficient. In larger teams or complex solutions, the reporting just needs to happen.
If people are judgemental around what stories are left uncompleted or points / week then the situation can become stressful for no benefit to anyone.
Agreed. (Assuming you mean "create" as in write, as distinct from create as in get funded.)
>> If people are judgemental around what stories are left uncompleted or points / week then the situation can become stressful for no benefit to anyone.
Clearly no stress is better. But these things create stress in the other direction too. Slower than expected progress, the existence of "intractable problems", work going unfinished creates significant stress up the ladder.
In a perfect world the dev team is given a perfect spec, and a reasonable time to do it in, and after being "left alone" they deliver the finished product on time.
Given that that world doesn't exist, given that the "money we're spending" may turn out to be completely wasted (because the spec was wrong, or because the problem us much harder than anticipated), the ideal case seems unlikely to happen.
I say this not as a defense of crappy management processes, or even less as a defense of crappy managers, but rather in the spirit that understanding the problem goes a long way to solving it.
And yes, many places have bad processes and bad middle managers. I don't envy you that. But finding a way to better solve the manager's problem typically improves the relationship.
Anybody doing work needs to be able to estimate duration, progress, risk of delays, etc. Other people's work depends on your deadlines. Go/no go of a project depends on cost and duration.
Insight and tracking is required. None of this was done any better before agile.
Assigning Points = Roughly estimating how long it takes you to implement it
Allocating Work = Well... allocating work
Standups = Talking with your colleagues about the current work and clearing problems
Reviews = Showing your results
None of that seems unreasonable. The only thing that kinda sucks are the rigid sprints, because they just cause artificial stress by setting unnecessary deadlines.
In the agile teams I've been on it's been to produce success. Getting good and useful software fast.
Of course, just like there are hundreds of wildly different Christian sub-religions, there are now any number of "agile" interpretations. In the end belief systems can be pushed to do most anything you want.
The real issue comes from middle management folks who conjure up buzzwords whenever they need to justify whatever they think the team should do. Don't know how to structure tasks but want to look like you're in control to the boss's boss? Just throw up a Kanban board with tiny tickets and a burndown chart trending down. Sprinkle in some Agile keywords in the management reports and call it a day. And let's not forget that by 'sprint' they often mean moving unfinished tickets from the last iteration to the current one, plus tacking on surprise urgent tasks that were not planned before because the product owner never shows up to share their vision and priorities.
Maybe having "easy" sprints would work?
There are benefits too, just that constant grind aspect is why I believe it's mostly a temporary endeavor. After 6-12 months most teams seem to just do something else then come back to it once a new manager joins.
If they all want to waste 2 hours a day, more power to them.
https://scrumguides.org/scrum-guide.html#daily-scrum
> The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
If what you are doing doesn't match that, then it's not a Scrum stand-up.
It definitely is human nature, and beyond that we're so trained to focus on goals and take them seriously that the "sprint goals" actually feel weaponized to me in order to get people to self-motivate/drive themselves. In the Scrum world engineers are fungible, so if one burns up or stops performing, you just replace them with a new one.
Also that "rough week at home" is going to show up on metrics for a very long time. A good manager understands the ebb and flow, but many do not. It also doesn't help that the Certified ScrumMaster® people will put so much emphasis on smoothness and consistency, and when it doesn't happen there's always someone/something to blame. When you remove the context (like team lead who knows what happened) and put it in a quarterly chart for upper management, you get a lot of bad and counter-productive conclusions.
When a project is about non trivial projects, people, especially developers can not be easily replaced, because no one can replace a specialist with several years of experience on the spot. What I can archive in one day and what somebody else can archive on a day highly depends on what it is. Write a field to the database? Works. Write a rule engine? I'll probably be a factor of 10x more productive than an average developer. Write some GUI/CSS? A frontend developer is 10x more productive than me.
The OP may have some things wrong, but the 'constant grind' aspect of scrum sprints is spot on, there is no slack.
Add to that the 'radical transparency' aspect of scrum. That works great among a tight-knit team, but it can be insidious and actually self-defeating when certain types of manager get involved and weaponize it.
I'm sure there are many people who love programming, but hate being a programmer as a job, and to some extent that has always been true, but scrum seems in many cases to make it much, much worse, IMHO. The attitude displayed here is exactly the problem.
Deleted Comment
IMO, if you're a SWE/dev and spending more time doing other stuff (meetings, TPS reports, etc.) than coding (coding includes the time needed to research, experiment and think of good solutions, not just actual coding), then something is wrong.
If a multibillion dollar corporation can do this, so can you!