My take on this is that devs, in general, are managed by people who are still completely clueless about technology in 2024. There are surely exceptions (FAANG, etc.), but I've worked with my fair share of managers who couldn't fathom the work required to add a feature. It's always "just a button".
Sales are easier to understand. You can describe it with words. Us devs use gibberish that nobody understands.
Scrum gives them tools to understand if there is progress or not: Is the burndown chart nicely on a downward trend? Are tickets closed? Is the sprint "green" or not?
I won't blame them. They are clueless. But I hate it!
> My take on this is that devs, in general, are managed by people who are still completely clueless about technology in 2024. There are surely exceptions (FAANG, etc.), but I've worked with my fair share of managers who couldn't fathom the work required to add a feature. It's always "just a button". Sales are easier to understand. You can describe it with words. Us devs use gibberish that nobody understands.
This is truth. A lot of "managers" in engineering just can't fathom the complexity. Even if they have an engineering background, even if they coded for 10 years, they can't fathom the complexity.
Some of the reasons I have discovered are
- They think of every project as "greenfield" with a clean slate, whereas 99% of the projects are built on old tech debt accumulated over years and increasing in complexity. Remember their old tech debt decision from Q4 of 2021? Yeah they don't remember it and can't fathom how that decision led to today's problems.
- They think every "headcount" at all the immense rungs of the ladder are the same. Remember that guy they fired in Q2 of 2022? Yeah they don't remember it and can't fathom how firing a person with context cannot be backfilled to the same level of context, even with an ex-faang label.
Ultimately, management does not see the pile of garbage their decisions have made. That pile is left to the garbage pickers (engineers) while they themselves just think about how to look good to execs.
I consider all of these "complexities" to be failures on our part. Our primary job as a software developer or technology specialist should be to reduce complexity, not add to it.
So the problem is that the one button is buried under stacks and frameworks multiple layers deep. Is it a failure of management to consider a single button change an easy task when it should, in fact, be an easy task?
And the guy that they fired (possibly for good cause). Did we take the time to train and/or learn the items that were handled by this person? Granted, maybe we didn't have management that prioritized passing that person's work off to the next candidate.
I think software developers are as just as much to blame as management for these types of problems. I am one of them, so I'm pointing at myself here too. There are problems to be addressed going in both directions, from my take.
> So the problem is that the one button is buried under stacks and frameworks multiple layers deep. Is it a failure of management to consider a single button change an easy task when it should, in fact, be an easy task?
This is a great example. Why? Because you called out complexity. Specifically, that an engineering org should try to minimize complexity. And yet, the framework for adding a button is immensely complex. Why? Because management wanted a "complexity" aspect for the button framework project. Without the "complexity" aspect, the engineer on it wouldn't get a promo and management wouldn't get additional headcount for their own promo.
> And the guy that they fired (possibly for good cause)
Likely fired to serve a stack rank. Someone had to fall at the bottom in Q2 2022. Unfortunately their exact context and expertise is required in Q2 2024 and the backfill just doesn't have 5 years with our complex button framework yet.
I am sorry. Devs cannot be blamed for poor management practices such as "complexity" and "stack ranking".
This is incorrect. Clearly defining tasks not only aids in tracking and reporting but also helps developers stay organized. It promotes transparency and effective communication, especially for remote teams working across different time zones. At all times everyone knows what they are working on.
Correct. This double standard reveals an underlying belief that managers are more productive and that engineers should eventually become managers if they are to scale their productivity. It's a fundamental misconception and underestimation of what constitutes software engineering, and it artificially constrains it because software can inherently scale by its very nature. The more you understand how software, the more you can leverage it to scale productivity, not just deployment and testing but also development and even prototyping.
Scrum/agile was never supposed to have managers involved. It's for self-managed teams. The PO shoes were meant to be filled by someone representing the client. You can still have a manager/EM on the side who takes care of people and career management at a high level, for multiple teams.
Tech corporations needed a path away from waterfall and to appeal to new developers, so they took it, adapted it to existing structures and mashed it up into the rituals we have today.
I think this part is somewhat true. Big problem is management/sales/business analysts taking over the scrum and weaponizing it to blame developers or push them into thinking they have to do all what they are told.
Issue is those people are usually more pushy, talkative, so it is easier for them to take over and having devs as pushovers.
I work in a company where me and other senior devs made sure that we run the scrum and we use scrum as our shield.
They want to change the scope? well wait till end of the sprint and add new requirements to our refinement , we will see if you have written good requirements or if not we send it back to drawing board. Velocity is not ever increasing, velocity is for us to make sure we don’t put to much work when someone is on vacation or we have new team member that needs onboarding.
Yes there are hotfixes and special cases where we drop stuff and work on something that has priority, but it is not someone just telling us - but you have senior devs to talk to first and explain that really is special case. Because if something really helps us to make customer happy I am also happy to jump on that to fix it.
We could go to Sales management... You have quarterly goals that only 85% of your team makes, and if you miss them 2 quarters in a row (or miss it badly enough) you're fired.
Your work needs to bring in $300,000 of new revenue this quarter or you're fired. You are responsible for all support of that product - no on call rotation. You can have QA help but they get that part of your revenue target.
I'm not a fan of Scrum as it's a rigid process that doesn't follow the agile manifesto. I do like using Github project boards either in a continuous Kanban fashion or even weekly sprints. The contents are self-managed by the team doing the work. Its purpose is basically to allow anyone to look at it and see what the team is doing and what recent progress has been made, or if there are blocked items that need to be resolved. It can prevent micro-management, the alternative is having each team member repeatedly polled by others to get the same information that's already presented there.
Yes. Kanban is the closest methodology that I have found that maps to the spirit of the Agile Manifesto. Kanban and Agile are very harmonious.
Scrum is most definitely not "agile" by most definitions. The process of planning and retroactive review are important agile concepts. But scrum has been significantly distorted in most cases to become the antithesis of agile.
SAFe is even more a divergence from Manifesto Agile. Maybe it's justified because corporations haven't figure out how to do big corporate things using an agile approach. Toyota is probably the exception, since they basically invented the groundwork for Agile today.
Scrum is moronic and has proven itself worse and worse over the past 20 years. It started out with good intent but today it is either merely not-in-the-way or horribly dysfunctional. There is a small, small percentage of projects where it might be suitable. It's very small though.
This critique of Scrum seems quite negative. In my experience, working in a large organization, we track almost everything in JIRA, including change requests for hardware and documentation, using customized Scrum-style boards. We also hold standups and follow Agile practices.
I think we have been stuck with this for so long we have forgotten that any other way is possible. Scrum is just a complicated way to divide labor. No one else at a software company needs a formal process to partition their work. They just sit down, talk and then go do the work. They come up with a light weight way -- a informal process -- to get stuff down. They would never even think to ask themselves, "I wonder what formal process we can follow to assign work?" They just do it.
Sure, and that works great if you have a small, motivated, experienced, and disciplined team with a deep understanding of customer needs. But that is not the reality in most real organizations that must reliably deliver software. They often need to get productive work out of inexperienced, undisciplined developers who don't personally know what the customers even want. So Scrum or something like it ends up being the least bad option that actually works.
You might argue that companies should hire more competent developers who fully understand the business domain issues. But there are few of those available at any price, especially in complex fields like healthcare.
I don't like scrum, but there is a simple counterargument that not all types of work benefit from scrum?
Like... it seems plausible that developing a piece of software and, say, deciding whether to do a merger benefit from different planning and management styles.
Yeah, yeah, yeah - Scrum is bad. That's the fashionable thing to say these days. I figure the people peddling Scrum have run out of people to peddle it to and now they're trying to convince everybody we need a new paradigm. Then they can sell new training and have fresh material for the Conference Circuit.
Here's the thing: I've been developing software for 40 years now and while Scrum definitely has its issues and can be abused - I'm not denying that! - it is loads better than what we were using before! No comparison!
Scrum is dumb? Okay. Cool. What's your alternative?
How about letting engineers do what everyone else at the company does? Get together in teams, divide up the work, and check back later. You are asking for an alternative thing to mandate upon engineers from above -- something formal. I say, just let engineers manage themselves. No mandated process.
Scrum, Waterfall, XP, Kanban - these are the tools engineers created for managing their work. I've never worked at a place where the way your engineering team manages their work has ever been mandated.
I've never met a business stakeholder who gives two shits how engineering manages their work - all they care about is when am I going to get it and how much is it going to cost me - and how accurate and reliable are these answers?
As far as letting engineers manage themselves - if the scope of work is small enough and there's no dependence on other teams or vendors delivering needed components then sure, do whatever you want. It's often inappropriate to apply much rigor to such small projects. Skunk work projects can also be managed that way.
This is sort of true, but it's common for engineering management to force Scum on their engineers. It's not being forced by a VP but it is still forced.
"Engineering Management" is still engineering. Nobody outside of the engineering department is telling the engineering department how to manage their work. This is what it means for engineers to manage their own work.
If your engineering department is being heavy-handed in how they apply project management to all their projects, then that's on them. But realize it is their job to ensure the work is getting done.
That's great that you've been doing things a long time, but it's possible to criticize the current state of affairs without invoking the whole "well do you want to just do what we did in 1980 again" argument. What was it that you were doing back then that was so bad? Can we avoid doing that, as well as scrum, and do something else, perhaps?
Yes, and please offer that rather than just come saying "Scrum Bad." Just for a point of reference, people had said "Waterfall Bad" for 25 years before an alternative was presented. It took another 15 years after that before the alternative became wide practiced. Now here we are 15 years after adopting the alternative and saying it's bad. Yes, these discussions and laments go back for decades.
Many people in the 80s and early 90s tried that alternative. It worked very well for smaller projects, which frankly, was the point. Take the big project and break it into little projects and then utilize a strike team to implement each of the little projects. The approach was decent, and still is!, it's just combining a bunch of little projects into a big project and managing the overall big project is challenging. That's the rub - small projects don't need much management at all, medium projects benefit from existing methodologies (whether they're "good" or "bad"), but large projects are a challenge no matter what you do. You can make them less challenging, but they're still challenging.
I think a big problem is that people seem to think of development as either "waterfall" or "scrum", with a gradient between the two. Being strictly on either side is seen as bad, and being a blend of waterfall-agile is bad too. All I can think of is to throw both out the window and figure out a different set of metrics to prioritize, other than the business-driven Time-To-Deploy-And-We-Make-Profit.
I don't have a perfect solution, but the best one I've implemented so far works only in small teams, and is effectively Kanban-driven development. I try to stay close to The Toyota Way, which I learned while working in medical device (where they, like aerospace, draw a lot of inspiration from our industrial engineering forefathers).
I guess my solution is - create many small teams, let them implement "lightweight scrum" where the Kanban board is the main discussion point every day. What tasks are pending, what's next, what is stuck? And finally, let the small teams throw away anything they don't like, including the board, as long as they meet their deliverables defined by the broader team.
Is this too Scrum-y still? Maybe. But Scrum has lost its way and its time to just return to the basics and implement stuff that's worked for decades in other industries. Software Engineering had its chance to play around and re-invent the wheel, going all the way back to Fred Brooks Mythical Man-Month. The industry has had 50 years to get its shit together, which is an absolute eternity and inexcusable for how shitty a state of affairs we have now, in terms of program management philosophies. Frankly I'm interested in just using the original wheel at this point, where we assign tasks to teams and estimate them USING REAL TIME ESTIMATES (not story points like we are fucking fairy tales).
I care more about making high-quality software and less about management philosophies these days.
Scrum gives them tools to understand if there is progress or not: Is the burndown chart nicely on a downward trend? Are tickets closed? Is the sprint "green" or not? I won't blame them. They are clueless. But I hate it!