There's a lot wrong with this post, especially the first few paragraphs. That part mostly just repeats a lot of tired myths and straw-man arguments w/r/t Scrum. There's nothing new or interesting there.
For an example of what I mean, consider this:
After the manifesto appeared, Scrum quickly declared itself to be “agile” in spite of its ...
But Scrum existed before the Agile Manifesto was created, and the creators of Scrum - Ken Schwaber and Jeff Sutherland - are signatories of the Agile Manifesto. So no, Scrum didn't just "declare itself Agile"... Scrum was part of the Agile movement from day 0.
But towards the end the post does get to an interesting point, which the author summarizes as:
If developers want the freedom to write software in sensible ways, they need to enter the market directly as either founders of companies or freelancers instead of through the comfort and convenience of existing companies.
There's something to be said for that. I've always said that a lot of the core issue here is exactly the "impedance mismatch" between the way engineers see things, and the way "the business" sees things. One way to resolve that - albeit perhaps not the only way - is what the author proposes above.
It is definitely not the only way and the hardest one. Solution is actually trivial: talk to engineers about business more. There’s an anti-pattern of a god stakeholder who decides on everything providing very detailed requirements about “how” and “what” to build. Functional requirements should be “written” by engineers after they learn “why”, i.e. see the problem with the eyes of business. They don’t have to be founders for that.
I agree with that. But unfortunately, you cannot force a dev to get implied in the business aspect if they don't want to. Bad scrum practices are, in my experience, very often the consequences of the devs themselves.
I'm a scientist working in the R&D of my company, and I'm involved with business people (to know what the company needs and what will help) and the software development (to follow up to see the PoC properly implemented and put in production). While I see business people trying to follow and understand the need of the software side, I keep seeing the software side considering that trying to follow and understand the need of the business is not their job. They just want perfect "requirements", and when they interpret them in a way that is obviously not what was needed, they just say "the requirements were not written precisely enough".
I even remember in my previous company the software team joking that they redirect the company emails to the bin inbox automatically, and then complained that they were made aware very late and did not had their say in some decision. Because I have read these company emails, I knew that these decisions were discussed in time and that they have requested inputs from everyone from the company (and they took into account my feedback). This was so ridiculous from the outside, but from the inside, they were fully oblivious of how stupid they acted, they were convinced the problem was "the others". The lesson is that, now, when I have something to complain about, I first investigate if my own behavior is not also responsible of the situation.
Most places I've worked, there is a clear separation of roles between the Product Owner (whose job it is to handle the business case, gather requirements, understand the "why", and decide the "when" and "what"), and the engineering TL who is merely in charge of "how".
At a few places, the TL does it all: business case, requirements, project motivation, schedule, AND the implementation. A lot is asked of that person, but it results in IMO better coordination and execution, because it's not a constant battle between "engineering vs. product". Well, there is a battle, but the battle takes place entirely in the TL's head, so it's faster and less visible.
In order to do it the second way, you need to hire engineers who also can manage the business/requirements side of the project. These people are significantly harder to find than engineers who just read a requirements document and implement it.
That's correct and that's the point: the bad scrum situation is sometimes in place because the TL does not do it all, either because they don't want to or is not able to.
Sometimes, it is because the owners or the managements do not let them to. Sometimes, it is because when the owners or the managements gave them more opportunities, the engineering TL did not use these opportunities and the owners or the management had to fill the gap.
As you said, taking these responsibilities is difficult for the TL and is asking a lot, so I don't think it's fair to expect it to be done systematically.
On the other hand, on my own experience, it is not very difficult to understand the technical aspect. It does not mean "being able to code", it just means "the devs explained the situation and I understood it". My experience being in the middle is that devs are usually worst at understanding the business side than the business side at understanding devs. So I really think that it's unfair to say there is only two ways: either the TL take everything in charge and the decisions are good or they don't and the decisions are bad because non-devs are obviously idiots.
Well, technically, if you show them the door, you failed to get them implied in the business aspect.
But also, the bad scrum situation exist EXACTLY because it's a strategy to push devs to get implied in the business aspect. Or rather, the "good" scrum situation evolves into a bad scrum situation because the devs did not took the opportunity when pushed to get implied in the business aspect.
I also find it strange and funny that some people are being so upset that a bad scrum situation exists, which is way less violent that showing them the door. If the bad scrum situation is too bad for you, you can always leave, which is equivalent to showing you the door. But hopefully, you can also take the initiative to be more engaged with the business side, which will have the consequence of making the bad scrum situation disappear. It is strange to blame people who try to avoid the most drastic situation of firing people.
> Well, technically, if you show them the door, you failed to get them implied in the business aspect.
I don’t think it’s a failure to recognize the problem and solve it by replacing the ignorant person with someone who cares. It has certain price, but it is better than supporting toxic culture, because toxic culture will inevitably increase churn and you will pay more.
You reacted to my sentence: "But unfortunately, you cannot force a dev to get implied in the business aspect if they don't want to"
What you say is that you cannot force them, but you can replace them. So you just say my sentence is perfectly correct.
Not sure what you bring to the conversation. Sure, a manager can fire a dev to avoid the toxic scrum situation (that's pretty obvious). Identically, a dev can quit to avoid the toxic scrum situation. Or, even better, the dev can grow up as a person and as a professional and try to make things work by doing their job that involves understanding the business situation too.
The latter seems to me to be the most sane one, and firing seems to me to be pretty drastic.
My point is that the dev has some responsibility in the toxic situation and it's just being ignorant to not notice that.
And, yes, it's sad that some managers don't do their work well and decide it's easier for them to have a toxic situation than taking the risk of firing someone (which can be a long process and can easily backfire on them, especially if the dev in question is not mature enough to understand they are part of the problem). But why these managers would be more guilty than the devs who created the toxic situation in the first place? Somehow, it's like devs have the right to be bad but managers should all be expected to be perfect. Or that devs have the right to think "not worth it, I will not take more risk or spend more energy to fix a toxic situation, I'm just going to ignore it and it can be someone else problem" but the managers don't have that right.
Oh, and funnily enough, in other discussions, some people answered that it's the responsibility of the manager but not of the dev. The same people who were complaining to be micromanaged and were asking why the company is not trusting them to take responsibility for the good operation of the company. Or that they could easily do the manager's job. Or even said that managers are a useless job anyway.
That is not a trivial solution. Anything with the word "more" isn't a solution. How much more? how many times a day? It's just hand-waving the problem away.
I have been leading engineering teams over 10 years, including on C-level. It does sound trivial to me because I actually have already solved the problem many times, but you are right, the question “how” is important. It is not “how many times” though, because there is no a number. Short answer is, whenever there’s new information from discovery, whenever there’s new business goal or new data from BI, you share that with the entire cross-functional team. Communicating business expectations and updates is the job of every PM and manager. Being curious, listening and picking from this stream what’s important for your job is the part of job description for every single person in R&D.
I've been doing "agile" since before "Agile" was a thing, and I am a Scrum.org certified PSM. I don't need to go read anything to know that you're misrepresenting the situation here.
But to indulge you, here's what scrum.org says, in part:
If you are just getting started, think of Scrum as a way to get work done as a team in small pieces at a time, with continuous experimentation and feedback loops along the way to learn and improve as you go.
Continuous experimentation, adapting with feedback, and learning and improving as you go? That doesn't sound like "process over people" to me.
Note also that the Agile Manifesto never says anything about not having some process. I think almost everybody would agree that a certain amount of process for the sake of consistency is a Good Thing. The problem is when people over-elevate the process to where it's seen as its own end unto itself, rather than a tool to help the team deliver the $THING they are trying to deliver.
I agree a small amount of process is a good thing. It needs to be small enough so that people won't be squashed by it, so they won't stop thinking and act correctly in whatever situation the process didn't cover.
As someone who was doing waterfall projects back in the day and lived through various agile variants, I don't think the amount of process that scrum involves is justifiable. At least waterfall produced tons of documentations which made projects rock solid. With scrum you do all these crap rituals and you are left with nothing but depressed engineers. And no, an "energizer" is not going to help.
I've seen plenty of times were scrum was added to organizations (even to teams that were working incredibly well without it) with horrific results. In one case, developers just started quitting (me included).
I'm glad one of my client is walking back on scrum, even though there are still a few zealots trying to do scrum without calling it scrum, no matter the pushback they receive from everyone else.
There are definitely some good ideas coming out of scrum (the product backlog is a great concept) but as a whole it's definitely a net negative for morale and productivity.
I respect the hustle of the scrum masters who managed to create the most useless job role I've ever seen, though.
Wanna play with cards shouting numbers with no meaning not unlike old ladies playing Bingo?
Wanna have a mini CEO, who, for some reason bosses around people far more qualified than themselves, implying that they are just nerds that can't be trusted to speak to the outside world?
Wanna appoint one of your team members each week (or, even better, hire a dedicated member of your team) to whine about you adhering to all of the rules you just made up?
If you love all of the above, you'd love Scrum. And, if your idea of good time is being in meetings about meetings, you'd love SAFe even more.
> If you are just getting started, think of Scrum as a way to get work done as a team in small pieces at a time,
The reality is that if you are just getting started, think of Scrum as a way to talk about work and have rituals about work, preventing you from doing actual work. I have never, in my long career, seen Scrum work. Unless your idea of it working is chasing away good developers and making the mediocre ones thrive (in following the process, not in actual achievements).
Scrum is just terrible and should be killed with fire.
SAFe should absolutely be nuked from orbit. But Scrum done right works very well. The thing is, most of your strawman items listed above are not intrinsic to Scrum.
Take the "playing with cards" thing for example. "Planning poker" is not an intrinsic element of Scrum. Despite the practice being nearly ubiquitous in shops that claim to be using Scrum, it's really an outside idea that got pulled in.
Don't believe me? Check the Scrum Guide[1] and see if you see any mention of planning poker. Or for that matter, Jira - another thing people often criticize in regards to Scrum, despite it also not actually being part of Scrum. Velocity is another thing that people love to rail against (and rightly so) that isn't part of Scrum.
And then one authors of the book state: "if you know nothing about Scrum, implement everything as in the book, otherwise adapt to the situation and the team. If not you will surely fail [...]"
But being "Scrum.org certified PSM", how do you see your colleague from scrumalliance.org?
I do agree it's toxic. And a productive workplace is often a turn off to certain kinds of employees.
Scrum done a certain way too often is a waterfall in a different way to manage developers and features.
Scrum/Agile are helpful where there is little to get consistent results out of team members with varying skillsets, but it doesn't mean it works for high flying team members.
For example, using trunk based development for a startup with senior devs is far more efficient, with the understanding that will slow down and including more and more people will mean helping the best parts of your agility remain.
Jumping all in to all ceremonies without understanding a 'why' makes a big difference.
Anyhow, I get to be quiet now and learn lots from the other comments in this thread, experience has taught me that experience is a great teacher.
If developers want the freedom to write software in sensible ways, they need to enter the market directly as either founders of companies or freelancers instead of through the comfort and convenience of existing companies. It’s a hard pill to swallow, but there just aren’t many companies doing it right. Luckily, I am guessing it is easier to teach business to a programmer than the other way around. Think of it this way: it HAS to be better than doing Scrum!"
===
My previous comment on the subject still seems appropriate.
The big problem is "How do I connect the money to the work". In large corporations, this becomes project -> plan -> work. The project gets a budget based on the plan, then you do the work based on the plan.
The problem is the link between plan and work. As you work, you learn. That is the primary activity of software development. Learning is a menace to planning. As you learn, you have to replan, but your budget was based on the original project plan.
You can talk about engineering and culture and whatever you want, but if you're working for money, the problem remains of connecting the work to money and the money to the work.
Yes, SAFe does attempt to deal with this issue, but it's like moving food around on your plate - it's still there, and management still wants to tie activities to budget.
Whatever framework or philosophy or concept you use, it gets implemented by people in an organization.
If that organization is new and growing, it is graded by things like active user growth (top line); if that organization is established, it is graded by profit (bottom line).
The journey from top line to bottom line is where all the complications come in.
So I think the author is correct in their conclusion [0], but not in depth.
0. Engineers will tend to be sad in established orgs [cost centers], and happy in new orgs [product development].
It it certainly possible for incompetent managers to misuse SAFe, as with any other methodology. I've seen that if actually implemented as written it tends to work pretty well in large enterprises, at least in the sense of being the least bad option that allows product delivery with the level of consistency and reliability necessary to meet external commitments. Comparisons to "waterfall" are a rather silly strawman.
Do you have a specific criticism of the SAFe budgeting model, or a specific alternative to propose?
> Developers have no real power or seat at the table. They are not peers engaged in a common creative enterprise — they are hired, replaceable machinery, no different than the computers and monitors they use all day.
This is correct. Scrum (and all of the other PM rituals) exist because the people controlling the money need to attach budgets to projects in order to figure out whether they're worth doing or not (or more loosely to teams, to figure out if they're profitable or not). Once a project has a budget, then it needs to be tracked.
It's enormously frustrating to be on the other side of the table, and to have a recalcitrant development team missing estimate after estimate, sometimes by orders of magnitude. Either it's your money that's slowly being incinerated, or you have to go back to investors and tell them that you decided to spend on X, and X is only 1/3rd as far along as the tech lead told you it would be.
But it's also frustrating to be on the developer's side of the table. We're not generally included in the business strategy meetings, because we don't generally have MBAs. (Also because we're expensive, and having us sit in "irrelevant" meetings, especially when we're "behind" anyway, seems like a poor use of resources.) As a result, we're two steps removed from the decisions that matter - and not in the room when we could potentially have suggested a better approach to solving the original problem.
Personally I'm done with the corporate software world - I'm riding the fractional/freelance bus until retirement. But, I wonder if these kinds of dysfunctional dynamics could be fixed with multidisciplinary teams. E.g. imagine a team of several devs, a couple mbas, and a few sales people, responsible as a group for the team's financial position in the company. Strange bedfellows, maybe, but if each person's success depended on everybody else in the team hitting their goals, the communication patterns could end up being quite different.
> It's enormously frustrating to be on the other side of the table, and to have a recalcitrant development team missing estimate after estimate, sometimes by orders of magnitude.
I know this is just my anecdotal experience versus yours, but every time this has been the case for me in my life, it's due to dates being told to the developers instead of the other way around. Sometimes it's blatant "we need to hit this date because of the market / end of quarter" and sometimes it's passive aggressive such as "management didn't feel your date matched expectations, try again" and it gets sent back for another estimate which will now be biased.
I've also been on both sides of the table, and I'm glad I was a developer first and had those experiences. I already knew that humans can't estimate large things accurately, and that was one of the great takeaways from scrum: do smaller batches and estimate those to get more accurate numbers.
I worked on a project once, where the date was written in the law (financial compliance). Sometimes we have to accept and deal with the deadlines and the problem becomes the problem of quality and scope. In such situations you just throw away some of the best practices and just ships whatever works. Business is often totally fine with imperfections.
> Sometimes it's blatant "we need to hit this date because of the market / end of quarter"
You know what‘s blatant? "Deadline is MM-DD, and it’s non-negotiable, because that‘s the birthday of the boss‘s deceased husband". Been there, suffered that.
All important projects had that deadline, year after year, when they were so unlucky to have their projected end dates somewhere around that part of the year.
> E.g. imagine a team of several devs, a couple mbas, and a few sales people
A modern product engineering team is like that. Decent product manager (as a substitute for MBA), UX designers, researchers, devs, QA, some relevant business stakeholders and north star metric to align the work with it.
>E.g. imagine a team of several devs, a couple mbas, and a few sales people, responsible as a group for the team's financial position in the company. Strange bedfellows, maybe, but if each person's success depended on everybody else in the team hitting their goals, the communication patterns could end up being quite different.
You described a small business!
If society and school system weren't trying to hard to turn everyone in mindless employees (MAX(salary) so everyone ends up in a few huge corps), we would see more small enterprises: the economy and people' lives would be much better.
Upwork to start - set rates high enough and you'll find a steady stream of reasonable positions coming through. It's a bit of a slog until you build a reputation.
Eventually word of mouth and your network kicks in.
I think you'll find "distributed decision-making" is no panacea. I joined a company recovering from a distributed governance model, and the big challenge was that nobody had enough decision-making authority for the firm to change quickly and respond to the evolving outside world. Bringing a whole room to consensus is a lot tougher than getting a few people to disagree-but-commit and move on with their day.
Funny enough, you even see this paradigm in secret messaging with Signal: the ecosystem is moving[0]. If you want a system that can evolve in response to external change, centralization is useful.
This isn't a defense of scrum, but a voice of opposition to running businesses as distributed utopias. It sounds great on paper, but you'll be out-competed by the faster-moving entities with centralized power very quickly.
This post resonates a lot with me, enough that I want to comment. After 5 years working with a full-time SM (3 different ones) in my team, I still have no idea what value they are supposed to provide, or how they fill their day once the daily meeting is over. As the author states it is completely demotivating to feel like you are carrying a parasite on your back ("robs engineers of their productivity and self-esteem").
Note that among the devs at my company, I'd say more than half don't seem to have a problem with it, or at least go with the flow, so I might be in the minority but I feel strongly enough about it to consider trying freelancing, I just hope I can demonstrate enough technical skills to be able to "insist on being in control of how [I] work" and still be hired...
Developers should become owners! It is much easier for a developer to learn the business side of startups than it is for a business founder to learn how to code. Not only will learning the business side allow developers to become founders, it will improve their development decision making, allowing them to communicate better with customers and the rest of the company about priorities and strategic decisions. Once you know how to talk the language, it becomes easier to convince people that technical factors are important to strategic decisions. Even if you don't become an owner, learning the business side of business will allow you to play a larger role in the decision making.
I definitely want to become an owner and learn about the business. I've even conceived and executed projects to improve the bottom and top line revenue. That being said, as a developer in a small business, the thought is that I'm too expensive an employee to not be coding even if I had a lot of impact on my own initiatives. The thinking is that a lot of people can think about strategy but very few people can code so I get pigeonholed into just executing. This has been my experience at multiple startups at various stages of their lifecycle.
Sure, but the reverse of that is, you as the developer, are the owner, and you just hire the people to think about strategy, etc.
What you are saying is true, because coding is the high value work that relies heavily on the individual effort and productivity. The team effect of coding is effectively the sum of each coders productivity.
The business side is the opposite, it can be much lower value individual work, but the team efforts combined is exponential. If you want good software you can't really just throw more developers at something, in fact doing so can often lead to declining returns. But this is the idea behind things like SCRUM, Agile, Stand up etc. It's a way to try and figure out how to scale development by effectively just adding more manpower. It simply isn't a fit for development though.
On the business side however you can scale just by adding more people.
At the end of the day you can have excellent software that makes no money, and you can also have excellent business strategy that makes money and fails to deliver a product.
That only works in some business domains. If, for example, you're trying to build products for a complex healthcare use case it takes years for most developers to start making a positive contribution as product owners. A lot of customer requirements are counterintuitive and don't make sense to anyone without deep domain experience.
As a tech feudalist myself, I think software developers could be the best at accounting, tax and corporate entity structures too, which can guide the business decisions as well. I generally see a segregation of those interests, but as business owners the interdisciplinary nature can become clearer
Ok, but here me out - I think many things are missed in this take. This one immediately jumps out at me (from the manifesto): "Build projects around motivated individuals"
The manifesto is predicated on this basis - that the individuals are motivated and capable of delivering when empowered. In a large corporate environment, can you make that assumption? Is your hiring always that good? Can you provide the type of environment that always produces high morale?
I'm no fan of scrum, but I've also seen what happens when "unmotivated" individuals are given too much free reign - nothing. How do you, as a large business, address that? Mass firings, or more "active" process? Perhaps business can't get over the risk mitigation that scrum provides?
I don't know the author, but these complaints about ownership make me worry if they are not a team player.
By "not a team player", I mean they can't easily subordinate themselves to the rest of the team's consensus, to the enterprise culture/standards, to the limitations of the legacy codebase, to their product owner's direction, or to the laws of physics.
This programming stuff takes humility, and everything is hard to do. Non-team players make everything harder with the friction they add to every decision and the morale drain they put on the rest of the team with their sourpuss nature.
I try to win these folks over with love and help them to add many small wins to their name, but they're often energy monsters and they quickly exhaust me. It's often a relief when they remove themselves from the team.
The scrum people can also be non-team-players by not subordinating themselves to the team's consensus on appropriate methodology and level of ceremony. That adds friction, too. It's just that, since it's the "team players" pushing scrum, it's not obvious that they are in fact not team players. They're running over the team with their vision of teamwork, but they're not actually listening to the team protesting that it doesn't fit.
The "scrum people" you refer to are supposed to be the team itself, so it sounds like you're describing some scrummerfall-type organization. I agree ceremony would be largely meaningless and worthy of scorn in such a place.
Can you describe a scenario you were involved with where these other people weren't listening to the team's protestations, or were you just giving a hypothetical?
My favorite ceremony in Scrum is the retrospective because that's where we get to factor protests and pains into our backlog.
Scrum is not a panacea, it's a form of agile that even big globo-corpo can appreciate and that's why it's so widely deployed. Low cost certifications and copy-cat'ism.
If you run Scrum the way it's trained, it is only effective at directing the people and planning. The developers need to ensure that non-functional requirements around code quality, all the -ilities really, are factored into the work that the team does - you do NOT get that with Scrum. This is my biggest complaint about Scrum is its utter silence on development standards. It is important as developers that we establish what our standards are and hold ourselves to those standards. You could say that the place for that in Scrum is the Team Working Agreement (like house rules), but again, there's no guidance that "Developers shall define the standard of quality for their work products...", etc.
Here's how I got there. Author doesn't like the way decisions are made so they think they should be the decision-maker. The team is supposed to make the decisions in Scrum. So, I feared that in reality, they're just not a team player and feeling a little powerless in that dynamic given all the pushback they may be experiencing.
The author's complaints about Scrum Master and Product Owner do not seem to be substantiated, just gripes.
The Scrum Master is supposed to be the unblocker and master of ceremonies. In my opinion, the best SM arrangement is as a rotating role for analysts/developers on the team rather than a dedicated position. The Scrum Master needs to be involved with the actual work to understand what a blocker is. Rotating SM is actually becoming more common in the industry, as I understand it.
The ideal Product Owner is the one neck to choke on the team for failure. The ideal PO is the keeper of the vision and the tastemaker and a buffer between the team and the business/politics and the subject matter expert when it comes to business requirements for the project. Obviously, there are less-than-ideal PO's, and we can lament and complain about that separately, but author needs to better understand what a PO is in Scrum. I wonder if they think a Project Manager is the same thing as a Product Owner.
> The Scrum Master is supposed to be the unblocker and master of ceremonies.
How about we throw the ceremonies AND the scrum master (and scrum along with it) out of the window and treat the developers like grown ups that can actually unblock themselves? How about we treat all the devs, all the time, like people who know how to say they are stuck, need help, or how to say NO? Why need to infantilize them?
> The Scrum Master needs to be involved with the actual work to understand what a blocker is
Wow, that means...literally every dev can be a scrum master. So, should the devs that are currently not the Scrum master suddenly lose their unblocking capability and sit around hopelessly while Scrum hero solves the bottleneck for them?
> The ideal PO is the keeper of the vision and the tastemaker and a buffer between the team and the business/politics and the subject matter expert when it comes to business requirements for the project.
Oh, poor devs, needing a buffer, and somebody to tell them what the Business (capital letter, like the Church, cause it's an institution) wants. It's not like they can go and ask, god forbid a developer talks to a Business person directly. The outrage!
> The author's complaints about Scrum Master and Product Owner do not seem to be substantiated, just gripes.
The author has a very substantiated gripes with both roles, as both the author and me (and many others) view these roles as useless management cruft.
And the PO has to also be a subject matter expert, wow! They must have studied hard in the Subject Matter school (1 week online course) to acquire such skills!
Wanna hear about my revolutionary idea? A development team consisting of...developers.
I don't understand your hostility. Are my opinions hostile to you? I'm sorry if they were. I'm just sharing what I've learned.
> Wow, that means...literally every dev can be a scrum master.
Yes. And that's why if you take the training as a developer, you get "Certified Scrum Master" training. If you would stop trying to gotcha me, you would see this is an potential area of agreement between us.
I don't think you have a proper sense for what a 'blocker' is in the context of Scrum. In a normal workplace and well-functioning team, blockers are few and far between so the SM shouldn't need to engage all that often anyways.
Not all problems we encounter in the workplace are in code. Scrum has roles to own and manage the different kinds of problems. Scrum is also a flat hierarchy, it's fairly minimal. You're supposed to make things as simple as possible, but no simpler. I think you're over-simplifying.
The 'Business' is capitalized because of English, but feel free to read my words with business all lowercase. I don't worship any man, bad look.
Product Owners need to be subject matter experts or at least SME's in training. In my experience lead developers who try to also wear the PO hat sometimes have trouble getting their heads out of the minutae. If you have seen the opposite in your experience, then lucky you.
> Wanna hear about my revolutionary idea? A development team consisting of...developers.
When you get to know types of folks other than coders, you get to appreciate how they make important contributions to the project. I think you were trying to smash home a point here, but the world is bigger and more interesting than what you wish it was.
I think the link is that it is not at all uncommon to see someone who cannot play nice with consensus or be humble to blame everything on the company ownership.
It is possible there is a company ownership problem sometimes. But the article conclusions seem to be presented to be valid all the time.
I too had this impression reading the article. I would not have had this impression if the article was also mentioning that maybe sometimes a bad scrum implementation is the result of the software developers wanting to control everything while being uneducated on all the aspects that are slightly outside of their narrow field of expertise. This is common enough that there is a term for that: "engineer's disease", and that it was illustrated by a xkcd comic strip (1570)
When everyone is responsible for a project, when everyone owns it, it means that no one is responsible for it, that no one owns it, and therefore it is doomed to fail with about a 95% probability.
As for the "product owner", they only control direction, and they are not actually vested in the success of the project beyond their immediate direction.
I have worked with product owners. They categorically refuse all proposed refactoring work that developers find necessary. As a result, the project keeps piling on so much tech debt that it's doomed after two to three years. Moreover, they never suffer the consequences.
Sounds like a retro topic. Real life isn't Dilbert, but I can see how we fall into its tropes. Ultimately, you're a professional, and shipping crap code is unprofessional. But when you inherited 90% legacy code, it's not like your team can instantly go to shipping non-crap. So, there has to be a gradual improvement in the team as you get the codebase under control.
This is why retrospectives are my favorite Scrum meeting because I get to air my grievances in a constructive, supportive way where I secure action items for the next sprint for what I want done and backlog items for the future.
If I am being told by my Product Owner I can't address tech debt, then I absolutely hammer home details in the retro when that tech debt bites us. And every single sprint, I will say the same things over and over, each time ratcheting up the severity, polite but firm. I get to say things like, "this is hurting our velocity, we are firefighting constantly, build times are ridiculous, we need to be logging more", etc.
Ultimately, even sociopaths get tired of hearing the repetition. So they give you a story to go fix some tech debt. Let me tell you from experience, you had better KNOCK that first tech debt story out of the park. And, it had better be a story you can measure for awesomeness. "Weekly Saturday morning outage abated for first time in months", that kind of thing. You need to proclaim your team's success in improving things to whoever will listen in the organization to make the wins public. This is how you gain trust and get the next tech debt story to work on, positive reinforcement.
Your story makes me sad though. It could mean that your PO didn't trust your team because maybe your system was fragile and every time you guys tried to fix things, it turned into a boondoggle. Not trying to insult you, I don't know your story, maybe your PO was a tyrant. I'm just relating learnings from my own past experiences that might apply to you. Like, if any developer on your team ever says in a team meeting "we don't know what's going wrong", the trust level goes down a peg and some PO's will immediately start to panic or die inside. You can't blame a PO for acting irrational or cold to the team after that happens.
All I know is, every story you do in those low trust situations with regards to tech debt needs to be a win, it should be bite-sized with high confidence levels before you agree to take on the story. No big bang releasing anything. Always gain more confidence.
Retrospectives allow airing concerns, but nothing really ever happens of those concerns in my experience. The concerns are documented but forgotten before the meeting is over. It's as if it's a religious ceremony.
It seems that you have to take desperate measures and be very convincing, which shouldn't be necessary in a high trust setting. One shouldn't have to repeat the same things over and over. It's the PO's job to take notes, and if they don't want to act on it, it's their project that will burn. No skin off my back. The best thing I can do is to have it documented once in writing an email, with a Bcc to my own personal address for legal reasons.
I shouldn't have to work extra hard to convince someone of what's necessary. I certainly don't get paid enough to do it. It is disrespectful to me, and similarly to you, if the other person is difficult to convince. If the management wants to torpedo the company, it's what is deserved.
> Retrospectives allow airing concerns, but nothing really ever happens of those concerns in my experience.
Even on the urgent stuff? If the pain is excruciating, coming out of retro, stories get added to stop the bleeding in the following sprint on every Scrum team I've ever been on.
Are there never any action items with owners or stories written coming out of retro on your teams? You should try that.
> I certainly don't get paid enough to do it. It is disrespectful to me, and similarly to you, if the other person is difficult to convince.
Not if your ideas are bad/misguided/counter-productive. Do you know your ideas are good? How do you know? One can't tell if they are misinformed, hallucinating or off the rails.
If you can't tell, then your PO and team certainly can't tell, especially on complex problems.
So some arguments take time to develop, you sharpen your argument with new data, or maybe the thing you were all worked up was your mind playing tricks. It happens all the time.
I think it's very easy to get defensive and angry when it feels like you're losing face in front of your team. Getting pushback is normal, especially when trust is low or resources are sparing. Just keep a cool head and wear down the resistance.
It's not losing face if you are always acting in good faith when discussing issues you want to see addressed on the project. You're actually stronger in the team's eyes if show commitment to the team even after embarrassments. You're not a robot and you'll make lots of mistakes.
You must be new to this. Even when stories get added, they never get prioritized, and just sit in the backlog forever.
> sharpen your argument with new data
Why should I care. If they want me to present ten times the necessary evidence, it is not me who is at fault. I have to cover my liability, which is to document the issue in writing, with proof that I documented it. Beyond that, there is no reason for me to care if the project or company perishes. It would in fact be better for the company to perish if they don't pay attention to what is said.
These are structural problems that for some reason you can't seem to get your head around. They require a structural solution. The current structure is one of deception, of deceiving others up and down the chain, as well as oneself. Also, "wearing down the resistance" is what toddlers do to their caretakers. If I was getting paid a million dollars, I'd put up more of a prolonged argument, but I am not.
> it would help if they did because the project fails after a year due to the overwhelming burden of the disorganized legacy
It's always someone else's fault with you. It's always someone else's goof. It's a mystery why no one listens to you.
Over a full year of disorganization where you are a powerless contributor and a non-lazy victim and those unfair tyrants deserve to crumple and fail at the end of it?
I'm not buying what you're selling, hyperbole or not.
To answer my own questions:
There is no mechanism to self-check your cognition for viability. Only other people (the team) can check your ideas in the moment with agreed-upon evidence/track record as a long-term proof.
Because you need others to validate your strategies and designs, which are likely flawed, you need to work harmoniously with others.
Therefore, you need to ingratiate yourself to them and respect them so you can influence them and you'll eventually get your way with the team if you're any good. It's called being a team player.
You really have no shame making incorrect and toxic assumptions. No, I wouldn't just keep working on a failing project for a year or more. I would leave well before the year is over. I know about the failures only because the project was there before me for a certain number of years.
I need to ingratiate myself to absolutely no one. One can nevertheless be a good team player by doing and delivering what takes on. In contrast, with agile there is no individual responsibility.
I am really not saying they should, but it would help if they did because the project fails after a year due to the overwhelming burden of the disorganized legacy. Note that it's not just me on the project; it's also a lot of other non-senior team members that aren't really capable of handling the legacy without introducing serious bugs.
You're thinking in an over-constrained framework where there are just two choices -- either to form a consensus or to reject the ideas. If instead you take a higher view, you will see that giving senior engineers ownership and freedom allows the management to see if the engineers sink or swim. The technical lessons will then be more apparent.
From my experience, the same people who love using Scrum are the same ones who post cringy stuff on LinkedIn. You just can’t reason with them. One time, I tried to reason with a middle manager who insisted on using it. He had no previous experience or education in project management, whereas I’m a certified PM. I tried my best to explain that just because a tool worked in some scenarios, it doesn’t mean it will work here. Long story short, it was dismissed, and Scrum was implemented because “all successful big companies are using it!” Less than a year later, three of the best engineers on his team left.
So many posts with X is not the problem, it's a symptom... they're always wrong. It's the problem. It might not be the only problem, but that doesn't make for a bait title.
This post contains a lot of truth. Developers have always complained about the processes that companies employ to direct and manage software development.
It correctly identifies that what preceded scrum was also poor for developers (big design up front), and that if anything replaces scrum, it will also be unpleasant for developers, because all these processes do not exist to make developers happy. They exist to control and manage software development.
So yeah, if you want to control how you write software, you have to be in control. But I strongly suspect that (other than for small, very high performing teams), you will inevitably create processes to manage it as you grow, and developers will then bitch about your process.
Indeed. To develop large information systems requires discipline and organization -- and programmers resist discipline as a mustang resists the bit. So what you have to do is break your programmers the way you break a horse -- enforce discipline upon them. They'll complain but it'll be worth it in the end. As an example, programmers often have cluttered desks citing the aphorism that "a cluttered desk is a sign of a brilliant mind" (when it's really just a sign of sloppy thinking). What you will find at highly effective software shops is that management will insist that the programmers keep a tidy desk, going so far as to bin any clutter they leave lying around -- because "neatness counts".
For as much as it's maligned, "big design up front" is just common sense. The most successful methodologies for software development are derived from engineering, manufacturing, and construction -- and in those fields, having a clear idea of your requirements and a complete design or blueprint before you build, before you even prototype, is just table stakes. Anything else is stupid.
I honestly don't care one bit how tidy someone's desk is. I've seen very good results from taking a more iterative approach as opposed to BDUF.
Software is not like building things that have been built a thousand times before. It is usually a bit more explorative, and the requirements can be hard to pin down. People aren't good at defining exactly what they want.
So I find myself disagreeing with pretty much everything you say. Which is not to say that you don't need a process to manage development, or that developers will like it, whatever it is.
> Software is not like building things that have been built a thousand times before. It is usually a bit more explorative, and the requirements can be hard to pin down. People aren't good at defining exactly what they want.
If you have a capable systems analyst, requirements are very easy to get pinned down. End users may not know what they want, but an analyst can determine what information needs the business has in order to carry out its functions by asking the right questions. Programmers are unlikely to have the big-picture vision or people skills to ask these questions; ergo, programmers make poor business analysts (but are often used as such, especially in Agile shops).
What you say is typical of an immature organization where programmers are in the driver's seat, and they view themselves as artists who need to express their creativity. Information systems development is not an art but a science, and as Tim Bryce says, most programmers are not artists but house painters. See Tim's excellent challenge to these ideas and others here: https://www.linkedin.com/pulse/ten-common-myths-information-...
> So I find myself disagreeing with pretty much everything you say. Which is not to say that you don't need a process to manage development, or that developers will like it, whatever it is.
You may not agree with it, but that's how grown-up, effective IT organizations have been building information systems for decades now. They take a structured, factory-like approach to development, replete with an up-front design process, assembly lines, strict process control, and resource management (generally in the form of a central information-resource repository); with corporate management -- not mythical "self-organizing teams" of programmers -- in control. Most businesses do not have exotic software requirements; their information needs can be met in standard ways with standard tools and techniques.
You will not see very many organizations like this in the USA. You will have to go abroad, especially to Japan. (Until recently, the Japanese did not lionize their programmers the way we do; programming was simply and strictly just another form of professional business or engineering work.) Once the West has shaken off its techbro wine (quite likely given current economic conditions), these methods will have to be rediscovered.
I have never seen great results from BDUF. It works, but you often build slightly the wrong thing or miss important requirements. I do not have much faith in business analysts.
Fundamentally, its a slow and expensive way to build something that probably won't meet your actual requirements.
Can it work? Sure. I bet NASA does BDUF very well. But most organisations don't have the resource and skills to pull that off.
Jira is like Java, many people think of their experience in 2000-2010s in some ugly corporate environment, not being aware how good it can be in agile environment where people are really above the processes.
The problem isn't the processes, the problem is the people.
The good news is that in a good environment, you can earn trust after a few years and gain a little more freedom. You are basically then solving the "people" problem by fixing the only person you have control over: yourself.
(Of course, I understand not everyone is working in healthy environments. Some micromanagers will never be satisfied!)
Healthy environment is not the one where you need to gain trust to get more freedom, it’s where you are free from the beginning and follow (and develop) best practices instead of obeying the rules. It is a combination of trust by default and safety net, where mistakes are made, but they don’t kill the business and are corrected quickly.
I once went looking into "how did this ever become to be".
The underlying workflow system in JIRA is based unsurprisingly on an existing workflow management library. And so much made sense about 'why' is it this way.
It also reminded me why most JIRA "replacements" only replace whatever the origin story of the creator of the software is, where they're at, what their priorities are, and how to get there.
> It doesn’t take much googling to find a vast number of developers griping about it on their blogs
It also doesn't take much googling to find a vast number of people convinced that vaccines are bad.
Scrum is the most popular development methodology because nothing is more popular. It's not like there's some development methodology out there that all engineers like and its just the bad managers stopping us from using it.
Scrum is liked by managers, not developers. It is a managerial approach, not a legitimate engineering approach. Kanban, for example, is less negative to developers than is Scrum.
> So what is the real solution? Engineers need meaningful ownership. If engineers could acquire enough ownership to represent a significant percentage of the company, they could demand to be part of decision making.
That rings a bell, where did I hear such a thing? Oh yes, "workers should own the means of production" – I don't know if the author realizes this, but he's making a good case for Marx.
I think the less layers of management in the company, the better. The flatter the hierarchy, the more freedom the developers have, more stuff they get done, the happier they are. But for that you need trust and good developers.
Every single post of this type is wrong. You don't need to read beyond the first line. "Scrum is horrible" - no, it's not (at least not necessarily) and asserting that you somehow know that this is true for _everyone_ is patently ridiculous. The author is taking their experience, finding others that validate it, ignoring those who disagree with them, and making sweeping assertions that make absolutely no sense.
Focusing on whether Scrum, Kanban, XP, etc. are good or bad misses the point entirely. They are neither good nor bad in principal: they are either good or bad for different teams in different situations, and even then depending on the specific implementation. There are very happy teams using scrum and performing excellently as a result. You cannot tell them they are doing it wrong. They're not.
My teams don't run scrum, but I consult for many who do, and I know how well they're doing and how happy they are with their situation. I also know of others who hate it.
I don't know why it's so difficult for engineers to understand this. Your experience is not universal. You don't know everything.
Sounds like you indeed didn't read beyond the first line - this article argues that it is not scrum (etc.) which is horrible, but the context in which these systems are used.
The first 4 paragraphs were enough to know that it isn't worth the time. You can't spend 50% of the article being so off base and have the rest be worthwhile.
I thought the opening line "Scrum is horrible" made it immediately clear that this is an opinion piece. I can't speak for this author, but when I say something like "your data fits in RAM" or "just say no to microservices" I am well aware that some data actually does not fit in RAM and sometimes microservices are actually appropriate.
I'm pretty happy at a Scrum shop right now, but I appreciated reading this. If you have a passionate opinion forged from personal experience, I think it's best to just present it that way rather than trying to tone it down or dress it up into something tamer but more universally correct.
Who is Scrum for? I would argue it's not for the developers. In that case, whether or not some teams are happy using it doesn't really matter. It's a tool to give the illusion of metrics and estimation in an situation that is antithetical to it.
Someone looked at the Agile manifesto -- specifically that part of "people over processes" -- and decided what was really needed was a strict process and a bunch of ceremonies to go with it! Can developers be happy with this? Absolutely. Are there plenty of developers unhappy with it? Also absolutely. I think that means we should still look at it critically.
> Who is Scrum for? I would argue it's not for the developers
The point of Agile/Scrum is to give the developers total peace from interruptions for a sprint of development. _Nobody_ can come and tell them to change the plans mid-sprint. If someone tries it's the Scum Master's job to tell them politely yet firmly to leave.
If someone insists on changes, the Official Process says that they delete everything from the start of the sprint and start again - this is to give a clear price for interruptions.
"You want this door over there instead of here where we designed it a month ago? Cool" burns down the house "Let's start over then".
In 99.99% of the cases the request suddenly isn't THAT important and they can wait until the end of the sprint.
BUT
Scrum can only work if it has the buy-in of the whole company, you can't start it from the bottom down without some really big cojones.
> The point of Agile/Scrum is to give the developers total peace from interruptions for a sprint of development.
That part can be done without scrum.
However, you are omitting that scrum also drags: Product Owners, sprint plannings, poker, daily standups, sprint demos. And you know what follows a sprint? Another sprint...And every time you miss that (self imposed, totally arbitrary) deadline, you fail.
I simply don't understand why people do this to themselves.
I think it's a management strategy to keep developers under constant pressure with feet close to the fire. There is always something to do, report, meet, discuss in a formalized way, damn everything else. Even if you didn't do much this week you still have to report something. Do this two weeks in a row and your already on the naughty list. Doesn't matter if your tenure was stellar so far.
In my experience the only ones loving it are of course management, and highly vocal and relatively young developers who seek refuge in arbitrary procedures and fake structure.
As others said, it's also a way to try to treat developers as assembly line workers, which can be replaced at any time. Doctors or lawyers have no such thing. Nor any other engineering profession that I know of.
Software development is a realm of snake oil salesman, move fast - break things philosophy, and no unions. So no wonder we get this kind of crap shoved down our throats. And just like with any mass of people, a certain percentage will absolutely adore it.
And I think it's a good way to communicate how the team works.
If you want new features, you talk to the product owner and they'll add it to the backlog - at a priority they choose.
You don't barge into the team's area demanding "just this one quick fix", there's a clear process to get your stuff in the queue.
If your workplace already works like this, you don't need agile, scrum or any other method with a fancy name. Keep doing what you're doing.
Agile is a way to save developers in orgs where it's normal for the sales guy to come in to a team's room and announce that they sold feature X to a client already and it needs to be delivered next Friday.
> Agile is a way to save developers in orgs where it's normal for the sales guy to come in to a team's room and announce that they sold feature X to a client already and it needs to be delivered next Friday.
How does it do that? If the sales guy sold feature X to a client you're going to have to build it -- Scrum be damned. Some process is going to get in the way of making money? I don't think so.
That's why it only works properly when there is FULL buy-in from the C-level down.
EVERYONE in the company must acknowledge that there is a clear process on how to get new features implemented and randomly barging into the team space demanding features is not it.
But I don't need Scrum to get buy in of non-shitty processes from the C-level down. I have that already without Scrum. Clearly people are doing Scrum that is awful. So it's neither a necessary nor sufficient property of Scrum itself.
I agree that not having management/sales directly involved in low-level development planning is a good. But that's not Scrum.
> As others said, it's also a way to try to treat developers as assembly line workers
Yes, a constant reminder that, even if you are highly paid cog in the machine, you are still a cog that can be replaced at any moment.
Because, you know, real decisions about what the product have to be made by a businessy dude, while developers are relegated to playing with their ci/cd and expensive toys. I guess what pisses me off the most is the patronizing attitude. All these methodologies scream: 'I don't trust you, so I will flood you with process where I can micromanage you'.
If you keep missing "deadlines", you aren't planning properly. You can always take more work for a sprint, don't overcommit.
Product Owner is just the one who prioritises the features the team implements, they're the one whose job is to know what the client wants and translate it to more technical terms and individual features.
Sprint planning is just... planning what you'll do for the spring? Don't you usually plan your projects or do you just YOLO it? Standups can be just two lines of text in a daily Slack thread, but usually it's handier to just gather around and go through what you did and what you'll be doing.
Demos are the best part of Scrum, you get to show what you accomplished to people who understand the client's requirements and you'll get immediate feedback for the next sprint.
What kind of project model do you like if Scrum is The Devil Incarnate? Who takes care of customer requirements? Do you plan your time use? How do you teach other people in the company not to bother the team during implementation?
> Standups can be just two lines of text in a daily Slack thread, but usually it's handier to just gather around and go through what you did and what you'll be doing.
Why? So a middle manager can create a report and submit it to their superiors? What if we omit all these reporting steps (and the middle manager) and gather when there is need to gather only? The team knows what they are doing, they can see it in each other's commits and each other's tickets. Who are you trying to inform/report to here?
> What kind of project model do you like if Scrum is The Devil Incarnate?
Kanban
> Who takes care of customer requirements?
Developers. You can also implement a feedback form and read it as a team.
> Do you plan your time use
Roughly. If we knew exactly what each thing entails to plan it in detail, that'd be waterfall. Or scrum, which is mini waterfalls one after another, never ending. That time you spend on planning, better spend it doing, and without a ceremony master.
> How do you teach other people in the company not to bother the team during implementation?
We told them once. If you have a problem when business types are barging in all the time and bothering your devs, maybe the business types can get a course in patience and basic manners?
So you know at all times what everyone in your team does? Do you chat constantly with everyone on your team? Nobody just hunkers down and does stuff for a few days?
It's these cases where the standard checkup time (daily standup) comes in handy. It's not for "the middle management", it's for the team to know how everyone is progressing.
--
How do you manage releases with Kanban? Do you have a release train and release whatever happens to be complete at the time it leaves the stateion or something else?
--
So Developers take the time to arrange a meeting with the customer, talk with them about their problem, write down the features etc? And this is fine, but spending a Monday morning every two weeks planning a sprint is anathema?
Nobody in the team is an introvert who considers root canal without anaesthesia more enticing than spending a full day talking with non-technical customers about project requirements?
--
You clearly have the cojones and corporate political power to tell business types and middle managers to fuck off. Many MANY other developers do not, if they tell the sales lead to fuck off with his "urgent" requests mid sprint, they'll be looking for a new job the next morning.
I have seen multiple teams using scrum and not a single one of them was happy. Members of literally every one complained when having a safe option to complain.
Scrum is widely disliked by people who work on teams. It is liked by managers and consultants.
I haven't read the article but in response to your comment here:
Scrum is widely used and also widely disliked. I find that apologists for scrum generally excuse the dislike as 'that's not how scrum is supposed to be implemented' - just as you have here. It's exactly the same form of argument you get from apologists for Marxism or Communism when confronted with the widespread dislike for those systems. If something has generally failed wherever it has been implemented, it's not because it hasn't been implemented properly, it's because it is fundamentally broken.
What I said is much more nuanced. I certainly wouldn't call myself a scrum apologist.
There are good implementations of scrum, and there are teams that like it. In my experience across companies and industries, it's a much larger percentage than unfounded comments like yours and the article would lead you to believe, perhaps 30-40%. Probably due to the SV slant on this site (also why people here always think they know everything). It absolutely has not failed everywhere it's been implemented, and starting from that position is simply incorrect.
My position is that the article (and you) are making incorrect assertions and that you don't even consider that it's a possibility.
Again, your experience is not universal. Stop claiming or thinking that it is and that you know everything. You don't.
I've been on teams where we got to pick what we could deliver in a sprint and utter peace to do it for 2 weeks. Daily scrums were mostly skipped and lasted 5 mins max while we had our morning coffee, standing up.
I've been on a team where "daily scrum" was a 30-60 minute daily Skype call with no agenda, goal or point. The only thing related to Scrum in that company was the terminology, basically a cargo cult.
I've also been on a team that used scrum terms and kinda sorta the process but it was closer to Kanban with releases. But it didn't matter, everyone on the team had 15+ years of experience.
For an example of what I mean, consider this:
After the manifesto appeared, Scrum quickly declared itself to be “agile” in spite of its ...
But Scrum existed before the Agile Manifesto was created, and the creators of Scrum - Ken Schwaber and Jeff Sutherland - are signatories of the Agile Manifesto. So no, Scrum didn't just "declare itself Agile"... Scrum was part of the Agile movement from day 0.
But towards the end the post does get to an interesting point, which the author summarizes as:
If developers want the freedom to write software in sensible ways, they need to enter the market directly as either founders of companies or freelancers instead of through the comfort and convenience of existing companies.
There's something to be said for that. I've always said that a lot of the core issue here is exactly the "impedance mismatch" between the way engineers see things, and the way "the business" sees things. One way to resolve that - albeit perhaps not the only way - is what the author proposes above.