Personally, I think SAFE or Agile/Scrum are good starting points.
The key part, however, is teams, departments, and companies, then modifying their actual working by eliminating ceremony and process.
The way I think Agile/Scrum/SAFE should work is that you expose all the teams to all the ceremonies, and all the different alternatives to each of the ceremonies to start with, but you also mandate thst 6 months to a year from now you should have reduced 50% of the ceremonies you started with.
The goal should be expose people the universe of options and ideas available, and then once exposed, require them to pick and choose between all these options to tailor their own customized solution which works best with the people on their team and the working styles and the kind of work they’re doing.
I heard an interesting perspective for startups - Kanban/Scrum is useful sometimes before launch, and not using scrum after is beneficial.
Mostly because launching changes so much.
Part of me does feel sometimes that ceremonies are for making sure the development practice is highly inclusive, including for new and less skilled developers still learning their ways. Another part of me thinks about how this also helps more people to be able to generally help with more of the codebase.
I think writing code for your future self or someone else, in a way you'd like to receive is critical to think about. This can include doing things the simpler way even if it's more verbose and more understandable. This isn't always possible, but more often than not, avoidable complexity also can encourage the engagement of a lot of ceremony around it. "Could this have been simpler?" is one useful question for code reviews.
It is a good question but the answer may be unsatisfactory: it depends. I think that the popularity of scrum is due to its catch-all nature and the way it sounds reasonable when you explain it to someone, especially a non-developer.
Here is an answer that (I believe) works well: Hire a team lead that is willing to shield a small dev team (less than about 7 people) from the politics above. The devs still talk to users and other people in the company but they do not necessarily have to be accountable to them. The team lead understands the company’s budget cycles, has a vision for the product being developed and, importantly, has the time to sit down with each developer on the team to look at what they are making. Not a code review but a regular show-and-tell kind of arrangement. The fine line in this approach is to make sure it doesn’t degrade to micromanagement and ego poking.
Sometimes a lot can be understood from the team and it's current process in terms of where it did, or didn't come from.
Having a team lead that is technical as a product manager can be very helpful as you are outlining. Being able to speak the language of and maintain the respect of both is so valuable in terms of "getting it".
Clearing the way for devs to learn and do with customers and each other is the other key thing I think about a lot.
Startups likely have less politics (hopefully) but the longer they operate as startups politics likely increase, or hides itself better.
When I see startups leaping to hire VP engineering, etc, I can't help but think of my own experiences where having the founders at those seats translating what is being learned from customers directly into the product was so critical.
For existing or larger organizations, I think what you're saying is very true.
This is a very unsatisfactory answer - but you have to grow a culture. Working with people to match their personal goals with organizational goals. High degree of mutual trust. Cooperative design. Group ownership of the codebase and rotating responsibilities. Lack of 'magic knowledge'. Sufficient infrastructure development to reduce rote workload on developers.
All of these are organic rather than formulaic. They require limited rates of growth to enculturate the new hires, and a seed group that understands this.
That works. But you can't hire a consultant to build that, or write a book about it. And bad elements in the mix can mess up the whole thing.
No, you're totally right though - culture is everything, and the experience of being a part of a team how it works is everything.
I heard an interesting explanation the other day, hard skills are easy to measure, and soft skills are hard to measure, but developing soft skills can be are more important than hard skills.
Start with keeping a very flexible core and codebase.. feed it with launched code from a plan that balances bug fixes, progress forward, and customer needs from the business.
This meant having a backlog, and by scoring each item on criticality where 1 was critical and 6 was someday/maybe, and whether it was internal facing, or external facing (customer is aware), you could almost start selecting what was done and ready.
Would love to hear anyone's processes they used that have worked well for them from start to growth.
We do a very loose agile process and everyone seems to like it. Basically, we have a standup every morning. Each team member has up to 1 minute to list (in very brief form) what they did yesterday and what they plan to do today.
It identifies if anyone will be stepping on anyone else's toes, or if anyone knows of something similar and can point you to it, and it lets the project manager know if anyone is working on something that can be traded for a higher priority task that just came up.
Most of the time, you work on what you say you're going to work on. Sometimes, the project manager will call you after standup to get more detail and/or adjust your priority to a different task.
This standup is the only formal meeting the developers go to, other than the odd department/company wide meeting. The project manager goes to all of the other meetings.
We are the most productive team in the company. I think the autonomy and the lack of formal meetings are the real magic. We're fully remote and talk to each other plenty throughout the day in an adhoc way, sometimes for fun and sometimes for technical discussions, problem solving, brainstorming, sanity checks (technical and personal), etc.
"what they did yesterday and what they plan to do today" is not something you can read off people's commits
"I was figuring out how to add a doohickey that widgets foobar" is not a commit, but during the daily someone else might remember that there already is something that can widget foobars. Or they might know that widgeting foobars was tried before and it failed because X and Y.
Then they won't start debugging that during the daily, but will point it out and get in touch afterwards along with others that might care. Either on a $TEXTUAL_MESSAGING_APP thread or $VIDEO_CALL_SERVICE call.
To my experience 10% of software developers think 7 am is morning, 60% something between 9 and 10. 30% not before 11 or 12. The first and the last group tend to be the most productive ones.
Forcing all of them to meet at 10 or even 9 is the best way to kill motivation and foster cynicism about useless meetings and processes.
Each person is limited to 1 minute, and most people only use about 10-20 seconds. So, the meetings are usually done in less time than it takes to go to the bathroom. I think everyone sees the value in calibrating our trajectory for a few minutes every day -- it often saves more time than it consumes.
I developed an alternative called “Hot-Potato Agile” while at Google. I got buy-in to try it, but then was laid off in January just before we could start. So if you have a team that likes sprint cadence but hates the scrum busywork and is open to an experiment, let me know! I still want to flesh out this thing’s rough edges.
Why would you hate spending 1 month out of 4 for “planning” and then 40% of the time in the remaining 3 months also for “planning” resulting in a massive destruction of productivity all so you can now claim that “yeah, you delivered a fraction of what the company was delivering pre SAFE, but at least we planned on delivering a fraction of what we delivered Pre-SAFE.”
SAFe is the next buzz word laden cancer to infect the enterprise. It will bring Business Agility(tm) to areas of the business beyond software development.
Typical immature bullshit where someone describes their own company's screwed-up incompetent so-called "Scrum" and "Agile" implementation, and then claims that that's universalizable amongst all companies everywhere.
Just because a so-called "Scrum Master" not worth the title is forcing you to do BS things that inhibit your flow does not mean it's emblematic of the species. I mean, how would you feel if someone generalized all developers as a bunch of fat neckbearded social cripples reeking of BO? Same thing here.
I ought to bookmark this post in case anyone thinks that people on HN don't try to farm karma Reddit-style. What a crap bunch of outrage bait.
Typical Scrum apologist who describes how someone else must have screwed up Scrum or Agile. They then claim that pure "Scrum" or "Agile" has never been implemented anywhere.
If only people weren't so ignorant, we could give pure Scrum a try and solve all the world's problems.
> They then claim that pure "Scrum" or "Agile" has never been implemented anywhere.
They are right, however the conclusion that should be drawn from this is that the most likely outcome of your organisations implementation of agile will be equally as poor, and that it should prolly be skipped.
This is a No True Scotsman argument. The guy enumerated a list of ways scrum failed in his experience; it's always interesting to hear honestly about failure modes from people who have actually used something a lot in their work.
It's interesting to hear about failure modes, and anyone whose job it is to teach stuff like this is interested in hearing about failure modes. It's the taking of one person's experience and extending it to encompass everything that's wrong.
Obviously the people charged with implementing this in OP's company are doing it wrong. That doesn't mean it's OK to insinuate that everyone who ever tries to implement Scrum or Agile is doing it wrong. For every clueless toxic manager who doesn't understand how to use Agile correctly, there's an egotistical or lazy dev who also wants to throw what the Brits would call a spanner in the works for purely personal reasons.
But to call it a No True Scotsman argument is a lazy rebuttal which won't engage with the argument. There are plenty of shitty Agile practitioners, and no one is trying to dispute this.
> For every clueless toxic manager who doesn't understand how to use Agile correctly
Anecdata Of One: I have worked at many places since 2005 and the most successful projects have been those without any Agile[1]/Scrum imposed by management. In contrast, the places with the worst outcomes[2] have all had distinct Agile/Scrum imposed by micro-managers[3].
[1] Plenty of places with iterative development but solely due to the nature of the work (changes required by external QA, experiments, etc.), not imposed.
[2] Software quality and speed of development-wise. They're all still alive and limping along despite the horrific nature of their internal systems.
[3] Who have always been there in a place with Agile/Scrum. Only once in a place without. I don't think it's coincidental.
The same thing works the other way. People see and experience shit Scrum and then they No True Scotsman it to mean that all Scrum must be shit.
It seems to me that most American software companies use Cargo Cult Scrum. They basically take the terms and maybe read a blog about the processes and just wing it from there.
The only way an Agile/Scrum process works if you bring in a consulting company that's expensive enough to make even the top brass buy into it. You can theoretically try to bring it in from the ground up, but it's really hard to do Agile when the rest of the company is either waterfall or flying by the seat of their pants.
"I'm sorry that you're personally offended. See, you disagreed with my pure, sweet, logical opinion, which means you must be personally offended, because no REASONABLE person would disagree with me. And because you're offended, you operate on emotions, as opposed to my high-and-mighty self, who operates on pure, sweet logic. Thus I am right and you're a crybaby, because you dared to disagree with what I consider to be my pure, sweet logic."
In a large organization, this will change nothing. All you can do is be in a trusted position with upper management, and spend your political capital to prevent it. Even then, it may not work if some exec has implementing it as a goal to help their prestige/career.
Sure, but "Stop going along to get along" is how all these agile processes spread in the first place.
Opponents were ridiculed and bullied by proponents for being boring, old, unmodern, not team players, not using best practice or whatever. And way too many programmers were actual believers for grumpy safeguards to be able to keep things in check.
I think a cooperative approach might be better to get rid of agile or it will just be replaced by some other dogmatic cult. Agile is more of a symptom than the root cause.
I think it's just best to call out BS when it pops up. That would have put a stop to this before it ruined everything. Cooperation is good, but people need to be told they are wrong. It's ok to be wrong. Everyone makes mistakes.
I’m a solo consultant and have had many good client relationships based on agreeing on deliverables. To summarize according to the old “pick two” adage of delivered-fast, works-to-spec and cheap: I’m fast, reliable, and expensive. I deliver high value and I’m always available to answer questions.
Interestingly, me consulting solo at an hourly rate doesn’t scale. To solve this, about 5 years ago I started a side business of building an electron app for designing and printing labels. I feel like scaling up allows my customers to pick all 3. The app is immediately available, it works, and it’s inexpensive.
So there’s another way to avoid agile and scrum: solo entrepreneurship.
Interesting phenomenon happens at my place which is scrum + Safe. Our team gets publicly dinged if we "carry over" tickets between sprints, so if we finish our work with 2 days left the manager asks not to start anything new.
The process is a performance within a performance, literally getting told NOT to do more work. This is what happens when you have chart-oriented-development (particularly jira's toxic charts).
You might think this is nice to have free time to sit around, but frankly it also drains a lot of the joy out of my work, takes away my sense of autonomy and pride in my work and leads to some resentment.
Our solution for this is to have nebulous time sucks that need to be done, but don't have a ticket with an estimate. Like "increase test coverage" or "experiment with new things for a git hook to do" or "eliminate warnings". There's no deadline, and everything else is higher priority- but when you finish your sprint early, now you know what you can work on. And it's useful, not just scutwork.
I work on a very small scale nowadays, but what I have found to be helpful is "weekend fun" tickets. Nice to have things that I wouldn't do otherwise but are fun when I don't have the energy for other stuff / when I consciously try to reward myself.
At a place I worked the management decided that a "story" should always be completed within a sprint. So what did we do? We started using stories instead of tasks and epics instead of stories[0]. And voila, now magically stories complete within a sprint!
[0] Just writing that sentence makes my eye twitch
Similarly, in order to fit stories into a sprint and not spillover, there is the constant fixation on making stories "as small as possible". So now people make a story for adding a button, then another story for the click handler of the button, then another story for saving data into DB when button is clicked, then another story for adding the tests, and so on. Then the sheer amount of time talking about how to split that up and adding all those into JIRA...
It kind of is. Well, the public dinging probably isn't. But at a few companies I've seen, teams are tracked on how many tickets span multiple sprints. If it exceeds some threshold, then theoretically it means that either:
1. The team is not breaking down tasks granularly enough, or
2. They're not estimating tasks correctly
The scrum guide [1] says team gives a forecast and not a commitment. I have yet to know any other scrum practitioners aware of that update.
Unless a person has no shame, failing a commitment I certainly believe is intrinsically shameful. Some cultures would commit seppuku if you don't deliver on a commitment.
The words, "you failed on your commitments" seems very much like shaming. Thus the move to "forecast" over "commitment"
*edit (addendum): Invoking 'seppuku' might be a bit sensationalist, my apologies. The southerner in me is coming out - saying someone does not live up to their word is a very big deal.
Ah yeah I had a boss that wanted me to open tickets, estimate them, plan them, do them, to fix 1 line issues that I would randomly find working on other tasks.
Normally I just fix them within a separate commit.
I can totally relate. We are not told not to do more work but at sprint planning if someone thinks a ticket would spill over then they should add it only to next sprint. So we do less work just to not spill over.
This. I moved from being the Main Tech Guy at a startup to being a backend engineer at a mature company running Scrum. I was amazed by how little work anyone did at the mature company. People obviously doing f-all during the day. If we finished our sprint 3 days early then we just pretended to be working (what is the point in having a standup every day when there are no tickets to work on?).
It was painful. I constantly felt that I should be working, because I was being paid decent money. But there was nothing to do, and no-one wanted me to do anything. I couldn't focus on a side project because I felt so guilty about taking their money and not doing anything.
We adopted Mob Programming. Five senior engineers on one call writing one piece of code. Or rather, one of us teaching the manager some Golang while he spent 4 hours doing a ticket that should have taken 1 hour. No stakeholders present because none of them wanted to waste a day watching us work.
> I couldn't focus on a side project because I felt so guilty about taking their money and not doing anything.
That’s what I hate about these wasted “pockets” of time.. you don’t have work to do, and you can’t focus on doing your side projects either, just a waste.
As a consultant with 25 years of experience in enterprise software for sizable corporations and universities, I have observed numerous development shops. The number of individuals in corporate America who accomplish little throughout the day is astonishing. This phenomenon aligns with the Pareto principle, wherein 20% of the workforce completes approximately 99% of the tasks and the rest are dead weight.
From Peopleware: “In the 1985 Jeffery-Lawrence study [from the University of New South Wales]…they investigated the productivity of 24 projects for which no estimates were prepared at all. These projects far outperformed all the others…Projects on which the boss applied no schedule pressure whatsoever (‘Just wake me up when you’re done.’) had the highest productivity of all.”
I read 20+ books on management and leadership[1], and none of them mentioned anything like Scrum. I agree it's BS.
Our team is the only one not doing “scrum” or estimates or shit. Our team is the only one far ahead because we don’t waste our lead engineers’ time and allow them to move at their own pace (that means very fast). I just have 15 minute dailies with the other senior and the manager to stay in sync.
While I too despise Scrum, the causation could be runming the other way: the Bosses that have a better team could be more likely to let them run without major pressure.
This problem exists at big tech and startup, in companies that spend fractional multipliers of the average salary on engineers as well as those who pay poorly.
In this environment, if your solution is "hire better people', you can't- there isn't any
If CEO can hire a 100$ scrum master to save a 1000$ failing team, it's much cheaper than hiring 2000$ successful team. That's probably what they're thinking
I don't think that's true at all. If there's time-to-market pressure (for example), then you really want that $2000 team to deliver on time. "Saving" the $1000 failing team with a $100 scrum master may not be good enough.
Also, please at least acknowledge that your numbers are completely made up and may have no basis in reality. It might be a $1000 team only if they deliver on time, but the overages might push that to $5000. Or whatever. See, I can completely make up numbers to support my point too.
Sadly the $1000 team doesn't get saved by the $100 scrum master though.
You are 100% right that legacy management falls for the SCRUM sales pitch.
At one company I worked at the scrum salesman basically bullied the executive team by saying "You don't want to be the last company to adopt scrum do you?!!??!"
Top programming talent may still need to be managed (and in fact may need to be managed more than lower quality talent). The sweet spot is to hire top programming talent who is also good at intra-team communication and can organize themselves with little direction from management except to be informed about outside factors like client priorities.
Even better is top talent who can also interface directly with the client when necessary (not necessarily all the time) and doesn't need everything first filtered through a manager.
I've worked with teams like this in the past and it was always a pleasure. Most of them were fairly experienced devs and knew the value of email, phone calls, and water cooler talk (serendipitous discussions which led to valuable information being exchanged). Despite the lack of "modern" productivity tools like text messages, chat apps, and Slack, we were able to get stuff done efficiently.
We had weekly meetings which were productive and useful, and actually helped identify if anything was falling through the cracks. Nobody got bored because the meetings were actually helpful.
The people who implement Scrum are insecure managers. They don't understand the development process, don't trust their staff to just get on with it, and need constant reassurance that their project/product is making progress.
So it would have to be both: the devs are good and don't need hand-holding, and the manager is able to deal with the lack of transparency that "it'll be done when it's done" comes with.
During a certain phase of my career, I was part of a company that extensively used the Scrum framework.
My takeaway then was that Scrum fosters a modular team management style, which diminishes the dependence on highly skilled individuals.
This approach seemed to offer management a sense of oversight in the software development process, but I didn't stay long enough to determine whether this was actual control and predictability or merely an illusion of it.
I re-read Peopleware this last weekend. It's one of my favourite books on the topic of software management. There are chapters that are not very useful for the $current_year (eg. regarding telephones or office furniture) but overall it's a fantastic piece on human interactions in the industry.
Scrum gives me the same impression as liberal economics. An intellectual tradition centered around quantifying things that can't reliably be quantified, as well as projecting incomplete models on top of reality in service of economic interests and insisting that they are correct.
> Scrum is a cancer that will eat your development team. Scrum is not for developers; it's another tool for managers to feel they are in control.
Agile and Scrum are for managers who don't know what they want, but they'll "know it when they see it". (Or more likely, they'll declare that they wanted is what they've got when the money runs out.)
agreed, Agile and Scrum are not the same, and if you read person's followup comments, even he says "he believes in Agile" but hates Scrum.
Yeah, most aspects of Agile (iterative development, MVP...) are fantastic and it has made most types of engineering lighter, more team-focused and well more agile.
If you're in a situation where someone is suggesting applying an off-the-shelf process like Scrum or SAFe, you've already lost.
> 3. We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.
This continues to be one of the most aggravating parts of capital A Agile software development. Forcing people to be uncomfortable to make them talk less is something a child would come up with.
Clever management technique in a shop full of blunt knives will only get you so far.
With my team, we’ve focussed on developing talent just as much as we have on getting the work done. By improving skills through senior-to-junior coaching and code review we’ve built a much more cohesive team that’s better at what they do and can complete tasks which they couldn’t do before. Dexterity and fluency with code was more important to us than organisational skills.
Perhaps I’m missing the point and Scrum is only for people at the top of their game? It didn’t feel that way the few times I’ve seen it — to be a little bitchy, it appeared to be quite the opposite.
Scrum puts "feel good" limits around the unknown qualities of time-to-complete and "divide and conquer"
You still don't really know when it will be ready, but you now have talking points with management about a) whats been done and b) how complex it is. This builds belief: Belief there will be a solution, and Belief you can find it.
Nothing not said better by others here, but I say this as a party who was dragged kicking and screaming into the process to be an agile product manager, hated it, and got out. I totally "get" why people want this. It's very rare to be a Bell Labs, or Xerox Parc, and have pretty much complete freedom to spend budget and deliver an outcome when it's ready.
I also have worked on large s/w projects which cost $16m to fail to work, and $60m in lawsuits out the other side. I know that the alternative (a massive proscriptive playbook of minute details of functions, UML, flowcharts, you-name-it) exists and works, or not (depending on your point of view).
Really? I think scrum was the wrong name. The process itself, is fine. Talking to your co-workers builds a sense of purpose and direction.
The individual was born in the unitary Marxist–Leninist one-party socialist republic of Cuba and lived there for a bit under three decades. He might have some expertise on the topic.
I agree it's rarely "done right", but I've been in career long enough that waterfall was still common early in career and horrible crunch time targeting some date at end of 9-12 months projects was inevitable - Scrum was a total breath of fresh air back in 2005-2006 and saved my sanity.
Basically we'd ask mgmt "what do you want next?" and they had to fuck off for the next 4 weeks while devs, ux, QA worked with no changes in plans until next demo and release. They were responsible for figuring out "when will everything be done?" etc.
I recently left a startup that said they were "doing Scrum" and it was just daily task tracking and pushing devs to overcommit to each sprint - that's not what I consider Scrum.
I should clarify: we had one of the early Scrum guys (Ken Schwaber) come in and train devs, QA, UX, and management - so there was little room for people to hide behind random interpretations of "agile" and it really helped us to start out correctly.
Yeah, that's definitely not Scrum like you said. The whole point is that the team promises to deliver features during a sprint and won't overcommit, they might deliver extra if they have extra time.
If your sprints continuously fail to deliver, then you need to decrease the team's velocity.
Yeah it was really messed up - their "velocity tracking" was so they could make sure devs committed to at least as many points as the last sprint, even if they didn't finish the last sprint.. I only lasted there 4 months before I quit.
I’ve developed a more nuanced view on Scrum since working as a contractor for a medium sized software company, but adjacent to their normal dev teams.
I used to have the view that Scrum is a useless batch of meetings, that sucks the life and productivity out of the dev process.
Now, after seeing it from an adjacent (but not subjugated under it) perspective, I think it is a life-sucking batch of meetings that are good for one thing: taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them.
Most of us here are not in that category. I’d wager a majority of HN readers can’t help but to seek out understanding of the business, where this piece fits, what it interacts with. For us, specifying everything upfront is useless. Estimating stuff is irritating because we need the flexibility to make smart decisions during dev. Retro meetings are lies because we can’t say “stop with all this and let me work”.
But if you’re trying to make a process than can take junior devs (not junior in tenure, but junior in the qualities above) and produce an output that scales almost-kinda linearly with dev count, it sort of works.
I’d argue that you’re way better off hiring 6 devs that can go from business problem -> technical solution in their head, without all the ceremony, instead of 40 devs who can’t and 6 PMs to wrangle them.
But I can also see how a company ends up there - go through a tough hiring year, or even just make a few poor hiring decisions, and now you have people on the team who need handholding and supervision. That’s what scrum is; it feels like micromanagement because it is. It forces junior-performing devs into a productive state - maybe 5% of what you’d get out of a senior-performing dev without scrum, but it’s something non-negative.
I agree with this. In my experience: these "rituals" are a way to force the conversations that a "senior" - in your terminology - dev would naturally have.
But what to do when instead of 6 competent and efficient devs you get 40 people with random mix of skills, no domain knowledge and at moderate programming talent? I dont know Scrum to comment on it, but many management methods converge to 'appear that work is done all the time even if it's just meaningless bureaucracy, make everything slow and inefficient, but manage the expectations - so customer is moderately disappointed all the time but there are no catastrophic failures. And make sure there are no red lights on the dashboard, ever.'
> But what to do when instead of 6 competent and efficient devs you get 40 people with random mix of skills, no domain knowledge and at moderate programming talent?
Leave.
That sounds like it's someone's problem, but it doesn't need to be yours.
> I’d argue that you’re way better off hiring 6 devs that can go from business problem -> technical solution in their head, without all the ceremony, instead of 40 devs who can’t and 6 PMs to wrangle them.
The problem is that finding those 6 experienced devs is _HARD_. And they're usually very expensive and know their value.
You can easily find 40 mid to low level coders and a half-dozen people who know how to run a scrum team. Maybe even some of the coders know how to do that for extra savings.
Also in the latter way you can easily have a turnover in the team without any major hassles, you can always find mid-tier coders.
But if one of the 6 highly experienced ones leaves, good luck finding a new one quickly.
A shitty car analogy: You can get a more efficient and faster car if it's 100% custom made. But if something breaks you need to manufacture the parts. Or you could make do with a less efficient and slower car, built out of highly standardised off the shelf parts.
I have been taking a closer look at project management and product management in the last few months. Coming from the programming side, I thought technical product manager rule the world, and thought everything that is technically led is glorious.
Then I had a very personal conversation with hardcore project manager from non-tech side. He told me that, I got the idea of management of all wrong.
Project manager is an operator where the engineers are nothing more than machine. Your standard engineer is not interested or even care about business goals. They are doing a job, they like to be told what is expected from them, they like to be told what deliverable is. Senior engineers can give an estimate of delivery date, but most don't. They are essentially cogs in the machine and managers are expected to birth products from them.
About those experienced devs: In an manufacturing plant there are things that just works and you don't fiddle with them. Or else, they break and you have to get a brand new thing. Most of these senior engineer with business focus are difficult to manage and they have an expiry date on them. You are lucky to get one, but you have to count the days until they leave for better pay. Moreover, you don't want programmers interested in business side as they get passionate about things that don't concern them which is obviously business side things. So, you need engineers to work but not get ideas.
---
He told a bunch of those stories, but it seems these stories are like if you are in the business, you probably know already type things. He really doesn't buy the idea that "software engineers" are special type of engineers, he said, management hasn't change in centuries, people just use different rhetoric that's all.
"Software engineer" is a special category in that people think you can train someone for 3 months on React and Node and shove them into this line of work and they should be fungible and just a green version of the real thing.
The high demand, high pay and low general understanding of computer architecture all fuel this race to the bottom and we all pay for it in low quality, overtly complicated and vulnerable software and all ancillary industries that spring around it. Coding "bootcamps", "Cybersecurity", Agile/SCRUM, Wordpress and clones, AWS and clones etc etc.
> Project manager is an operator where the engineers are nothing more than machine. Your standard engineer is not interested or even care about business goals. They are doing a job, they like to be told what is expected from them, they like to be told what deliverable is. Senior engineers can give an estimate of delivery date, but most don't. They are essentially cogs in the machine and managers are expected to birth products from them.
Yes I think you got to the crux here - managers want to be indispensable and make everyone else "a machine" so he told you a bunch of self-serving bs. I'm sure if you turn this around on him then project manager will not be a machine but more like a wizard or an artist whose needs must be carefully tended =)
> Moreover, you don't want programmers interested in business side as they get passionate about things that don't concern them which is obviously business side things.
Right and who is better to help here than someone who can take business requirements and hand them to the engineers? You know, someone who got people skills!
Having been on both sides of this, and having worked closely with "the business" doing requirements analysis, project management, tech-leading and individual development, my conclusion was that your original view is somewhat closer to the right one than the PMs.
One may ask, from where does the tech industry come from? From where tech startups come from? Why is there such a thing as the "tech" industry at all? Don't all companies use tech? We don't talk about the "science industry", do we? If you try and find a definition of tech firm that captures what people mean when they say this, you'll conclude they're basically either computer companies or ordinary firms doing ordinary things, who use computers more effectively than normal. And in the latter case what makes a firm a tech firm is basically unarticulated, people know it when they see it but it's not like there's a set of rules to classify, say, Netflix as a tech firm and Disney as not a tech firm.
So what is it that people see? Mostly it's the distinctive culture that appears when you have (ex-)programmers at the very top of the company, as in CEO and/or board level. This causes companies to differ in all sorts of ways, but one way in which tech firms differ, for example, is that in tech firms you don't get terms like "the business" and "IT". You don't get non-technical project managers. The distinction between the two sides simply doesn't exist.
Non-tech firms live in fear of tech firms and startups. It took me a while to notice this, but go to enough conferences, talk to enough people and you'll see it. The average firm is far more scared of Google or Apple encroaching on their space than they are of an established competitor. This is because tech firm culture is more effective than their own. Such firms have a long history of coming from nowhere to utterly dominate entire industries very fast, and they don't know how to respond to it.
The cultural problems can be seen in the stories you were told. Programmers who understand the business are too expensive. They get ideas. They get passionate, and that's a problem. In a tech firm, experienced devs who understand business end up at director level or higher and firms compete to pay them the best. In non tech firms, they are a problem and get pushed out. This is because the business people are scared of such devs because senior developers end up understanding the business better than the business people do. After all, they implemented the business logic so every rule, regulation and detail is in their mind. And they're used to the rigor demands of programming, so tend to say awkward things in meetings like "that won't work" or "that contradicts the other thing you just said". Tech firms don't mind this because that guy's boss is himself a former developer, and is used to such discussions (from e.g. code or design reviews). "Business people" on the other hand aren't used to this at all, yet feel like their value is their business understanding. They need their devs to be bored and uncaring drones because otherwise what's their own value? You don't want to be competing for a promotion against someone whose understanding of the business is better than yours and who can actually execute change projects effectively!
Underlying all this of course is the uncomfortable fact that programming is much harder than most office jobs. Programmers can and will learn programming and then go on to learn the fine details of finance, accounting or shipping without breaking a sweat, but the reverse is generally not true. It was maybe to some extent in the Visual Basic era but the move to web apps put a stop to gifted amateurs cobbling together business apps and nothing really replaced it (maybe Oracle APEX but it's not as widely used).
This, and more. Like it or not,the incredible success of software made it an industrial affair, the way clothing industry went 200 years ago - from highly skilled artisans creating unique beautiful designs tailor specifically to their customer to cheap patterns industrially printed. Its just that the printers are still human.
Yeah, very comfortable sweat shops for highly paid manual laborers. Why do you think open seating plan exists?!? Open plan is the default layout of a standard sweatshop.
The key observation is that they successfully made the "design" of software they "mass duplication" part. The cost of designing and creating crappy custom software has never been so low and it continues to fall.
You do know that there are steps between bespoke tailor and exploitative sweat shop, right?
Multiple steps actually.
(And in some cases the alternative to the "sweat shop" is the same amount of hours outside in the fields with fluctuating income based on what happens with the crop that year)
> Also in the latter way you can easily have a turnover in the team without any major hassles, you can always find mid-tier coders.
And turnover you will have! =)
Note that you just ballooned the cost probably 3-4x compared to keeping the team small and strong. And that is how we got to this zombiecorn land we see today.
Also consider this - hiring a large team of bozos is a one-way street. You will likely never be able to hire and retain strong talent ever again. While you can always turn to hiring "mid-tier coders" when the product matures.
All you said is true. But the number of talented programmers is very limited and concentrated. And they are quite expensive. Most companies and teams have to go the structured approach with whatever local mediocrity they can hire.
Most people work in most companies that mostly fail over time. Making a living is the goal with work, building enduring value is something that few achieve.
One thing to remember is that every superstar used to be a mid-tier coder. This is not an YA novel where talent is decided at an arbitrary time and that's the lane you'll hold until you retire. =)
When you hire people straight off school or "mid tier" people, you can help them grow to be better and reap the benefits.
If everyone will just hire the "top tier talent", their prices will inflate and the pool of top tier people will never grow.
There’s a pretty big difference between carefully seeding up and coming talent and deliberately hiring 40 mids like some folks are suggesting here to build their scrum teams or whatever. There aint going to be no growth here.
Over here we have a 6 month probation, during which you can fire people American-style by just saying "GTFO" with no reason required. (You can give one, but it's an art to tell the correct one, the wrong reasons will get you in trouble)
Yes, there are some people who shape up for 6 months and then start slacking, but they're definitely not the norm. You should be able to evaluate a person in that time and see if their personality fits the team and whether they are a net positive for the productivity.
> > I’d argue that you’re way better off hiring 6 devs that can go from business problem -> technical solution in their head, without all the ceremony, instead of 40 devs who can’t and 6 PMs to wrangle them.
> The problem is that finding those 6 experienced devs is _HARD_. And they're usually very expensive and know their value.
It's harder than finding uncaring juniors, sure.
But if you need 40+6 people, or 6 experienced people, that's nearly 8x salary.
In silicon valley money, you'll need to pay those uncaring juniors about 150K.
I guarantee you that you can very easily find those 6 experienced people in a few weeks if you're offering over $1M/yr to them. In a month you can staff all 6 positions.
If you're saying you want ~8x performance but not interested in paying ~8x salary.. then yes, it's harder to find the people.
The problem is that I'm not talking about Silicon Valley, it's an anomaly within an anomaly when it comes to hiring.
I'm pretty sure that short of John Carmack or a legend of that caliber I can't justify paying 1M to _anyone_ to the people making the budget.
Of course you can grab a half dozen superstars if you pay them a million per head, but they'll also leave the second the job stops being 100% interesting.
That's not a sustainable way to build a company or a team.
Yea, they f'd up a whole generation because of TRADITION.
There was a good video about this but the tl;dw is about this:
In Japan you're supposed to get hired straight out of school and then you'll stay with The Company until you retire.
The same tradition implies that The Company will _never_ fire people.
Japan faced some very hard times. Companies couldn't afford to hire new people because they couldn't fire the older people.
A whole generation never really entered the workforce because they never got the experience. Now they're mostly doing odd jobs and for the same reason never got married and had children.
> The problem is that finding those 6 experienced devs is _HARD_. And they're usually very expensive and know their value.
That’s not the only cause with all due respect, I have worked with several C-level managers before, they WANT those mid-low level developers/engineers, they are cheaper and easy to find like you said, but most importantly, they can replace them on a whim with another one who will do the same work, with “super” engineers, it isn’t the case, the amount of knowledge and depth one of them has, you will need a whole team to understand what’s going on first and another to carry on the job, and C-levels being egoistic, they don’t like anyone to have any leverage by any means.
I would fully agree with your point if I weren't regularly in daily were nobody listen to what being said : e.g. discovering by themselves what was said the previous day/week as it was a new piece of important information to share.
> Not everybody knows that, but Scrum was invented to manage a team of dysfunctional COBOL programmers at a bank, not for product-led tech companies, and certainly not for startups.
> If you're mostly hiring juniors, low-skilled, unpassionate, unable to work autonomously without constant handlholding, reactive instead of proactive people, then you'll certainly need some micromanaging SDLC like Scrum.
So funny thing... about twenty years ago I was managing a project with Cobol developers on one side, and this web thing on the other. And we had a bunch of business people convinced we were all stupid and lazy, so they wanted to force us to do this scrum thing. We would do things like a daily standup with them in order to go through the motions, and then we'd have the real meetings once they left us alone. Because the problem wasn't that the Cobol programmers were dysfunctional, it was that the business refused to actually listen and understand anything - they just wanted to make edicts, even when they didn't understand the regulations or processes in their own business (this being a highly regulated industry...). I pulled off what was perhaps the first project in that company's history that got delivered on time and met its requirements (and it was a big flipping deal of a project...) and the business people took credit for it and I got overlooked for promotion and life went on.
99.9% of “Scrum” you’ll come across in the wild is cargo cult. People performing the ceremonies with no fucking idea why, in the hope that the giant eagles will come from the sky bringing gifts.
Scrum was created to help good developers communicate with management. But the problem is that management has all the power and couldn’t give a shit. If the management was qualified to “get it” you probably wouldn’t need it.
So yeah, if you’re using Scrum, you’re probably going to fail: whatever the reason that you’re doing scrum? That’s why you’re gonna fail.
I once worked at a place that did Scrum for the exact reasons you mentioned.
Every user story was the same - “As a business owner, I want users to be able to do x”. Defeats the entire purposes of user stories. But they were told they had to write stories. So they did.
We also had our work planned out 6-12 months in advance.
It was top-down waterfall disguised as agile, which would have been acceptable if we didn’t also waste 5+ hours a week in daily standups (aka status reports), sprint planning, retros, story breakdowns, all of which were scheduled at the most inconvenient of times to ensure they interrupted your flow.
Ok, this totally resonates. What I want to know is how I find a place to hang out with those 5 other devs.
I’ve had that “team of six motivated” come together twice organically during my career. But it never seems to last. People move on, the company gets wind of the success and either normalizes it out, or attempts to try and distribute and harvest. If I could figure out the recipe to reliably locate or create that sort of team, I think I’d be very well off.
I love https://basecamp.com/shapeup approach - tiny teams with high independence and sufficient domain knowledge working in six week periods to deliver features.
> taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them.
Maybe in theory that's the point of it, but it practice it also (and mostly) has the opposite effect: it takes all agency away from capable developers and make them impossible to see the big picture, drastically plummeting developer productivity of otherwise very capable developers.
> Most of us here are not in that category. […] For us, […] is useless.
It's not just useless, it's actually harmful.
> But I can also see how a company ends up there - go through a tough hiring year, or even just make a few poor hiring decisions, and now you have people on the team who need handholding and supervision
But most of the time it's not how it happens: it's forced top-down by manager who have no idea of how software development work, and who are genuinely convinced that it is how projects should be run.
They don't realize that it's a workaround for terrible HR that reduces productivity for everyone, because if they did they'd probably think twice (“How is my HR so poor when I'm not trying to cut on costs there? Oh maybe it's not and I should not use scrum”), they just do it because everybody else does.
It works both ways. Every form of micromanagement will turn every dev team into a bunch of demotivated, junior performing, just here for the paycheck careless bunch of codemonkeys.
It is an assured loss for all.
Why not the opossite way? Trust people a bit above what they currently warrant, see who rises to the opportunity, and ease out the rest. This will over time elevate to a decent team.
The Netflix Culture deck[1] acknowledges that this strategy requires "top of market compensation." What percentage of organizations have the ability to pay top of market compensation? The answer to that is the reason why the strategy doesn't generalize.
I don't see where the document you cite makes this causal link. In my experience this is also not true. You pay enough for money not to be a concern. Then people start to value other things, such as not getting depressed through being micromanaged or killed by process.
>taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them
That's a very charitable view... I think back over my career and it was always cargo-culting and micromanagement. I give you credit for analyzing and finding a way to make scrum work beneficially.
The thing is - if you have people who don't (want to) understand the relationship between their work and business value, you've fundamentally got a hiring / personnel problem. And I don't see how scrum (or any other methodology) ever solves that. What you've got at that point is to me the difference between "programmers" and "developers / engineers". People who are more enamored with the technology than with actually accomplishing work. The thing is, some of those people are really good so long as they can be pointed in the right direction. But that's a management thing, not really a methodology thing.
I have been slaving as a cheap outsourced labor in a poor country for a large US software company. The goal of the scrum manager was specifically to prevent code monkeys from asking questions about "business/architecture picture" and to specify the tasks as narrow as possible. Anyone who asked too many questions was seen as a threat, as if they were going to communicate directly with our US masters and break the command chain.
Ye God I hate "chain of command" places. "Need to know basis" is the most toxic leadership type there is. Since my conscription it instantly makes my blood boil.
You always want to be able to sidestep your boss to your boss's boss of you need to. Or talk to end users and customers.
> I think it is a life-sucking batch of meetings that are good for one thing: taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them.
If I'm being onboarded at some project, I expect to be provided that description as early as possible. Compensating for broken communication by enforcing a life-sucking batch of meetings doesn't seem right.
Been on both sides of the equation as well over the past three decades. Two observations.
1) As you said, when you have a lot of junior developers (which given developer demographics is a given), you need some structure. Scrum provides that. For better or worse, the structure is helpful to people that are still a bit uncertain about how stuff works. I hate stand-ups as much as any other developer. But as a product focused CTO, I love that it gets the day started and my developers out of bed, awake and cafienated and focused on the job. Scrum's other meetings are a necessary evil. You need a platform to get them aligned with business goals. They don't naturally do this by themselves. Most importantly, a lot of developers kind of expect to this structure at this point. Providing structure to a team is important. Scrum is as good as any other structure. Not ideal with remote teams as meetings get more tricky.
2) Most scrum roles are junior management roles. And as such you get typically not very experienced people filling these roles as part of their entry into the corporate rat race. So, you get corporate politics playing out at the micro level with lots of turf fights about stuff that generally is close to irrelevant. Ranging from the right way to run meetings, the best issue tracker, etc. It's this endless friction that is causing a lot of resentment with more senior developers. Particularly in larger organizations this can get ugly in a hurry.
My strategy for containing this madness:
1) Keep teams small. Small teams are efficient teams that should not need a lot of (micro) management. And they also don't need a lot of formal roles.
2) No scrum masters. It's a bullshit role that doesn't add a whole lot of value. Especially in smaller teams. Instead I prefer to have tech leads calling the shots on their team or topic and stepping up as a leader. Part of that responsibility is leading the team in a direction that makes sense from a technical and business point of view. And the rest is about coaching people around them. It's something that happens naturally even when you don't want it to. So, I mostly just let this happen and encourage it.
3) Product ownership splits into technical and business ownership. While these can be the same person, it's better to have two equally ranked people shooting for consensus covering both business and tech. That ensures the business and tech is actually aligned. Weed out unrealistic requirements and deadlines; make sure that the technically easy yet valuable work actually gets done; ensure that business value is delivered; ensure that work gets prioritized correctly and that POs don't revert back to waterfall.
4) Management by exception. I like giving people enough room to manage themselves. I step in when that doesn't work. And I use positive re-enforcement to encourage them to do more of the right things. I'm not actually a genius; so I need smart people to tell me what the right way is to do things. Especially when those are things I'm not that good at. People closest to the problems, usually are best positioned to come up with good solutions. So let them. Fix it when that isn't working.
5) Use sprints as a predictable, calendar based umbrella for people to structure their activities around. Short enough cycles that it doesn't turn into waterfall. Long enough that we don't drown in meetings. Day to day management is Kanban based. Just generally remove uncertainty about what needs doing, who is doing it, why we're doing it, what's coming next, etc. Using continuous deployment to release stuff means that guarding quality is a constant and not a once a sprint kind of thing. Sprints are not release deadlines. Using Kanban day to day means that any high priority issues jump to the top of the stack right away. Short feedback cycles are key to keeping quality and morale high.
6) Meetings can be synchronization blocks. Any engineer knows those are bad. Business people seem to never gras...
> But if you’re trying to make a process than can take junior devs (not junior in tenure, but junior in the qualities above) and produce an output that scales almost-kinda linearly with dev count, it sort of works.
I don't think that's even the case. I've been brought onto teams of junior (in the sense that you talk about) developers to help fix broken, late projects. Those projects had always been managed under some sort of agile process, and they still ended up in trouble. I wouldn't even say the process "sort of" worked before then. I dunno, maybe it would have been even more of a disaster without the process, but I still don't think that lends much praise to the process.
I'm lucky that I can pick and choose what sort of projects I work on these days, and I will never work at or for a company where I'd be subject to any kind of agile garbage. Another toplevel commenter farther down mentioned a study that showed that projects managed under the "get to work and let me know when it's done" model outperformed all the others. I've always intuitively believed that model can work (though perhaps not in all situations with all types of developers), and it's nice to see some data to back that up.
In my case, it was a few managers in the org who decided to change over from scrum to kanban.
If there are some teams in your organization or company using kanban, you can use them as an example. If issues brought up in the retrospectives are not being addressed and those issues are related to the scrum process, then that might be a way to get something to change.
You absolutely do. If you are going to critique something, be sure to present what's in your view a better alternative, otherwise what's the point of complaining about a way of doing things other than being negative?
I hope people read this person's full post. he says, "I believe in Agile, but this ain't agile."
Yeah, agile and scrum aren't the same. In my humble opinion, agile process is pretty fantastic and a lot better than waterfall (although waterfall has some elements that should be carried over to agile) or even Rational Unified Process. Yeah, Agile is taking over the engineering world (not just software) for a reason, because iterative development using small teams works.
Read through the principles and then find out how it maps to scrum.
Scrum is not the same as "Agile", but it tries to provide a simple methodology to implement parts of it.
> continuous delivery of valuable software
> Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
That's a sprint in Scrum.
> The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
A stand-up is one way to do it. Standing and talking face to face may seem foreign to people used to sit all day in front of computer screens, but I think it's worth trying... ;-)
I’ve managed teams that have been excellent without scrum. Then there’s one or two teams that just cannot get things done and are all over the place. Had to introduce scrum to get more structure and accountability to getting things done. Once the team started having a good cadence, slowly weaned off scrum.
Tldr; scrum is another tool in your toolbelt you can reach for. Some teams work better with scrum, some dont. Experiment and see which one works - ultimately the goal is the same which is a productive, well oiled machine, regardless of the ‘how’
Different teams get by with different amounts of Scrum Processes.
Less experienced ones need the full-on shit with backlog grooming, planning poker, dailies and retrospectives.
When the team gets better (and there isn't much turnover), you can relax the Processes.
I'm pretty sure I might be the only one on HN who has Scrum actually work in real life. (I've had my share of shitty-Scrum too, like 45 minute "dailies"... =)
Most people don’t know some history. During 1990s, a group of people made a fortune out of consulting gigs where they will be called in by their CTO friends in traditional enterprises to save the late and over budget projects. One of these people was Kent Beck. Kent will use his license to kill to turn things around and eventually generalize his rescue formula and sell it to make 100X more. His crowning glory during those days was XP or eXtreme Programming.
Like with all self-help formulas, Kent will label his solution as magic bullet for all software development problems. He will advertise it as secret medicine that cures all ills. He will be at every conference, write articles after articles, publish books.
Also, like all magic self-help formulas, it wouldn’t quite work. So, Kent will invent something new. His next prescription was TDD and when I first saw it, I thought it was a joke. But people around me started drinking cool aid and if you didn’t join them then you weren’t one of them. Again, Kent and friends will go out on massive marketing spree advertising it as secret talisman. Like all overweight desperate people in need to lose weight, people will enthusiastically start new Kent Beck diet, lose few pounds and endorse the formula. But they will soon find that they had simply traded one problem for another more uglier one.
This went on for long time. For more than two decades, these group of people kept inventing these processes, selling it as magic pill and made millions upon millions in consulting gigs, books, training, certifications and so on. They came up with Agile and 17 people in that group created “agile manifesto”. Their most aggressively marketed prescription was scrum. Like their all previous prescription, world is finally coming off of night of drinking cool aid and feeling severe headache.
I think most of these people have now sort of retired after amassing massive fortunes and hopefully we will not see more of these magic processes pushed to dumb CTOs with promises of curing all ills.
The truth is Scrum was never a magic bullet and it is downright harmful for many projects. It is useful for highly predictable projects where research component is negligible, for example, CRUD websites AND where you are stuck with unmotivated tier-3 talent who failed to get job at insurance company. For everything else, it should never have been used. It is especially going to hurt creativity, originality and novelty if you are in business of making a differentiating unique novel product. It also is very very bad choice if you already had tier-1 highly motivated team.
> Their most aggressively marketed prescription was scrum.
I don't think Agile has prescribed this though. Scrum, in my view, is an intermediary 'solution' so non-technical 'bosses' can overlook and micromanage dev teams. I guess it all stems from 'unproductivity' really, those cases you mention, where you end up with sub-par devs trying to deliver complex software products.
I think even a tier-1 team could make it work for them, but the key is they would make it work for them (make it their own process).
Once you hire a scrum master to tell you how to do your work, you've sort of lost. They are rarely useful other than as sort of "priest" of the process, who ends up becoming another sort of management, but without management powers (usually).
The meetings etc. can be downright useful, in certain cases, but don't really make sense to follow religiously. I.e. if the devs themselves are running the meetings, for themselves, its a useful form of self-management, and you don't need much management skill to run it (any seasoned dev with any sort of communication capability can do it).
But if its imposed upon you, its just a cookie-cutter sort of management, which, doesn't fit all teams or scenarios.
If you already know _exactly_ what your code needs to do, you can "just implement it".
I find TDD to be very helpful in the cases where I do _not_ know everything in advance, because it lets me take small steps to explore things and I get very fast feedback if I "misstepped".
All of the methods mentioned are based on a reasonable core. It muddles the waters and make the snake oil marketing - the "this is the cure to it all" discourse - harder to dismiss. Testing is good. Planning is good. Discussing the project is good. But these things are beside the point of op. The point is, these cargo cults are designed to make consultants money. Now they have a lot of inertia because people grow up on it.
It seems like the new generation of software development silver bullets is "microservice", cloud "devops" etc... Managed kubernetes is not a bad thing. Configuration files, software defined infrastructure, etc, not bad things at all. But there is a definite market push in consulting for overtly complicated frameworks as The Way and people who are anxious about their complicated projects gobble it up.
Second, even XP is not a "magic bullet". Nothing is. It's work that works. (Scrum, on the other hand, is not a "magic bullet" but simply a "bullet". Use it to kill projects very effectively).
Third, at my first real job after uni, we did most of the XP-like practices, and it worked amazingly well. But we didn't know about "XP". Partly because it didn't exist yet, as this was around the same time the Kent Beck started at Chrysler Comprehensive. When the XP books came out it was fun to have a name for what we had been doing so successfully. And also to compare and contrast.
Fourth, I had a great side-by-side natural experiment during my tenure at the BBC. My team did XP-ish things, mostly the technical practices, so test first/TDD, YAGNI etc. Pairing when necessary, but we were co-located around a desk "island" (sort of the way journalist workspaces are organised). My team succeeded far beyond expectations [1]
The team next to us, larger, more important and with way more experienced developers did SCRUM, but not XP. That project had to be rebooted completely after 2 years.
>The truth is Scrum was never a magic bullet and it is downright harmful for many projects. It is useful for highly predictable projects where research component is negligible, for example, CRUD websites AND where you are stuck with unmotivated tier-3 talent who failed to get job at insurance company.
Agile is a cancer too: In many orgs, Agile is essentially synonymous with chaos. Zero look-ahead. Let's do it first and fix it later. Later never comes.
I believe 99% of Agile's value comes from caring about developers and letting them pride themselves with their progress.
Managers benefit from regularly reminding devs that their progress is not measured by amount of code, but working features. "Can you do a demo?"
Care about your devs, let them demonstrate progress. There, I just invented another Agile framework.
485 comments
[ 5.4 ms ] story [ 577 ms ] threadIt might not be the best question to ask given the complexity of the software and experience/culture of the team.
The key part, however, is teams, departments, and companies, then modifying their actual working by eliminating ceremony and process.
The way I think Agile/Scrum/SAFE should work is that you expose all the teams to all the ceremonies, and all the different alternatives to each of the ceremonies to start with, but you also mandate thst 6 months to a year from now you should have reduced 50% of the ceremonies you started with.
The goal should be expose people the universe of options and ideas available, and then once exposed, require them to pick and choose between all these options to tailor their own customized solution which works best with the people on their team and the working styles and the kind of work they’re doing.
Mostly because launching changes so much.
Part of me does feel sometimes that ceremonies are for making sure the development practice is highly inclusive, including for new and less skilled developers still learning their ways. Another part of me thinks about how this also helps more people to be able to generally help with more of the codebase.
I think writing code for your future self or someone else, in a way you'd like to receive is critical to think about. This can include doing things the simpler way even if it's more verbose and more understandable. This isn't always possible, but more often than not, avoidable complexity also can encourage the engagement of a lot of ceremony around it. "Could this have been simpler?" is one useful question for code reviews.
Here is an answer that (I believe) works well: Hire a team lead that is willing to shield a small dev team (less than about 7 people) from the politics above. The devs still talk to users and other people in the company but they do not necessarily have to be accountable to them. The team lead understands the company’s budget cycles, has a vision for the product being developed and, importantly, has the time to sit down with each developer on the team to look at what they are making. Not a code review but a regular show-and-tell kind of arrangement. The fine line in this approach is to make sure it doesn’t degrade to micromanagement and ego poking.
Sometimes a lot can be understood from the team and it's current process in terms of where it did, or didn't come from.
Having a team lead that is technical as a product manager can be very helpful as you are outlining. Being able to speak the language of and maintain the respect of both is so valuable in terms of "getting it".
Clearing the way for devs to learn and do with customers and each other is the other key thing I think about a lot.
Startups likely have less politics (hopefully) but the longer they operate as startups politics likely increase, or hides itself better.
When I see startups leaping to hire VP engineering, etc, I can't help but think of my own experiences where having the founders at those seats translating what is being learned from customers directly into the product was so critical.
For existing or larger organizations, I think what you're saying is very true.
All of these are organic rather than formulaic. They require limited rates of growth to enculturate the new hires, and a seed group that understands this.
That works. But you can't hire a consultant to build that, or write a book about it. And bad elements in the mix can mess up the whole thing.
I heard an interesting explanation the other day, hard skills are easy to measure, and soft skills are hard to measure, but developing soft skills can be are more important than hard skills.
“How Big Tech Runs Tech Projects and the Curious Absence of Scrum”
https://blog.pragmaticengineer.com/project-management-at-big...
My own experience has been similar.
Start with keeping a very flexible core and codebase.. feed it with launched code from a plan that balances bug fixes, progress forward, and customer needs from the business.
This meant having a backlog, and by scoring each item on criticality where 1 was critical and 6 was someday/maybe, and whether it was internal facing, or external facing (customer is aware), you could almost start selecting what was done and ready.
Would love to hear anyone's processes they used that have worked well for them from start to growth.
It identifies if anyone will be stepping on anyone else's toes, or if anyone knows of something similar and can point you to it, and it lets the project manager know if anyone is working on something that can be traded for a higher priority task that just came up.
Most of the time, you work on what you say you're going to work on. Sometimes, the project manager will call you after standup to get more detail and/or adjust your priority to a different task.
This standup is the only formal meeting the developers go to, other than the odd department/company wide meeting. The project manager goes to all of the other meetings.
We are the most productive team in the company. I think the autonomy and the lack of formal meetings are the real magic. We're fully remote and talk to each other plenty throughout the day in an adhoc way, sometimes for fun and sometimes for technical discussions, problem solving, brainstorming, sanity checks (technical and personal), etc.
"I was figuring out how to add a doohickey that widgets foobar" is not a commit, but during the daily someone else might remember that there already is something that can widget foobars. Or they might know that widgeting foobars was tried before and it failed because X and Y.
Then they won't start debugging that during the daily, but will point it out and get in touch afterwards along with others that might care. Either on a $TEXTUAL_MESSAGING_APP thread or $VIDEO_CALL_SERVICE call.
To my experience 10% of software developers think 7 am is morning, 60% something between 9 and 10. 30% not before 11 or 12. The first and the last group tend to be the most productive ones.
Forcing all of them to meet at 10 or even 9 is the best way to kill motivation and foster cynicism about useless meetings and processes.
SAFe is the next buzz word laden cancer to infect the enterprise. It will bring Business Agility(tm) to areas of the business beyond software development.
Consultants love it!
Just because a so-called "Scrum Master" not worth the title is forcing you to do BS things that inhibit your flow does not mean it's emblematic of the species. I mean, how would you feel if someone generalized all developers as a bunch of fat neckbearded social cripples reeking of BO? Same thing here.
I ought to bookmark this post in case anyone thinks that people on HN don't try to farm karma Reddit-style. What a crap bunch of outrage bait.
If only people weren't so ignorant, we could give pure Scrum a try and solve all the world's problems.
They are right, however the conclusion that should be drawn from this is that the most likely outcome of your organisations implementation of agile will be equally as poor, and that it should prolly be skipped.
What did you expect the parent commenter to say? "you've done well and have shown that scrum doesn't work"?
Obviously the people charged with implementing this in OP's company are doing it wrong. That doesn't mean it's OK to insinuate that everyone who ever tries to implement Scrum or Agile is doing it wrong. For every clueless toxic manager who doesn't understand how to use Agile correctly, there's an egotistical or lazy dev who also wants to throw what the Brits would call a spanner in the works for purely personal reasons.
But to call it a No True Scotsman argument is a lazy rebuttal which won't engage with the argument. There are plenty of shitty Agile practitioners, and no one is trying to dispute this.
Anecdata Of One: I have worked at many places since 2005 and the most successful projects have been those without any Agile[1]/Scrum imposed by management. In contrast, the places with the worst outcomes[2] have all had distinct Agile/Scrum imposed by micro-managers[3].
[1] Plenty of places with iterative development but solely due to the nature of the work (changes required by external QA, experiments, etc.), not imposed.
[2] Software quality and speed of development-wise. They're all still alive and limping along despite the horrific nature of their internal systems.
[3] Who have always been there in a place with Agile/Scrum. Only once in a place without. I don't think it's coincidental.
It seems to me that most American software companies use Cargo Cult Scrum. They basically take the terms and maybe read a blog about the processes and just wing it from there.
The only way an Agile/Scrum process works if you bring in a consulting company that's expensive enough to make even the top brass buy into it. You can theoretically try to bring it in from the ground up, but it's really hard to do Agile when the rest of the company is either waterfall or flying by the seat of their pants.
"I disagree with you and here's why!"
"I'm sorry that you're personally offended. See, you disagreed with my pure, sweet, logical opinion, which means you must be personally offended, because no REASONABLE person would disagree with me. And because you're offended, you operate on emotions, as opposed to my high-and-mighty self, who operates on pure, sweet logic. Thus I am right and you're a crybaby, because you dared to disagree with what I consider to be my pure, sweet logic."
Opponents were ridiculed and bullied by proponents for being boring, old, unmodern, not team players, not using best practice or whatever. And way too many programmers were actual believers for grumpy safeguards to be able to keep things in check.
I think a cooperative approach might be better to get rid of agile or it will just be replaced by some other dogmatic cult. Agile is more of a symptom than the root cause.
Interestingly, me consulting solo at an hourly rate doesn’t scale. To solve this, about 5 years ago I started a side business of building an electron app for designing and printing labels. I feel like scaling up allows my customers to pick all 3. The app is immediately available, it works, and it’s inexpensive.
So there’s another way to avoid agile and scrum: solo entrepreneurship.
Good luck!
The process is a performance within a performance, literally getting told NOT to do more work. This is what happens when you have chart-oriented-development (particularly jira's toxic charts).
You might think this is nice to have free time to sit around, but frankly it also drains a lot of the joy out of my work, takes away my sense of autonomy and pride in my work and leads to some resentment.
This is not part of scrum
At a place I worked the management decided that a "story" should always be completed within a sprint. So what did we do? We started using stories instead of tasks and epics instead of stories[0]. And voila, now magically stories complete within a sprint!
[0] Just writing that sentence makes my eye twitch
Practically, it means nothing of course.
- the product owner sets the backlog priority
- team estimates
- team commits to what it can deliver from the backlog
- any misses are analyzed for scope mistakes
Rinse/repeat
There’s no shaming part
Edit: format
Unless a person has no shame, failing a commitment I certainly believe is intrinsically shameful. Some cultures would commit seppuku if you don't deliver on a commitment.
The words, "you failed on your commitments" seems very much like shaming. Thus the move to "forecast" over "commitment"
[1] https://www.scrum.org/resources/commitment-vs-forecast
*edit (addendum): Invoking 'seppuku' might be a bit sensationalist, my apologies. The southerner in me is coming out - saying someone does not live up to their word is a very big deal.
Normally I just fix them within a separate commit.
It was painful. I constantly felt that I should be working, because I was being paid decent money. But there was nothing to do, and no-one wanted me to do anything. I couldn't focus on a side project because I felt so guilty about taking their money and not doing anything.
We adopted Mob Programming. Five senior engineers on one call writing one piece of code. Or rather, one of us teaching the manager some Golang while he spent 4 hours doing a ticket that should have taken 1 hour. No stakeholders present because none of them wanted to waste a day watching us work.
Such a waste of time and talent.
That’s what I hate about these wasted “pockets” of time.. you don’t have work to do, and you can’t focus on doing your side projects either, just a waste.
I read 20+ books on management and leadership[1], and none of them mentioned anything like Scrum. I agree it's BS.
[1] https://tuckerconnelly.com/management-leadership
A good team that runs itself? Ofc it doesn't need Ten Scrum Masters to deliver value.
Now, the real question is why leadership tries to salvage failing teams with Scrum? Save the wasted money, use it to hire top talent instead... easy.
This problem exists at big tech and startup, in companies that spend fractional multipliers of the average salary on engineers as well as those who pay poorly.
In this environment, if your solution is "hire better people', you can't- there isn't any
Big tech or startup status are not correlated with top talent. I've seen the whole spectrum of low to high talent from both places.
> in companies that spend fractional multipliers of the average salary on engineers as well as those who pay poorly
Pay and top skill are only slightly correlated, unfortunately.
> Top talent does not exist.
It does exist. I've seen it, but most managers don't know how to find it, identify it, and retain it.
Also, please at least acknowledge that your numbers are completely made up and may have no basis in reality. It might be a $1000 team only if they deliver on time, but the overages might push that to $5000. Or whatever. See, I can completely make up numbers to support my point too.
You are 100% right that legacy management falls for the SCRUM sales pitch.
At one company I worked at the scrum salesman basically bullied the executive team by saying "You don't want to be the last company to adopt scrum do you?!!??!"
Have you _tried_ hiring good people?
Even better is top talent who can also interface directly with the client when necessary (not necessarily all the time) and doesn't need everything first filtered through a manager.
I've worked with teams like this in the past and it was always a pleasure. Most of them were fairly experienced devs and knew the value of email, phone calls, and water cooler talk (serendipitous discussions which led to valuable information being exchanged). Despite the lack of "modern" productivity tools like text messages, chat apps, and Slack, we were able to get stuff done efficiently.
We had weekly meetings which were productive and useful, and actually helped identify if anything was falling through the cracks. Nobody got bored because the meetings were actually helpful.
So it would have to be both: the devs are good and don't need hand-holding, and the manager is able to deal with the lack of transparency that "it'll be done when it's done" comes with.
Some people just have a very hard time letting go and trusting a team. Who they are managing just needs to follow.
My takeaway then was that Scrum fosters a modular team management style, which diminishes the dependence on highly skilled individuals.
This approach seemed to offer management a sense of oversight in the software development process, but I didn't stay long enough to determine whether this was actual control and predictability or merely an illusion of it.
Agile and Scrum are for managers who don't know what they want, but they'll "know it when they see it". (Or more likely, they'll declare that they wanted is what they've got when the money runs out.)
Just stay away from it, if at all possible.
Yeah, most aspects of Agile (iterative development, MVP...) are fantastic and it has made most types of engineering lighter, more team-focused and well more agile.
> 3. We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.
This continues to be one of the most aggravating parts of capital A Agile software development. Forcing people to be uncomfortable to make them talk less is something a child would come up with.
With my team, we’ve focussed on developing talent just as much as we have on getting the work done. By improving skills through senior-to-junior coaching and code review we’ve built a much more cohesive team that’s better at what they do and can complete tasks which they couldn’t do before. Dexterity and fluency with code was more important to us than organisational skills.
Perhaps I’m missing the point and Scrum is only for people at the top of their game? It didn’t feel that way the few times I’ve seen it — to be a little bitchy, it appeared to be quite the opposite.
You still don't really know when it will be ready, but you now have talking points with management about a) whats been done and b) how complex it is. This builds belief: Belief there will be a solution, and Belief you can find it.
Nothing not said better by others here, but I say this as a party who was dragged kicking and screaming into the process to be an agile product manager, hated it, and got out. I totally "get" why people want this. It's very rare to be a Bell Labs, or Xerox Parc, and have pretty much complete freedom to spend budget and deliver an outcome when it's ready.
I also have worked on large s/w projects which cost $16m to fail to work, and $60m in lawsuits out the other side. I know that the alternative (a massive proscriptive playbook of minute details of functions, UML, flowcharts, you-name-it) exists and works, or not (depending on your point of view).
Really? I think scrum was the wrong name. The process itself, is fine. Talking to your co-workers builds a sense of purpose and direction.
I dislike Scrum quite a bit, but oh gee ain't that a full plate for Scrum apologists to have a point.
Basically we'd ask mgmt "what do you want next?" and they had to fuck off for the next 4 weeks while devs, ux, QA worked with no changes in plans until next demo and release. They were responsible for figuring out "when will everything be done?" etc.
I recently left a startup that said they were "doing Scrum" and it was just daily task tracking and pushing devs to overcommit to each sprint - that's not what I consider Scrum.
Yeah, that's definitely not Scrum like you said. The whole point is that the team promises to deliver features during a sprint and won't overcommit, they might deliver extra if they have extra time.
If your sprints continuously fail to deliver, then you need to decrease the team's velocity.
I used to have the view that Scrum is a useless batch of meetings, that sucks the life and productivity out of the dev process.
Now, after seeing it from an adjacent (but not subjugated under it) perspective, I think it is a life-sucking batch of meetings that are good for one thing: taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them.
Most of us here are not in that category. I’d wager a majority of HN readers can’t help but to seek out understanding of the business, where this piece fits, what it interacts with. For us, specifying everything upfront is useless. Estimating stuff is irritating because we need the flexibility to make smart decisions during dev. Retro meetings are lies because we can’t say “stop with all this and let me work”.
But if you’re trying to make a process than can take junior devs (not junior in tenure, but junior in the qualities above) and produce an output that scales almost-kinda linearly with dev count, it sort of works.
I’d argue that you’re way better off hiring 6 devs that can go from business problem -> technical solution in their head, without all the ceremony, instead of 40 devs who can’t and 6 PMs to wrangle them.
But I can also see how a company ends up there - go through a tough hiring year, or even just make a few poor hiring decisions, and now you have people on the team who need handholding and supervision. That’s what scrum is; it feels like micromanagement because it is. It forces junior-performing devs into a productive state - maybe 5% of what you’d get out of a senior-performing dev without scrum, but it’s something non-negative.
Leave.
That sounds like it's someone's problem, but it doesn't need to be yours.
The problem is that finding those 6 experienced devs is _HARD_. And they're usually very expensive and know their value.
You can easily find 40 mid to low level coders and a half-dozen people who know how to run a scrum team. Maybe even some of the coders know how to do that for extra savings.
Also in the latter way you can easily have a turnover in the team without any major hassles, you can always find mid-tier coders.
But if one of the 6 highly experienced ones leaves, good luck finding a new one quickly.
A shitty car analogy: You can get a more efficient and faster car if it's 100% custom made. But if something breaks you need to manufacture the parts. Or you could make do with a less efficient and slower car, built out of highly standardised off the shelf parts.
Then I had a very personal conversation with hardcore project manager from non-tech side. He told me that, I got the idea of management of all wrong.
Project manager is an operator where the engineers are nothing more than machine. Your standard engineer is not interested or even care about business goals. They are doing a job, they like to be told what is expected from them, they like to be told what deliverable is. Senior engineers can give an estimate of delivery date, but most don't. They are essentially cogs in the machine and managers are expected to birth products from them.
About those experienced devs: In an manufacturing plant there are things that just works and you don't fiddle with them. Or else, they break and you have to get a brand new thing. Most of these senior engineer with business focus are difficult to manage and they have an expiry date on them. You are lucky to get one, but you have to count the days until they leave for better pay. Moreover, you don't want programmers interested in business side as they get passionate about things that don't concern them which is obviously business side things. So, you need engineers to work but not get ideas.
---
He told a bunch of those stories, but it seems these stories are like if you are in the business, you probably know already type things. He really doesn't buy the idea that "software engineers" are special type of engineers, he said, management hasn't change in centuries, people just use different rhetoric that's all.
The high demand, high pay and low general understanding of computer architecture all fuel this race to the bottom and we all pay for it in low quality, overtly complicated and vulnerable software and all ancillary industries that spring around it. Coding "bootcamps", "Cybersecurity", Agile/SCRUM, Wordpress and clones, AWS and clones etc etc.
Yes I think you got to the crux here - managers want to be indispensable and make everyone else "a machine" so he told you a bunch of self-serving bs. I'm sure if you turn this around on him then project manager will not be a machine but more like a wizard or an artist whose needs must be carefully tended =)
> Moreover, you don't want programmers interested in business side as they get passionate about things that don't concern them which is obviously business side things.
Right and who is better to help here than someone who can take business requirements and hand them to the engineers? You know, someone who got people skills!
One may ask, from where does the tech industry come from? From where tech startups come from? Why is there such a thing as the "tech" industry at all? Don't all companies use tech? We don't talk about the "science industry", do we? If you try and find a definition of tech firm that captures what people mean when they say this, you'll conclude they're basically either computer companies or ordinary firms doing ordinary things, who use computers more effectively than normal. And in the latter case what makes a firm a tech firm is basically unarticulated, people know it when they see it but it's not like there's a set of rules to classify, say, Netflix as a tech firm and Disney as not a tech firm.
So what is it that people see? Mostly it's the distinctive culture that appears when you have (ex-)programmers at the very top of the company, as in CEO and/or board level. This causes companies to differ in all sorts of ways, but one way in which tech firms differ, for example, is that in tech firms you don't get terms like "the business" and "IT". You don't get non-technical project managers. The distinction between the two sides simply doesn't exist.
Non-tech firms live in fear of tech firms and startups. It took me a while to notice this, but go to enough conferences, talk to enough people and you'll see it. The average firm is far more scared of Google or Apple encroaching on their space than they are of an established competitor. This is because tech firm culture is more effective than their own. Such firms have a long history of coming from nowhere to utterly dominate entire industries very fast, and they don't know how to respond to it.
The cultural problems can be seen in the stories you were told. Programmers who understand the business are too expensive. They get ideas. They get passionate, and that's a problem. In a tech firm, experienced devs who understand business end up at director level or higher and firms compete to pay them the best. In non tech firms, they are a problem and get pushed out. This is because the business people are scared of such devs because senior developers end up understanding the business better than the business people do. After all, they implemented the business logic so every rule, regulation and detail is in their mind. And they're used to the rigor demands of programming, so tend to say awkward things in meetings like "that won't work" or "that contradicts the other thing you just said". Tech firms don't mind this because that guy's boss is himself a former developer, and is used to such discussions (from e.g. code or design reviews). "Business people" on the other hand aren't used to this at all, yet feel like their value is their business understanding. They need their devs to be bored and uncaring drones because otherwise what's their own value? You don't want to be competing for a promotion against someone whose understanding of the business is better than yours and who can actually execute change projects effectively!
Underlying all this of course is the uncomfortable fact that programming is much harder than most office jobs. Programmers can and will learn programming and then go on to learn the fine details of finance, accounting or shipping without breaking a sweat, but the reverse is generally not true. It was maybe to some extent in the Visual Basic era but the move to web apps put a stop to gifted amateurs cobbling together business apps and nothing really replaced it (maybe Oracle APEX but it's not as widely used).
Not sure it's a great analogy though since software is still basically the design part - the duplication part is trivial.
The key observation is that they successfully made the "design" of software they "mass duplication" part. The cost of designing and creating crappy custom software has never been so low and it continues to fall.
Multiple steps actually.
(And in some cases the alternative to the "sweat shop" is the same amount of hours outside in the fields with fluctuating income based on what happens with the crop that year)
And turnover you will have! =)
Note that you just ballooned the cost probably 3-4x compared to keeping the team small and strong. And that is how we got to this zombiecorn land we see today.
Also consider this - hiring a large team of bozos is a one-way street. You will likely never be able to hire and retain strong talent ever again. While you can always turn to hiring "mid-tier coders" when the product matures.
> Most companies and teams have to go the structured approach with whatever local mediocrity they can hire.
Yes most companies fail
When you hire people straight off school or "mid tier" people, you can help them grow to be better and reap the benefits.
If everyone will just hire the "top tier talent", their prices will inflate and the pool of top tier people will never grow.
or something like that.
The only way to figure it out is to hire the ones that seem good and see who blossoms.
Yes, there are some people who shape up for 6 months and then start slacking, but they're definitely not the norm. You should be able to evaluate a person in that time and see if their personality fits the team and whether they are a net positive for the productivity.
> The problem is that finding those 6 experienced devs is _HARD_. And they're usually very expensive and know their value.
It's harder than finding uncaring juniors, sure.
But if you need 40+6 people, or 6 experienced people, that's nearly 8x salary.
In silicon valley money, you'll need to pay those uncaring juniors about 150K.
I guarantee you that you can very easily find those 6 experienced people in a few weeks if you're offering over $1M/yr to them. In a month you can staff all 6 positions.
If you're saying you want ~8x performance but not interested in paying ~8x salary.. then yes, it's harder to find the people.
I'm pretty sure that short of John Carmack or a legend of that caliber I can't justify paying 1M to _anyone_ to the people making the budget.
Of course you can grab a half dozen superstars if you pay them a million per head, but they'll also leave the second the job stops being 100% interesting.
That's not a sustainable way to build a company or a team.
There was a good video about this but the tl;dw is about this:
In Japan you're supposed to get hired straight out of school and then you'll stay with The Company until you retire.
The same tradition implies that The Company will _never_ fire people.
Japan faced some very hard times. Companies couldn't afford to hire new people because they couldn't fire the older people.
A whole generation never really entered the workforce because they never got the experience. Now they're mostly doing odd jobs and for the same reason never got married and had children.
Oopsie.
That’s not the only cause with all due respect, I have worked with several C-level managers before, they WANT those mid-low level developers/engineers, they are cheaper and easy to find like you said, but most importantly, they can replace them on a whim with another one who will do the same work, with “super” engineers, it isn’t the case, the amount of knowledge and depth one of them has, you will need a whole team to understand what’s going on first and another to carry on the job, and C-levels being egoistic, they don’t like anyone to have any leverage by any means.
> Not everybody knows that, but Scrum was invented to manage a team of dysfunctional COBOL programmers at a bank, not for product-led tech companies, and certainly not for startups.
> If you're mostly hiring juniors, low-skilled, unpassionate, unable to work autonomously without constant handlholding, reactive instead of proactive people, then you'll certainly need some micromanaging SDLC like Scrum.
Story of my life! And I guess it is the case for most competent employees unfortunately.
Scrum was created to help good developers communicate with management. But the problem is that management has all the power and couldn’t give a shit. If the management was qualified to “get it” you probably wouldn’t need it.
So yeah, if you’re using Scrum, you’re probably going to fail: whatever the reason that you’re doing scrum? That’s why you’re gonna fail.
Scrum is a fantastic canary.
Every user story was the same - “As a business owner, I want users to be able to do x”. Defeats the entire purposes of user stories. But they were told they had to write stories. So they did.
We also had our work planned out 6-12 months in advance.
It was top-down waterfall disguised as agile, which would have been acceptable if we didn’t also waste 5+ hours a week in daily standups (aka status reports), sprint planning, retros, story breakdowns, all of which were scheduled at the most inconvenient of times to ensure they interrupted your flow.
I’ve had that “team of six motivated” come together twice organically during my career. But it never seems to last. People move on, the company gets wind of the success and either normalizes it out, or attempts to try and distribute and harvest. If I could figure out the recipe to reliably locate or create that sort of team, I think I’d be very well off.
And here’s Dave Thomas (one of the names under the Agile Manifesto) speaking of the Agile/Scrum Industrial Complex https://youtu.be/a-BOSpxYJ9M?si=pwROU4JU9V64A39O
Maybe in theory that's the point of it, but it practice it also (and mostly) has the opposite effect: it takes all agency away from capable developers and make them impossible to see the big picture, drastically plummeting developer productivity of otherwise very capable developers.
> Most of us here are not in that category. […] For us, […] is useless.
It's not just useless, it's actually harmful.
> But I can also see how a company ends up there - go through a tough hiring year, or even just make a few poor hiring decisions, and now you have people on the team who need handholding and supervision
But most of the time it's not how it happens: it's forced top-down by manager who have no idea of how software development work, and who are genuinely convinced that it is how projects should be run.
They don't realize that it's a workaround for terrible HR that reduces productivity for everyone, because if they did they'd probably think twice (“How is my HR so poor when I'm not trying to cut on costs there? Oh maybe it's not and I should not use scrum”), they just do it because everybody else does.
It is an assured loss for all.
Why not the opossite way? Trust people a bit above what they currently warrant, see who rises to the opportunity, and ease out the rest. This will over time elevate to a decent team.
1. https://igormroz.com/documents/netflix_culture.pdf
That's a very charitable view... I think back over my career and it was always cargo-culting and micromanagement. I give you credit for analyzing and finding a way to make scrum work beneficially.
The thing is - if you have people who don't (want to) understand the relationship between their work and business value, you've fundamentally got a hiring / personnel problem. And I don't see how scrum (or any other methodology) ever solves that. What you've got at that point is to me the difference between "programmers" and "developers / engineers". People who are more enamored with the technology than with actually accomplishing work. The thing is, some of those people are really good so long as they can be pointed in the right direction. But that's a management thing, not really a methodology thing.
It is very easy to hire one bad player, and he takes the team down, and (in most jurisdictions) it is hard to lay them off.
The reason is, no one who knows what it is required, wants to do the hiring.
You always want to be able to sidestep your boss to your boss's boss of you need to. Or talk to end users and customers.
If I'm being onboarded at some project, I expect to be provided that description as early as possible. Compensating for broken communication by enforcing a life-sucking batch of meetings doesn't seem right.
1) As you said, when you have a lot of junior developers (which given developer demographics is a given), you need some structure. Scrum provides that. For better or worse, the structure is helpful to people that are still a bit uncertain about how stuff works. I hate stand-ups as much as any other developer. But as a product focused CTO, I love that it gets the day started and my developers out of bed, awake and cafienated and focused on the job. Scrum's other meetings are a necessary evil. You need a platform to get them aligned with business goals. They don't naturally do this by themselves. Most importantly, a lot of developers kind of expect to this structure at this point. Providing structure to a team is important. Scrum is as good as any other structure. Not ideal with remote teams as meetings get more tricky.
2) Most scrum roles are junior management roles. And as such you get typically not very experienced people filling these roles as part of their entry into the corporate rat race. So, you get corporate politics playing out at the micro level with lots of turf fights about stuff that generally is close to irrelevant. Ranging from the right way to run meetings, the best issue tracker, etc. It's this endless friction that is causing a lot of resentment with more senior developers. Particularly in larger organizations this can get ugly in a hurry.
My strategy for containing this madness:
1) Keep teams small. Small teams are efficient teams that should not need a lot of (micro) management. And they also don't need a lot of formal roles.
2) No scrum masters. It's a bullshit role that doesn't add a whole lot of value. Especially in smaller teams. Instead I prefer to have tech leads calling the shots on their team or topic and stepping up as a leader. Part of that responsibility is leading the team in a direction that makes sense from a technical and business point of view. And the rest is about coaching people around them. It's something that happens naturally even when you don't want it to. So, I mostly just let this happen and encourage it.
3) Product ownership splits into technical and business ownership. While these can be the same person, it's better to have two equally ranked people shooting for consensus covering both business and tech. That ensures the business and tech is actually aligned. Weed out unrealistic requirements and deadlines; make sure that the technically easy yet valuable work actually gets done; ensure that business value is delivered; ensure that work gets prioritized correctly and that POs don't revert back to waterfall.
4) Management by exception. I like giving people enough room to manage themselves. I step in when that doesn't work. And I use positive re-enforcement to encourage them to do more of the right things. I'm not actually a genius; so I need smart people to tell me what the right way is to do things. Especially when those are things I'm not that good at. People closest to the problems, usually are best positioned to come up with good solutions. So let them. Fix it when that isn't working.
5) Use sprints as a predictable, calendar based umbrella for people to structure their activities around. Short enough cycles that it doesn't turn into waterfall. Long enough that we don't drown in meetings. Day to day management is Kanban based. Just generally remove uncertainty about what needs doing, who is doing it, why we're doing it, what's coming next, etc. Using continuous deployment to release stuff means that guarding quality is a constant and not a once a sprint kind of thing. Sprints are not release deadlines. Using Kanban day to day means that any high priority issues jump to the top of the stack right away. Short feedback cycles are key to keeping quality and morale high.
6) Meetings can be synchronization blocks. Any engineer knows those are bad. Business people seem to never gras...
I don't think that's even the case. I've been brought onto teams of junior (in the sense that you talk about) developers to help fix broken, late projects. Those projects had always been managed under some sort of agile process, and they still ended up in trouble. I wouldn't even say the process "sort of" worked before then. I dunno, maybe it would have been even more of a disaster without the process, but I still don't think that lends much praise to the process.
I'm lucky that I can pick and choose what sort of projects I work on these days, and I will never work at or for a company where I'd be subject to any kind of agile garbage. Another toplevel commenter farther down mentioned a study that showed that projects managed under the "get to work and let me know when it's done" model outperformed all the others. I've always intuitively believed that model can work (though perhaps not in all situations with all types of developers), and it's nice to see some data to back that up.
Bad managers would certainly like to do this but this is not what scrum is about
[1] https://en.wikipedia.org/wiki/Kanban_(development)
We would like to try but we can't, as "everyone else here does Scrum so the problem is in you, not in the process".
If there are some teams in your organization or company using kanban, you can use them as an example. If issues brought up in the retrospectives are not being addressed and those issues are related to the scrum process, then that might be a way to get something to change.
You don't have to produce an alternative to critique something. In fact making such a requirement makes problems linger.
Yeah, agile and scrum aren't the same. In my humble opinion, agile process is pretty fantastic and a lot better than waterfall (although waterfall has some elements that should be carried over to agile) or even Rational Unified Process. Yeah, Agile is taking over the engineering world (not just software) for a reason, because iterative development using small teams works.
1) Searched the entire agile manifesto site for "sprints", "stories", "velocity", "stand ups" etc. Zero references.
2) Searched the official scrum guide for the words "agile", "stories", "story points". Zero references. It only defined sprints.
Read through the principles and then find out how it maps to scrum.
Scrum is not the same as "Agile", but it tries to provide a simple methodology to implement parts of it.
> continuous delivery of valuable software
> Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
That's a sprint in Scrum.
> The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
A stand-up is one way to do it. Standing and talking face to face may seem foreign to people used to sit all day in front of computer screens, but I think it's worth trying... ;-)
and so on.
Tldr; scrum is another tool in your toolbelt you can reach for. Some teams work better with scrum, some dont. Experiment and see which one works - ultimately the goal is the same which is a productive, well oiled machine, regardless of the ‘how’
Different teams get by with different amounts of Scrum Processes.
Less experienced ones need the full-on shit with backlog grooming, planning poker, dailies and retrospectives.
When the team gets better (and there isn't much turnover), you can relax the Processes.
I'm pretty sure I might be the only one on HN who has Scrum actually work in real life. (I've had my share of shitty-Scrum too, like 45 minute "dailies"... =)
Like with all self-help formulas, Kent will label his solution as magic bullet for all software development problems. He will advertise it as secret medicine that cures all ills. He will be at every conference, write articles after articles, publish books.
Also, like all magic self-help formulas, it wouldn’t quite work. So, Kent will invent something new. His next prescription was TDD and when I first saw it, I thought it was a joke. But people around me started drinking cool aid and if you didn’t join them then you weren’t one of them. Again, Kent and friends will go out on massive marketing spree advertising it as secret talisman. Like all overweight desperate people in need to lose weight, people will enthusiastically start new Kent Beck diet, lose few pounds and endorse the formula. But they will soon find that they had simply traded one problem for another more uglier one.
This went on for long time. For more than two decades, these group of people kept inventing these processes, selling it as magic pill and made millions upon millions in consulting gigs, books, training, certifications and so on. They came up with Agile and 17 people in that group created “agile manifesto”. Their most aggressively marketed prescription was scrum. Like their all previous prescription, world is finally coming off of night of drinking cool aid and feeling severe headache.
I think most of these people have now sort of retired after amassing massive fortunes and hopefully we will not see more of these magic processes pushed to dumb CTOs with promises of curing all ills.
The truth is Scrum was never a magic bullet and it is downright harmful for many projects. It is useful for highly predictable projects where research component is negligible, for example, CRUD websites AND where you are stuck with unmotivated tier-3 talent who failed to get job at insurance company. For everything else, it should never have been used. It is especially going to hurt creativity, originality and novelty if you are in business of making a differentiating unique novel product. It also is very very bad choice if you already had tier-1 highly motivated team.
So exercise caution!
I don't think Agile has prescribed this though. Scrum, in my view, is an intermediary 'solution' so non-technical 'bosses' can overlook and micromanage dev teams. I guess it all stems from 'unproductivity' really, those cases you mention, where you end up with sub-par devs trying to deliver complex software products.
Once you hire a scrum master to tell you how to do your work, you've sort of lost. They are rarely useful other than as sort of "priest" of the process, who ends up becoming another sort of management, but without management powers (usually).
The meetings etc. can be downright useful, in certain cases, but don't really make sense to follow religiously. I.e. if the devs themselves are running the meetings, for themselves, its a useful form of self-management, and you don't need much management skill to run it (any seasoned dev with any sort of communication capability can do it).
But if its imposed upon you, its just a cookie-cutter sort of management, which, doesn't fit all teams or scenarios.
If you already know _exactly_ what your code needs to do, you can "just implement it".
I find TDD to be very helpful in the cases where I do _not_ know everything in advance, because it lets me take small steps to explore things and I get very fast feedback if I "misstepped".
It seems like the new generation of software development silver bullets is "microservice", cloud "devops" etc... Managed kubernetes is not a bad thing. Configuration files, software defined infrastructure, etc, not bad things at all. But there is a definite market push in consulting for overtly complicated frameworks as The Way and people who are anxious about their complicated projects gobble it up.
First, Scrum is not XP. Huge difference.
Second, even XP is not a "magic bullet". Nothing is. It's work that works. (Scrum, on the other hand, is not a "magic bullet" but simply a "bullet". Use it to kill projects very effectively).
Third, at my first real job after uni, we did most of the XP-like practices, and it worked amazingly well. But we didn't know about "XP". Partly because it didn't exist yet, as this was around the same time the Kent Beck started at Chrysler Comprehensive. When the XP books came out it was fun to have a name for what we had been doing so successfully. And also to compare and contrast.
Fourth, I had a great side-by-side natural experiment during my tenure at the BBC. My team did XP-ish things, mostly the technical practices, so test first/TDD, YAGNI etc. Pairing when necessary, but we were co-located around a desk "island" (sort of the way journalist workspaces are organised). My team succeeded far beyond expectations [1]
The team next to us, larger, more important and with way more experienced developers did SCRUM, but not XP. That project had to be rebooted completely after 2 years.
[1] https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_...
Nailed it.
I believe 99% of Agile's value comes from caring about developers and letting them pride themselves with their progress.
Managers benefit from regularly reminding devs that their progress is not measured by amount of code, but working features. "Can you do a demo?"
Care about your devs, let them demonstrate progress. There, I just invented another Agile framework.