[HN Gopher] Practical ways to increase product velocity
___________________________________________________________________
Practical ways to increase product velocity
Author : zdw
Score : 74 points
Date : 2023-12-08 04:05 UTC (18 hours ago)
(HTM) web link (staysaasy.com)
(TXT) w3m dump (staysaasy.com)
| RamblingCTO wrote:
| > Create a culture that favors begging forgiveness (and reversing
| decisions quickly) rather than asking permission. Invest in
| infrastructure such as progressive / cancellable rollouts.
|
| What a terrible idea. How do you make sure no one breaks the
| product on friday evening? Especially with non-reversible db
| mgirations or other funky things?
| marginalia_nu wrote:
| Create a culture where you don't deploy directly to prod on
| friday?
| intelVISA wrote:
| Create a culture where you bikeshed instead of shipping?
| marcosdumay wrote:
| How do you make sure the gate-keepers don't do exactly that?
|
| Because gate-keepers also fail once in a while. And the same
| things that help deal with their failures can also be applied
| directly to deal with failures from the developers.
|
| It's a robust and very counterintuitive finding that quality
| verification of human processes do not increase the final
| quality. You still need quality control, but people will adjust
| for any universal checking you add to their work.
| datadrivenangel wrote:
| Create a culture where people are good at what they do and
| don't break things on a Friday.
| SkyPuncher wrote:
| It's pretty easy when the people who break stuff also need to
| fix it. Nobody wants to ship on a Friday just for the sake of
| shipping. They just wait until Monday.
| ac50hz wrote:
| Promote a culture of responsibility, and attach responsibility
| to every person, every decision and every action.
| red-iron-pine wrote:
| lol then watch the knives come out, and over the smallest
| thing.
|
| there is a limit
| PH95VuimJjqBqy wrote:
| part of creating such a culture is getting rid of the fuckwits.
|
| "we can't allow them to deploy to the QA environment without
| written approval because what if they deploy to production on a
| friday!?!?".
|
| said no one ever.
| zoogeny wrote:
| I think it partially depends on what you are willing to
| forgive. For example, I am much more willing to forgive
| eagerness compared to carelessness or impatience.
|
| One thing to consider is that moving to a culture of
| "permissiveness" won't stop carelessness. In fact, it helps to
| embed it. People learn that they can offload being careful onto
| the one giving permission.
|
| Over time this leads to a worse situation since you end up
| having a lot of people who feel it is OK for them to be
| careless and you end up with one person (the one who can give
| permission) bearing the entire weight of carefulness for the
| entire org.
| alxmng wrote:
| In my experience a culture of urgency has been the most reliable
| indicator of a mismanaged or toxic workplace.
| rubicon33 wrote:
| And yet, I think all us engineers know that time matters
| immensely for the business. There has to be some balance
| struck, otherwise some engineers will build crystal castles
| that never ship or take months for relatively simple features.
| SkyPuncher wrote:
| Urgency is different that shipping small and often.
|
| Best team I ever worked on consistently shipped at a very
| high pace without needing a false sense of urgency. We worked
| hard upfront to cut scope and ship only features we thought
| were valuable.
| marginalia_nu wrote:
| I think urgency is a management foot gun more than anything
| else.
|
| I've had bosses where everything was always on fire and
| extremely urgent and needed to be done the day before
| yesterday. The result is that you don't take what they're
| saying seriously, and when something actually is extremely
| urgent, you're like "yeah I'll do that next week when I'm
| finished with all the other urgent tasks you've given me"
|
| Beyond that, constant panic mode is also incredibly
| shortsighted and a recipe for crippling technical debt down
| the line.
| rubicon33 wrote:
| Great point!
| financltravsty wrote:
| Does it? Does it really?
|
| Excuse my facetiousness, but I don't think time matters at
| all for businesses. I don't think I've ever been in a spot
| where time really mattered. It's always been about people's
| perception of time mattering. And by people I mean upper
| management.
|
| Realistically, if you axed everyone except counsel from the
| executive team, your business would survive. If you have
| paying customers, they will continue paying for the product,
| regardless of whether X or Y feature that customer research
| (and championed by some goon) says is a !MUST HAVE!
|
| The only time time matters is in startups, where you _will_
| run out of money until you can find a sucker to give you more
| (whether that be VCs or customers!).
| PH95VuimJjqBqy wrote:
| you've never worked for a small to midsized company then.
| financltravsty wrote:
| I have. And never has the urgency been warranted in
| retrospect. It's always been a reflection of the
| anxieties and worries of the CEO/president/whoever is in
| charge, than it has been reality.
|
| It's an unchecked personality disorder at that point; and
| I want no part of it.
| PH95VuimJjqBqy wrote:
| business people need to be able to make decisions and
| they do that based upon timelines.
|
| If you're a small to midsized company these decisions
| have larger effects on the overall health of the company.
|
| I've seen too many instances of technical people abusing
| business ignorance of technical details. Most of _my_
| experience has been business people trying really hard to
| work with the technical groups, but the technical groups
| just don't want to be held to any timelines whatsoever.
|
| You can't have that in the business world. That doesn't
| mean all deadlines are hard, but if there isn't some
| timeline then business decisions may as well be made by
| throwing darts at the wall.
| flappyeagle wrote:
| Time matters for every endeavor because in the end we're
| all dead. Every single thing I've done at a company, time
| mattered. Paying customers churn. Competitors come to
| market with features. Employees get recruited away.
|
| All of this happens as time goes by without you doing
| anything.
| ac50hz wrote:
| That's my experience too.
| koliber wrote:
| I've worked with toxic teams and I've worked with productive
| teams. There can be an overlap, but one does not indicate the
| other. Working with respectful like-minded highly-motivated and
| capable people and building things quickly is the opposite of a
| toxic workplace.
| tikhonj wrote:
| There's a massive difference between "productive" and
| "urgent". I've worked on teams that were constantly in a
| hurry, I've worked on teams that got a lot done, and there's
| been basically no overlap between the two.
| mason55 wrote:
| I think the key, as it is in most cases, is the "why".
| Sometimes there really are urgent deadlines that you really
| need to hit. Imagine you're building an app for the Super
| Bowl - if you miss that date then the entire thing is a
| waste. Other times the deadlines are made up or self-
| inflicted.
|
| Understanding the difference and communicating which is which
| are one of the things that make a good manager/exec. If
| you're constantly telling the team "this feature needs to be
| done yesterday" you'll lose their trust very quickly. If
| you're good about saying "this thing is important and we can
| forget the rest" or "I know we don't do this much but this
| date is really important for <good reason X>" then you really
| build trust with the team.
|
| Most engineers are smart enough to understand when dates are
| bullshit and when they aren't. If you push a lot of bullshit
| dates then you won't get the good effort when you really need
| it. If you don't trust the team to work hard without bullshit
| dates then you should find a new team.
| ac50hz wrote:
| The title would better represent this approach by appending
| "...at any cost."
|
| This isn't a judgement, but clarity of intent can help everyone
| make decisions relevant to the effect that such an approach would
| have on them. Elaborating on risk is usually conveniently
| omitted, because it gets in the way of reality.
| koliber wrote:
| The first thing mentioned in this article can be summed up:
| minimize pauses. He calls it "eliminate dependencies" but it's
| really about finding out where work stops and needs to wait for
| something.
|
| This is so important. It's one of the key tenets of agile (not
| only software agile, but real world agile too) as embodies in the
| TPC (Toyota Production System).
|
| I recently wrote a bit more on this topic if you're interested in
| that aspect of speeding up product velocity, or improving the
| overall efficiency of any system:
| https://koliber.com/articles/the-waits-cause-all-the-pain
| peterbell_nyc wrote:
| Lean software development has a lot to say about this too -
| check out anything on value stream mapping and if you haven't
| already, try "Principles of Product Development Flow". It's dry
| but good.
| koliber wrote:
| You're right. I worded it poorly in my original reply. I
| fixed it.
| mratsim wrote:
| It's not dependencies, it's bottlenecks that you need to fix.
| makerdiety wrote:
| Yeah. Sleeping during a marathon defeats the purpose of a
| marathon. Which is to test your superhuman ability and seeing
| if you can run without resting or stopping.
| candiddevmike wrote:
| Step 1: Get rid of all the generic/prescribed devx tooling you
| bought or cargo culted and create bespoke abstractions specific
| to your needs.
| milesvp wrote:
| This list is missing the most important one in my experience.
|
| Stop trying to do so much.
|
| I was on a team that really got good at pushing back on
| aggressive estimates. You wouldn't believe how much more we got
| done and the things we worked on were of higher value when we
| stopped agreeing to add more to our sprints.
|
| It really helped that we got good at doing retros. Where we
| looked at what we said we'd do vs what got done, and saying,
| well, next time it looks like we can only agree to X% of what we
| think we can do.
|
| Like, I know the phrase "slow is smooth, smooth is fast", it'd
| worked really well for me when doing physical tasks. This was the
| first time I'd experienced it for mental tasks as well.
| flappyeagle wrote:
| The article is talking about throughput not latency. There are
| not dates mentioned.
| milesvp wrote:
| Forgive me. I thought I was being clear that I was talking
| about throughput.
|
| My team, when we started to get better at not overcommitting
| in any given period was able to produce more countable work.
| Not just more story points (inflation is super common) but
| more actual deliverables. It was weird, because we all felt
| like we were working less, we just thought we had to be
| honest about our commitments. But when you looked at the
| trend line at the end of the quarter, there was an increase
| in what we were able to do.
|
| I don't claim to know why this works, but it's such an old
| phenomenon that there are lots of sayings that hint at it. I
| know that when I'm personally not overcommitted I have more
| capacity to focus. When I have fewer things on my plate, I
| context switch less. But I think something else happens as
| well. When you say no to things, it forces others to be more
| deliberate with their asks. They stop asking for low value
| things.
| toss1 wrote:
| Excellent
|
| Seems likely that a big reason for the increase was unseen,
| but cumulatively huge. When everyone is not rushing so
| much, fewer interruptions happen. Each is tiny, but the
| cost of context switching is cumulative and even nonlinear.
| You're benefitting from bending that in the good direction
| - reducing thrashing.
| SketchySeaBeast wrote:
| I'm on a 4 dev team (one of many). 3 of us commit to only
| do what we are pretty sure we can do. One of our team
| commits to way more than they should. Guess which of us is
| always carrying over stories and whose new functionality
| creates new bugs ever sprint? They never can wrap stuff up
| completely, they are like a tar ball of chaos.
| Unfortunately they are supposed to be our tech lead so all
| we can do is shake our head and watch.
| tmshu1 wrote:
| As a solo dev, "slow is smooth, smooth is fast" coupled with
| ruthless focus and prioritization has resulted in the biggest
| increases in my productive output.
|
| None of the OP's tips for increasing product velocity apply to
| my company. The essence of product velocity reveals itself when
| N=1.
|
| Focus on a few things. Don't rush, do them well. Say no to
| everything else.
| moeamaya wrote:
| One tactic that worked really well while I was a coding
| engineering manager is to have engineers in opposite timezones
| that don't mind sharing git branches.
|
| We have a small team of 4 engineers (1 in Seoul, 1 in NYC, 2 in
| Brazil) + myself (CA) and we shipped a brand new product line
| with paying customers for our startup in a few weeks
| (subsequently added more features). I correlate that strongly to
| us having a 24hr engineering cycle and us being willing to pick
| up where others left off.
|
| The small team acting as a startup really resonates with my
| experiences.
| magicalhippo wrote:
| Reminds me of the Carmageddon[1] post-mortem where they noted
| that having management in London and all developers in Sydney
| was perfect as everyone was at work at the same time...
|
| [1]: https://en.wikipedia.org/wiki/Carmageddon
| fifilura wrote:
| Haha I (Europe) once worked with an American company who had
| the development center in India.
|
| My experience with that setup was - quite the opposite to say
| the least.
|
| We did not have direct contact with the Indian team so we had
| to speak to the US team to ask them to do stuff in India. But
| if they had questions... ... ... ...
| simonw wrote:
| This is a great article. I wish it had author attribution though
| - it's credited to Stay SaaSy and this page
| https://staysaasy.com/about.html says "we" a lot, but I much
| prefer to know the author of a piece rather than see it credited
| to a company.
| hackitup7 wrote:
| Hi, I'm the author. This is a personal blog, it says "we"
| because there are two of us that write as a team. Thanks for
| reading!
| 29athrowaway wrote:
| Just measure how time is consumed, ask people about what
| interrupts their work, what risks have to be mitigated and start
| from there.
|
| Measure, prioritize then optimize.
| autonomousErwin wrote:
| What a great practical article! I deeply resonate with the
| incident metrics section and the questions you need to ask
| yourself - I'd add another...how long does it take to get it
| running on your local machine?
|
| If you can nail this it massively reduces the friction to someone
| mentioning a bug has occurred to you reproducing it and then
| deploying a fix. If you need to run 10 micro-services to work out
| why a button isn't registering a click event, that kind of stuff
| is going to sap the energy of your engineering team and trade-off
| isn't worth the effort.
| xyzzy4747 wrote:
| Have small PRs, pick good tech stacks and stick with them for all
| your products (I'd recommend using TypeScript / next.js /
| tailwind.css / node.js), don't overly write automated testing for
| things that don't have revenue yet, and fire anyone who doesn't
| get work done or lacks alignment.
| rurp wrote:
| Lots of good points in this article. One big factor I didn't see
| mentioned is cycle time when developing or debugging. How long
| does it take to run some code to test it or reproduce a bug? This
| is especially relevant these days since a lot of modern
| architecture trends like serverless, k8s, or distributed
| microservices can be much tougher in this area than a more
| traditional monolith.
|
| There are workable approaches but they often take some legwork to
| get working well. Having an easy way for any engineer to quickly
| run and test code, especially when jumping into an area they are
| unfamiliar with, can save an immense amount of time.
| chrisweekly wrote:
| Yeah, I think container-based dev envs (devpods / codespaces
| and the like) are going to make more and more sense for a lot
| of companies, with "tighter feedback loop for interacting with
| prod-like env" as the primary reason.
| sonicanatidae wrote:
| Fire it out of a Cannon.
|
| We've been doing this for maybe the past 3 years and I have to
| say, after the first shot, no complaints!
| tunesmith wrote:
| For those of you who have been on well-functioning teams that use
| stories (like Jira) and PRs, I'm wondering how you incentivize
| small PRs.
|
| Our org traditionally estimates a product-oriented story with
| points, and then had one feature branch, which goes through QA
| and merge, at which point the story closes.
|
| I think this causes all sorts of distorted effects, in that it
| simultaneously causes larger PRs, and also disincentivizes
| responsible coding practices that could grow the PR even more.
|
| As these stories are product-focused, it's hard to break down the
| story into smaller stories, as this involves anticipating the
| tech work before starting, and makes it confusing to product
| folks if the stories start getting less product-focused.
|
| I suspect it would be better to allow multiple PRs per story, or
| to otherwise push back on product? Should stories always be sized
| to accommodate one small PR?
| mason55 wrote:
| > _I suspect it would be better to allow multiple PRs per
| story_
|
| Yes. Stacked PRs are one way to accomplish this. Another would
| to have the dev write smaller tickets for PRs and then PRs are
| attached to tickets from the tech team.
|
| Anything that relies on product understanding how to write a
| ticket that is the right size & scope for the dev team to
| create good PRs is doomed to fail.
| 0xcoffee wrote:
| https://newsletter.pragmaticengineer.com/p/stacked-diffs
| tunesmith wrote:
| Stacked diffs sound like what I sometimes do with PRs, where
| I branch off a previous branch. merging/rebasing from main
| would cascade through. It's a drain on QA though if they feel
| like they have to manually qa each PR, as opposed to testing
| the entire bundle of PRs at once.
| natbennett wrote:
| Depends a lot on the domain. In some domains it's possible to
| slice even product stories super small. This usually takes a
| lot of skill from the person writing the stories. But if you
| can get the typical story size down to "about half a day" it
| handles a lot of this problem.
|
| What I usually do instead is multiple PRs per story & hide work
| behind a feature flag or something until it's ready to show
| people. This doesn't require a fancy feature flag framework or
| anything, just a hardcoded Boolean or code comments.
| dml2135 wrote:
| For my own team we do a few things:
|
| - Have engineers write most of the stories, as they are better
| at slicing things down to PR size.
|
| - When product writes the stories, make sure we align on
| engineering approach as part of the pointing process. If
| something should definitely take multiple PRs, we call it out
| then.
|
| - Heavily use feature-flags so that it's easy to have more than
| one PR for a story, as deployment to prod and release of a
| feature are decoupled
|
| - Have a culture where it's totally cool to ask someone to
| break up a large PR into smaller parts.
| jsdalton wrote:
| My advice to you (at least what's worked for me on several
| reasonably well-functioning teams using stories and Jira in a
| similar manner as you have described:
|
| Decouple users stories (customer/product outcomes) from tasks
| (units of work needed to achieve those outcomes). Jira is
| designed pretty well for this, since you can have sub tasks
| attached to user stories.
|
| This works better when your user stories _are_ actually
| defining outcomes -- for example when you have stories like
| "User admins can filter jobs by category" and not "Build a
| category filter for the job search." The first can usually be
| successfully defined by a few acceptance criteria, whereas the
| second starts to get weird since you're focus is more on what
| it will take to build the thing vs. what is the result you want
| your customer to see.
|
| With your outcome defined in the story you can define any
| number of implementation tasks it will take to achieve it. If
| you're a cross-functional team and you do "vertical" instead of
| "horizontal" splitting then you're sure to have a few coding
| tasks on the front end ("add the filter component to the search
| bar", "update the backend client to pass the category id as a
| query parameter") as well as a few on the backend ("update the
| API to accept the category parameter", "add the category param
| to the repository query service"). You probably have some non
| technical tasks too ("update the help documentation", "update
| the OpenAPI spec").
|
| We almost never (save for absolutely trivial user stories) have
| a PR attached to the story but instead have PRs attached to sub
| tasks. If you're doing trunk based development with continuous
| deployment and feature flags, you can and should be shipping
| many PRs. Just yesterday I was in the middle of a task at the
| end of the day and decided to cut the PR where I was and split
| the task in two on the fly, since it was easier for me to ship
| the code like that and easier for my team to review it.
|
| We do story grooming and estimation and all that -- but only
| for user stories. Tasks are the domain of the humans doing the
| work and they are meant to be flexible and even disposable. We
| usually have a session at the start of work on the user story
| when the engineers working on it align on the solution and then
| break the work down in to sub tasks, but these naturally evolve
| as the work progresses. I should had that multiple tasks invite
| collaboration instead of one story per engineer.
|
| Lastly, I've found you have to preach the virtues of small PRs
| to your team and usually convert a few stragglers who don't see
| the value. I try to practice what I preach (i.e. by keeping my
| own PRs small) and also make a big deal out of it in
| retrospectives -- i.e. point out how painful the review process
| is with large PRs, usually entailing many rounds of comments
| and changes -- so that people quickly become believers if they
| are not already.
|
| As a last point I try to encourage the value of "PR reviews are
| your top priority at any given moment" since every second a
| piece of code sits unreviewed adds to your team's cost of
| delay. There's a virtuous cycle here where smaller PRs lead to
| less painful code reviews lead to greater willingness to spend
| 10 minutes (vs. an hour) doing a code review, which helps
| really get PRs moving through.
|
| I think PR stacking is great but I also find it's not as
| important if your PRs are getting reviewed and approved faster
| than you can write the code for your next PR.
|
| (I didn't realize I'd write so much here, I forget that it's
| actually kind of a big topic that's built on a variety of
| different practices that all start coming together at some
| point when you get in a groove.)
| chucke wrote:
| Skip tests.
|
| Thank you for coming to my Ted talk.
| pavel_lishin wrote:
| I'm pretty sure you're just joking, but in reality, this would
| probably increase velocity by a bit at start, only to grind
| down to a negative value within a year.
___________________________________________________________________
(page generated 2023-12-08 23:01 UTC)