11 ms·
I've worked at both SV and traditional companies, and I feel like this very closely matches my experience. One of the things I worry about is that even at comp
by quicklime 6y ago
I've worked at both SV and traditional companies, and I feel like this very closely matches my experience.
One of the things I worry about is that even at companies that are doing "Agile transformations" and adopting methodologies like Scrum, in practice have "Product Owners" who are there to give instructions via Jira tickets. Other roles like "Business Analysts" are there to ensure that lowly developers never have to worry about things like understanding the business themselves.
So I get funny looks when I suggest that engineers should go talk to people in the business, and write design docs. Silicon Valley engineering practices can look very non-Agile to a lot people from traditional companies that are doing Agile.
- opportune 6y agoYes! The proliferation and role of "business people" in traditional companies is IMO their defining characteristic. It shows how much or how little a business trusts engineers (and also engineer's "status" within the company, e.g. are they respected and valued or treated as a disposable resource) to run the business as general problem solvers. The ironic thing about Agile is that it has a cottage industry of "scrum consultants", "scrum masters", project owners, etc. which advocate ostensibly for letting developers self-organize but which also has a vested interest for career and self-preservation reasons in inserting itself above software engineers in the decision making process.
- courtf 6y agoI've long imagined a position just above the scrum masters: the scrum lord. I see this position as a critical component of any agile strategy that seeks to maximize scrum master productivity, while still allowing scrum masters all the autonomy they need for their day-to-day duties.
- loosetypes 6y agoI appreciate your sense of humor
- klipt 6y agoWhy settle for scrum lord when you could be scrum king? Scrum emperor? One day even scrum Pope?
- courtf 6y ago> scrum Pope his holiness will make his presence known in due time
- tehjoker 6y agoSomehow I suspect that something like this is at work inside the Vatican.
- gnusty_gnurc 6y agoLet's just call them all scrumbags
- optimiz3 6y agoPope Scrootus the 1st
- Roboprog 6y agoGod-Emperor of Scrum. The code must flow.
- courtf 6y agoNow fly my scrumlings! Bring me their estimates! Eeehehehe
- DoofusOfDeath 6y agoMeh. A real Evil Scrum Lord makes his victims enter the data by themselves into Jira.
- bitwize 6y agoTwice. Once in points after Planning Poker has sized the story -- the second time in hours.
- jrott 6y agonot sure you're going far enough there. Obviously we need a scrum king to guide our scrum lords as they help our scrum masters transform our organization.
- chris11 6y agoI definitely agree with you, but I don't think that's sufficient. I think at larger companies it would be helpful to spend a day or two every quarter having a scrum increment meeting. The SI would let scrum lords and scrum masters plan what experiments would occur during the next quarter.
- lakala6790 6y agoWhat you are looking for is RTE; Release Train Engineer
- bigiain 6y agoClick [here] to sign up for my Free Introductory Scrum Lord certification course! Join our hundreds of Certified Scam Lords earning well above industry standard after just 12 months of online training! (Credit card required. Rebilled at $29.95 per month until cancellation. Minimum period of 12 months. T&Cs apple.)
- deleted 6y ago[deleted]
- peteradio 6y agoThe scrum lord spends most his day in his office making spunk charts. The making of spunk charts is an intensely personal task that uniquely suits them for office ownership. There have been cases where two or more scrum lords create spunk charts together but it is more rare.
- cjfd 6y agoStill, at my company I have an even more lofty title. I am the Kanban King...
- kevin_thibedeau 6y agoThese are people whose entire job consists of sitting in meetings and firing off emails. They can't conceive that other people do work collaborating outside of a meeting room.
- Aeolun 6y agoNot just collaborating. Any kind of work. We plan 8 hours a day of work for developers, but they spend 4 hours in meetings, 2 hours fielding questions and just 2 actually working.
- coldcode 6y agoAt my job its more like 10-12 hours a day, since you are counted on to do 6-8 hrs of programming despite all the other stuff.
- dgellow 6y agoTo be fair, I've seen engineers with a similar role.
- anthonypasq 6y agoyep, and thank god. Because I sure as hell dont want to do that as a developer
- pm90 6y agoKeep in mind that Agile (using the term loosely) was invented by software consultants who wanted to maximize the value they provided to the business they worked with. It’s a formalization of the ideas to make them more “acceptable” to execs and the decision makers (who care about such things). When applied to in house engineering teams, it is largely ineffective if it doesn’t come with the same kind of freedom that highly paid software consultants get. This is manifested concretely in how many companies have corrupted agile methodologies by focusing too much on the perfecting practices (or “ceremonies”) rather than focusing on the foundational principles.
- mdtusz 6y agoI'm convinced that the vast majority of business-y manager types that always trumpet "we have to be more agile" have never read the agile manifesto - specifically the "individuals and interactions over process and tools". It's regretful that it caught on so well and has (incorrectly) evolved into a concrete process in most places rather than an ideology.
- drspacemonkey 6y agoI'm convinced of the same thing. I once had a rather enlightening conversation with an Agile consultant who had never read the manifesto. When I showed him, he said "I'm not sure I agree with this".
- walshemj 6y agoThen they don't understand what RAD / SCRUM is for - and I would bet had crappy outcomes before the switch.
- tolbish 6y agoThat would give developers too much power and make them non replaceable/interchangeable.
- consp 6y agoThey already aren't replaceable in that sense. It it impossible to open a can of developers and hope to get results straight away or hope nothing gets lost if someone leaves.
- p_l 6y agoIf you drop your expectations low enough, then yes, it's possible. It involves a steady churn state and the idea that "it's just how it is".
- surfingdino 6y agoSo true.
- celim307 6y agoWe had a large disconnect between product and engineering. The directors solution was to have mandatory 8 hours of sprint ceremonies a week where we would review the definition of “bug” and “epic”, every week. We also were required to sit in on all team meetings regardless if it was your team. We had two full time scrum masters for a team of six engineers. I suggested instead engineers get looped earlier into the process with stakeholders. The director said it was a bad idea as we couldn’t possibly hope to understand the business side of things. Very glad I got out
- deleted 6y ago[deleted]
- danielheath 6y agoIn many companies, the 'product' department exists to protect the owners from the leverage developers would have if they had access to the business context.
- ShamelessC 6y agoThat's interesting... I think. Could you give an example (as contrived as you wish) to illustrate this point?
- irishloop 6y agoMy guess is that if developers understood the business, they would understand how simplistic a lot of the business models are, and how much of the profit is derived directly from their skilled labor and yet how much of the profit goes directly towards someone else, and developers would suddenly realize they have leverage because they are essentially the profit model.
- ta988 6y agoNote that this is the case in most industries, not just software. And that's why the "patrons" "bosses" "chiefs" whatever they are named over time always fought to keep their employees silenced, non-organized... Maybe now is the time to consider cooperatives and getting rid of all or part of the hierarchies (some cooperatives work well with simpler hierarchies). They want disruption, we cut the ties.
- lordnacho 6y agoI think the key is whether you consider an engineer a business person. That is what links most of the things in the article: a business person needs to know certain business things to be effective, and so if you're considered a business person you get told things like what the competive landscape is, what the budget is, and so on. For me, the engineer is actually the only person who can do those business functions properly, if the business is solving new problems (rather than a cash cow). I tolerate people who aren't engineers, because I often can't avoid them, but once you get more than a few of these people in your business, things get awkward for the actual engineers. I also tend to think of engineering as more than just coding. An essential part of it is communicating. You can't do that without technical skills, there's just so much friction.
- ta988 6y agoMaybe (or not, I didn't think that idea fully yet) it is time to start cutting the software development jobs in two jobs: Technicians and engineers. And maybe it is also time for developers to organize take the lead of their craft.
- bigiain 6y ago> traditional companies that are doing Agile. Aka "Wagile". "We have a standup every morning, where you're required to report on how many of your assigned Jira tickets you completed yesterday and get berated for any incomplete ones no matter the cause! No excuses! We've committed to these deadlines and budgets, that you know nothing about having not been consulted on anything."
- LimaBearz 6y agoThat’s just the tip of the ice berg... I call it the tyranny of project managers. When I worked for a large multinational in SF, 100M+ users we operated very much in the “SV” style the article describes. I got to see how our satellite offices in other parts of the world operate; EVERYTHING was in calendar, work was tracked in 15 minute intervals, meeting about meetings, and follow up meetings after the meeting, and a post mortum after. One project manager for every 3 engineers. Dealing with them I felt like I was looking some sort of Project Managers Gone Wild porn set Then I moved away from the BA and found out most places are like this, it’s real bad
- TedDoesntTalk 6y agoHow about “people over process”? Yet we are slaves to Agile Scrum process and procedure. Double talk.
- 29athrowaway 6y agoThe reasons behind the creation of Scrum and the reasons behind the adoption of Scrum are different. Plus, most implementations of Scrum are bullshit. Scrum does not recognize the role of a "project manager". There's the product owner, the scrum master and the development team. That's all. The scrum master only exists to guarantee the process is followed. The scrum master is just a scrum evangelist, not a real leader.
- spaetzleesser 6y agoAnd product owner and scrum master need to be highly skilled people with a lot of responsibility instead of whoever has nothing better to do at the moment as is so often the case. I still can’t figure out how line managers and architects fit into a well run scrum environment. Seems they would be losing a lot of power.
- spfzero 6y agoWhen I was managing engineers, I would insist that the engineer talk 1:1 to the engineer on the client (or customer) side when doing fixes or feature enhancements that happened to be requested from outside the company. This always caused consternation among scrummasters and product managers, and there always had to be a discussion about it. But it sped things up tremendously, because the engineer could do things like say "well, what if we did this other thing instead, which would give you what you need, and also solve another problem we have". In almost all cases the other engineer was happy to talk to our engineer, and very easy to work with. This needed to be a private conversation as well, so that both parties not need to worry about optics. Preferably phone. Once a scrum-master tried to insist that these conversations take place on a public slack channel so that we could "capture" it! And yes I understand why, but it would have skewed the process into something less effective.
- JMTQp8lwXL 6y agoI've been the client engineer before, trying to get through the opaque 'solution support' folks to the actual engineers of the product. No dice. We could never get the problem solved and we ended up ditching the product.
- JMTQp8lwXL 6y agoWhen I eventually got an NPS e-mail from them, I gave them a 1, and explained that I couldn't get through to actual engineers so we gave up, and then a solution engineer followed up and apologized and informed me that if there was anything they could do, to let them know. I never wanted to bang my head against the monitor harder than in that moment.
- Stratoscope 6y agoFor anyone like me who had never seen the term "NPS e-mail", this seems to explain it pretty well: https://www.questionpro.com/blog/nps-email/ https://www.questionpro.com/blog/nps-email/ (I don't know anything about this company and am not endorsing them, just noting it as a reference.)
- bitwize 6y ago> So I get funny looks when I suggest that engineers should go talk to people in the business, and write design docs. I've gotten more than funny looks. They get downright mean or irritated, because to them it sounds like you're trying to take their job away. Remember, these are the people who bring the requirements to the engineers.They have people skills! Can't you understand that? What the hell is wrong with you people?! https://www.youtube.com/watch?v=fcIMIyQnOso https://www.youtube.com/watch?v=fcIMIyQnOso
- Consultant32452 6y agoThis post just made me miss coding so much. I spend basically all my time these days understanding the business. Sometimes I just want to blindly code: create an algorithm to calculate x, make a screen to display y. But those roles don't pay.
- dreamcompiler 6y ago> Silicon Valley engineering practices can look very non-Agile to a lot people from traditional companies that are doing Agile. This is of course because the thing that traditional companies call "Agile" is really just the same business-as-usual top-down manager-controlled garbage software process they've always used but with the cool-sounding name "Agile" slapped on it. Whereas what SV companies do is much closer to what Agile is really about, regardless of what they call it.
- wpietri 6y agoAs a person who was there for the early days of Agile, I just want to say it's sad that's what Agile has become. You're right, of course. But that's not what was meant. Somehow "Individual and interactions over processes and tools" became "individuals, please stop interacting and conform to these processes and tools".
- mclightning 6y agoIt gets worse. If you're caught in a power grab/political game as a developer, some manager consciously use this to slow you down in comparison to their favorite developer. I was a developer brought into a team along with codebase. They would allow their own devs to go full SV-style, free. But when it comes to me; "please check with PO, create a jira subtask for this"
- deleted 6y ago[deleted]
- jstepka 6y agosold my company to atlassian in 2006. i worked at atlassian for nearly a decade. ran bitbucket for years. ran product at docker after that. any notion that engineers should not be on customer calls, or driving engineering specs is the opposite of what i would consider the best implementation of agile.
- baxtr 6y agoI think it also depends a lot on the type of dev and if they want to take responsibility. I have experienced many devs that just didn’t care about the business and design side of things. “Leave me alone and go talk to the product owner”, was something I gotten quite often. But, to be fair I often also got “We want to be more involved in decision making”.
- mclightning 6y agoIf you set up the responsibility, power & accountability right. Then the developer will have to care and take responsibility. Otherwise, their deliverable is wrong, and they're out. As simple as that.
- mmcnl 6y agoExactly, a lot of devs complain about meetings and just want to code.
- austincheney 6y agoRegular practice in other industries don’t need Agile to work fast, be creative, or hold people to account for their work. How is software different in this regard?
- hderms 6y agoI think in a lot of industries the work "speaks for itself" like a creative agency or people producing widgets. For creative work you can walk through the assets produced and everyone can theoretically see that there is value being created. I believe software development gravitates towards heavy processes mostly because it's hard for "decision makers" to accurately gauge good software from bad, or even understand what progress is being made at all. Having more engineers in decision making positions certainly helps, but I think it boils down to whether the organization is set up for trust.
- dgellow 6y ago> "Product Owners" who are there to give instructions via Jira tickets A good product owners facilitates the communication between business people and engineers (or designers, or others). They don't dictate instructions, they regularly spend time with business people to understand their needs and what they care about, work with engineers and designers to craft solutions that are the best suited to what the business needs. When the relationship works well engineers are shielded from constant interruptions, and can rely on one person to answer their business questions instead of trying to have discussions between all the stakeholders. As an engineer I was myself very skeptical of the role in the past but then worked with 2 awesome product owners for a few years and it was a fantastic experience.
- valuearb 6y agoI was a lead developer on an agile team at a $10B+ 50,000 employee pet store chain for 9 months, and never met the product owner. All backlog was generated by having two analysts or their boss meet with the product owner, a direct marketing exec, writing down what she wanted, then meet with team to give marching orders. Being a direct marketing exec, all she cared about was “engagement”, so our product was mainly just feeds of pet advice, tips and tricks along with a game (that the bored analysts played all day). The app also allowed booking store services such as grooming, vet visits, and boarding. But the implementation of the service bookings was so poor it took over a dozen steps with lengthy spinners for network requests. Our metrics showed less than one third of service booking attempts completed. I pointed out that since the company was terrified of Amazon, that store services were a key differentiator and margin producer and we could make booking services far faster and easier with some design changes. The response was, that’s not in our backlog. So next build after completing my work, and helping other devs complete theirs, I worked over a weekend and cached some booking data in the app to eliminate spinners on entry into the booking system. I proudly showed it to the analysts that Monday and they nearly had heart attacks. That wasn’t in the backlog! All they cared about was making the product owner happy (she was a teller, apparently) and all my efforts did was make me unpopular with them and their boss.