6 ms·

Practical ways to increase product velocity

93 points by zdw 3y ago

RamblingCTO 3y ago
> 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 3y ago
  Create a culture where you don't deploy directly to prod on friday?
- intelVISA 3y ago
  Create a culture where you bikeshed instead of shipping?
- marcosdumay 3y ago
  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 3y ago
  Create a culture where people are good at what they do and don't break things on a Friday.
- SkyPuncher 3y ago
  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 3y ago
  Promote a culture of responsibility, and attach responsibility to every person, every decision and every action.
  - red-iron-pine 3y ago
    lol then watch the knives come out, and over the smallest thing. there is a limit
    - ac50hz 3y ago
      ;-) Yeah, I do get that, but when there's no promotion of personal responsibility, chaos reigns. When everyone does wat they want to do, or what they think is necessary, nothing is completed. This is from experience with different companies, organizations, teams, projects, people. Of course, nothing is perfect, but without some structure, there is only communication mayhem ;-(
- PH95VuimJjqBqy 3y ago
  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.
  - RamblingCTO 3y ago
    I'd love that. And I'd love employees who take ownership and have a vision of more than a meter. Truth is, as a startup that nobody knows (stealth mode) in a tough financial market you're not attractive in Germany (and it's ridiculously competitive already). I hope it get's better with more public visibility.
- zoogeny 3y ago
  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.
  - RamblingCTO 3y ago
    Point taken! I have yet to find a path to distributed ownership in my team, but I lack the right resources imho. Can't go into detail, but we have special issues that are probably not widely shared in other startups.
alxmng 3y ago
In my experience a culture of urgency has been the most reliable indicator of a mismanaged or toxic workplace.
- rubicon33 3y ago
  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 3y ago
    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 3y ago
      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.
      - makerdiety 3y ago
        Yeah, we can use that World War Two general's (Patton?) important-urgent matrix. Any object (a task to get done eventually) gets assigned a vector of two components: important and urgent. Things that are both important and urgent will be in one corner of the geometric graph visual thingy. Things that are the complete opposite type of that both important and urgent object type are in the opposite corner, which is the corner of the not important and not urgent. The other two corners (important but not urgent and urgent but not important) beget the need for a measuring system, to make the whole model useful. Maybe encase the vectors in a Gaussian distribution where each object's vector's components are scaled, measuring, representative, or simply numerical values? Like, for example, for a new task to do, add a new object whose vector is 0.5 important and 0.1 urgent. I don't know what mathematics and analyses this setup will imply. So any mathematician or numbers nerd is invited to help further develop this abstraction.
ac50hz 3y ago
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 3y ago
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 https://koliber.com/articles/the-waits-cause-all-the-pain
- peterbell_nyc 3y ago
  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 3y ago
    You’re right. I worded it poorly in my original reply. I fixed it.
- mratsim 3y ago
  It's not dependencies, it's bottlenecks that you need to fix.
- makerdiety 3y ago
  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.
  - koliber 3y ago
    It used to be common wisdom that for hyper marathons you needed to sleep. People thought that you can not run a few days non stop. And then Cliff Young proved that theory wrong. And now they run non-stop, at least for the Sydney to Melbourne Ultramarathon.
candiddevmike 3y ago
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 3y ago
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 3y ago
  The article is talking about throughput not latency. There are not dates mentioned.
  - milesvp 3y ago
    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 3y ago
      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.
moeamaya 3y ago
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 3y ago
  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 https://en.wikipedia.org/wiki/Carmageddon
- fifilura 3y ago
  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 3y ago
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 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 3y ago
  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 3y ago
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 3y ago
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 3y ago
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 3y ago
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 3y ago
  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 3y ago
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 3y ago
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 3y ago
  > 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 3y ago
  https://newsletter.pragmaticengineer.com/p/stacked-diffs https://newsletter.pragmaticengineer.com/p/stacked-diffs
  - tunesmith 3y ago
    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 3y ago
  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.
chucke 3y ago
Skip tests. Thank you for coming to my Ted talk.
- pavel_lishin 3y ago
  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.
ath3nd 3y ago
My top X whatever ways to increase product velocity: - Stop wasting time estimating Planning poker is like kindergarten, there is a parent figure asking the children how many candies are needed to build a tree house... and nobody does anything useful with these "velocity points". Things will be done when will be done. Business types nosing around and trying to pressure the devs into providing an estimate they that's more to their liking is more disruptive than helpful. Guess what? Things will still be done when they are done. Just throw the estimates out of the way. - Throw standups out of the way Or at least throw the non-technical people out of the standups. Nobody benefits from those but micromanager types or useless middle manager personas like Product Owner and Product Managers. - You know what, just drop all the scrum nonsense It's busywork for no gain. It's loved only by people who can't contribute to actually building anything, so they need something to do to justify their salary. Drop this nonsense out and see delivery speeding up. Treat your developers like grown ups who can achieve their goals without a fresh faced college BA graduate who happened to have done the 1 week of Scrum training. - Tests are important Don't go all cult-y on TDD or whatever. If you add a new feature, at least its happy path has to be tested, preferably with as little mocking as possible. Spawn that database, spawn that redis or whatever, make that http request. It will make future changes much easier. - Limit concurrent work in progress. In a team of five or six, don't allow more than 2 big tasks at the same time Give your guys the ability to team up on tasks and do them well until they are satisfied. People teaming up and doing common tasks is invaluable in creating a shared context, reducing the bus factor, and building inter-team-relationships. If some sleazy management types are sniffing around like vultures trying to pressure your team into taking on more work in parallel, show them the door, and if they keep insisting, give them the boot. - Invest in good monitoring You gotta know who uses your shit, how they are using it, and what kind of volume. Every usage feature gotta have a counter and some extra tagging for context. Every rest call needs to have counter, latency, and extra tags. Have a dashboard per app, preferably maintain the dashboard/monitors with some infra as code like terraform. If management insists that there has to be a PO or a PM, give them access to these charts, and show them the door for everything else. - Don't over rely on clients feedback, especially if you think you know better. If you have feedback buttons and you are getting some suggestions or whatever, don't over-rely on them indiscriminately. Most humans are dumb, and half of them are dumber than that, and their feedback can often be senseless. Have Have a damn vision for the product you are building, and the spine to stick to your vision. Politely disregard any features suggestions that you don't think are fitting to the overall product vision. By that, I mean the devs make the decision together, not some PO.

93 points by zdw 3y ago

> 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 3y ago
Create a culture where you don't deploy directly to prod on friday?
intelVISA 3y ago
Create a culture where you bikeshed instead of shipping?
marcosdumay 3y ago
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 3y ago
Create a culture where people are good at what they do and don't break things on a Friday.
SkyPuncher 3y ago
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 3y ago
Promote a culture of responsibility, and attach responsibility to every person, every decision and every action.
- red-iron-pine 3y ago
  lol then watch the knives come out, and over the smallest thing. there is a limit
  - ac50hz 3y ago
    ;-) Yeah, I do get that, but when there's no promotion of personal responsibility, chaos reigns. When everyone does wat they want to do, or what they think is necessary, nothing is completed. This is from experience with different companies, organizations, teams, projects, people. Of course, nothing is perfect, but without some structure, there is only communication mayhem ;-(
PH95VuimJjqBqy 3y ago
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.
- RamblingCTO 3y ago
  I'd love that. And I'd love employees who take ownership and have a vision of more than a meter. Truth is, as a startup that nobody knows (stealth mode) in a tough financial market you're not attractive in Germany (and it's ridiculously competitive already). I hope it get's better with more public visibility.
zoogeny 3y ago
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.
- RamblingCTO 3y ago
  Point taken! I have yet to find a path to distributed ownership in my team, but I lack the right resources imho. Can't go into detail, but we have special issues that are probably not widely shared in other startups.

alxmng 3y ago

In my experience a culture of urgency has been the most reliable indicator of a mismanaged or toxic workplace.

rubicon33 3y ago
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 3y ago
  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 3y ago
    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.
    - makerdiety 3y ago
      Yeah, we can use that World War Two general's (Patton?) important-urgent matrix. Any object (a task to get done eventually) gets assigned a vector of two components: important and urgent. Things that are both important and urgent will be in one corner of the geometric graph visual thingy. Things that are the complete opposite type of that both important and urgent object type are in the opposite corner, which is the corner of the not important and not urgent. The other two corners (important but not urgent and urgent but not important) beget the need for a measuring system, to make the whole model useful. Maybe encase the vectors in a Gaussian distribution where each object's vector's components are scaled, measuring, representative, or simply numerical values? Like, for example, for a new task to do, add a new object whose vector is 0.5 important and 0.1 urgent. I don't know what mathematics and analyses this setup will imply. So any mathematician or numbers nerd is invited to help further develop this abstraction.

ac50hz 3y ago

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 3y ago

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 https://koliber.com/articles/the-waits-cause-all-the-pain

peterbell_nyc 3y ago
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 3y ago
  You’re right. I worded it poorly in my original reply. I fixed it.
mratsim 3y ago
It's not dependencies, it's bottlenecks that you need to fix.
makerdiety 3y ago
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.
- koliber 3y ago
  It used to be common wisdom that for hyper marathons you needed to sleep. People thought that you can not run a few days non stop. And then Cliff Young proved that theory wrong. And now they run non-stop, at least for the Sydney to Melbourne Ultramarathon.

candiddevmike 3y ago

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 3y ago

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 3y ago
The article is talking about throughput not latency. There are not dates mentioned.
- milesvp 3y ago
  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 3y ago
    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.

moeamaya 3y ago

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 3y ago
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 https://en.wikipedia.org/wiki/Carmageddon
fifilura 3y ago
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 3y ago

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 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 3y ago
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 3y ago

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 3y ago

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 3y ago

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 3y ago

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 3y ago
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 3y ago

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 3y ago

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 3y ago
> 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 3y ago
https://newsletter.pragmaticengineer.com/p/stacked-diffs https://newsletter.pragmaticengineer.com/p/stacked-diffs
- tunesmith 3y ago
  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 3y ago
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.

chucke 3y ago

Skip tests. Thank you for coming to my Ted talk.

pavel_lishin 3y ago
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.

ath3nd 3y ago

My top X whatever ways to increase product velocity: - Stop wasting time estimating Planning poker is like kindergarten, there is a parent figure asking the children how many candies are needed to build a tree house... and nobody does anything useful with these "velocity points". Things will be done when will be done. Business types nosing around and trying to pressure the devs into providing an estimate they that's more to their liking is more disruptive than helpful. Guess what? Things will still be done when they are done. Just throw the estimates out of the way. - Throw standups out of the way Or at least throw the non-technical people out of the standups. Nobody benefits from those but micromanager types or useless middle manager personas like Product Owner and Product Managers. - You know what, just drop all the scrum nonsense It's busywork for no gain. It's loved only by people who can't contribute to actually building anything, so they need something to do to justify their salary. Drop this nonsense out and see delivery speeding up. Treat your developers like grown ups who can achieve their goals without a fresh faced college BA graduate who happened to have done the 1 week of Scrum training. - Tests are important Don't go all cult-y on TDD or whatever. If you add a new feature, at least its happy path has to be tested, preferably with as little mocking as possible. Spawn that database, spawn that redis or whatever, make that http request. It will make future changes much easier. - Limit concurrent work in progress. In a team of five or six, don't allow more than 2 big tasks at the same time Give your guys the ability to team up on tasks and do them well until they are satisfied. People teaming up and doing common tasks is invaluable in creating a shared context, reducing the bus factor, and building inter-team-relationships. If some sleazy management types are sniffing around like vultures trying to pressure your team into taking on more work in parallel, show them the door, and if they keep insisting, give them the boot. - Invest in good monitoring You gotta know who uses your shit, how they are using it, and what kind of volume. Every usage feature gotta have a counter and some extra tagging for context. Every rest call needs to have counter, latency, and extra tags. Have a dashboard per app, preferably maintain the dashboard/monitors with some infra as code like terraform. If management insists that there has to be a PO or a PM, give them access to these charts, and show them the door for everything else. - Don't over rely on clients feedback, especially if you think you know better. If you have feedback buttons and you are getting some suggestions or whatever, don't over-rely on them indiscriminately. Most humans are dumb, and half of them are dumber than that, and their feedback can often be senseless. Have Have a damn vision for the product you are building, and the spine to stick to your vision. Politely disregard any features suggestions that you don't think are fitting to the overall product vision. By that, I mean the devs make the decision together, not some PO.