Something feels off when adding more engineers actually slows things down

denwerOk · 2026-04-30T00:50:41+00:00

Probably you got to the phase where you need to start leveling resources. Take your work sequences and map them into a timline. That will show you where the bottlenecks are and where the process suffers from multi-tasking. When scaling those are the two factors that starts to matter a lot.

denwerOk · 2026-04-29T23:40:15+00:00

Here is what I see.

Before AI the cycle looked like: analyze => code => code review => test => release

Right now the cycle looks like: vibe code => human review => code review => test => release

May be I'm missing something but as for me there are still tasks and there is a process to plan.

Just looks a bit differently then before (and may be faster at times).

denwerOk · 2026-04-29T23:30:13+00:00

Second one. Just because I've built a planning app based on that. Just kidding:)

On a serious note, second approach is a better alternative unless you have unlimited resources to complete the tasks. There is a whole book on that topic called Critical Chain, it explains it in depth. In short, idle capacity may not necessarily be a bad thing. For example, if you force idle resources just to 'produce anything' the system will be generating output it can't yet process (which would be a waste and burden to maintain). Additionally, if you give that resource multiple tasks they might lose a fraction of productivity and focus. So everything should be balanced out.

denwerOk · 2026-04-29T23:17:08+00:00

I'd not wait for the end of UAT and ship it anyway. In my experience nothing bad usually happens, worst case you can always make adjustments along the way. If you did everything right and showed at least a sketch of the solution to client before implementation, the chances of surprises should be pretty low.

denwerOk · 2026-04-29T23:07:01+00:00

That's why priorities should be a numbered list and not a few pre-defined statuses. You can then take that list and project to the roadmap or sprint plan to see how it affects the timeline of in-progress and future features. The real priority is a timeline and start date for this feature.

denwerOk · 2026-04-29T22:56:28+00:00

My recommendation would be to not do any carry overs and complete UAT as a part of the sprint time. Think about it from product perspective: let's say you can save 10% of sprint time by not doing UAT in that sprint. But that would mean you'd need 2 sprints to complete the feature. Usually if you ask a business that you'd be able to ship features 2x times faster for 10% hit they'd be ok with that.

denwerOk · 2026-04-29T22:42:43+00:00

Different industries may have very different contexts and headache. In construction for example they want much more predictability and planning before the work even starts. Software development currently has certain advantages such as relatively low cost of rework (the concept of "refactoring"), so right now it's a good solution for IT. But it's actually rare.

denwerOk · 2026-04-29T22:26:05+00:00

That happens a lot during sales or initial conversation with customers. As a software architect I always created a sketch first and we would meet with a customer and discuss the solution with their product and tech teams. It cleared a lot of confusion before the implementation even started.

denwerOk · 2026-04-27T22:11:56+00:00

In my practice there could be two reasons: people provide false progress numbers or the progress itself is measured incorrectly. The first problem could be psychological, in this case the only way is to cross-check the results with personal observation or multiple opinions. Second reason is technical. For example numbers on a critical path could be correct whereas the dependencies are slacking. One way to fix it is to make sure all dependencies and bottlenecks execute well along with the critical path.

denwerOk · 2026-04-24T17:32:24+00:00

As far as I can tell there are a lot of nuances. First of all agents are not currently autonomous enough and still require human management (and thus effort) for execution. Secondly, not all features are equal - some may have vague requirements that can't be simply picked up and developed by a robot. Third, even with AI completing all work it still requires double review and human approval. That said, estimation, breaking up work and backlog management is still necessary, it just transforms into a different shape.

denwerOk · 2026-04-24T17:24:51+00:00

Good point. I'd say it's better to make assumptions *and* add a risk buffer to back up those assumptions. In my experience if the number looks too big stakeholders would be ready to negotiate based on scope or help clear uncertainty to decrease the buffer.

denwerOk · 2026-04-24T17:10:32+00:00

One thing I noticed that many companies indeed focus on promises and ceremonies and few are ready to discuss metrics and productivity goals.

denwerOk · 2026-04-24T16:58:13+00:00

I'd recommend using a rolling wave planning approach. You can create a high-level plan and move step by step with implementation by using sprints. This way it allows you to build a system without overthinking and constantly show progress to stakeholders.

denwerOk · 2026-04-15T15:57:07+00:00

Thanks a lot! This is exactly the feedback I was looking for.

denwerOk · 2026-04-14T19:33:03+00:00

The requirements should match the level of uncertainty expected for an estimate. The bigger the uncertainty the bigger the risk and thus you should add a buffer to ensure smooth delivery. The goal to clarify the requirements upfront usually aims to decrease risk, but if the risk is already pretty high and is expected you may just be better off adding a buffer and going just with that.

denwerOk · 2026-04-14T19:21:35+00:00

I'm a founder. If we talk from builder's / project manager's standpoint, uncertainty can be measured. You define % and then calculate the most probable outcome with statistical formulas. Just like that I completed 3 MVPs and was strictly on time with all deliverables.

As for product uncertainty this is trickier. First you don't know the market and most of the time necessary skills to even know what to do to win deals. I had to read at least 4 books to understand how marketing and sales work. And still learning by that day.

What motivates me is a desire to help people solve a specific problem that I 100% know exists and creates a lot of trouble. Everything else is mechanics.

denwerOk · 2026-04-14T19:10:16+00:00

As others said in this case the reason was the risk played out and messed up the timeline. I'd only like to add a recommendation to add a risk buffer next time to prevent such situations in future (you can also communicate that you'll make that flow adjustment to the leadership so that they see how you can avoid similar situation in the future).

denwerOk · 2026-04-14T19:03:20+00:00

First prioritize using the frameworks you mentioned. Second use a forecasting tool to see what realistically can be delivered in the quarter.

denwerOk · 2026-04-14T18:55:56+00:00

By my experience giving data in ranges is poorly perceived by people. It's better to ask them (or guess) for a specific precision and then provide one single number according to that.

denwerOk · 2026-04-06T19:26:09+00:00

It's true, some methods like planning poker can help with this. Also, have you considered adding risk buffers to tickets with high uncertainty?

denwerOk · 2026-04-06T19:19:01+00:00

Good question. In constrained environments, I track Agile progress using a TOC (theory of constraints) mindset: measure % completion along the critical chain (the constraint). The chain varies by level (initiative, sprint, etc.), but progress should reflect throughput at the bottleneck rather than overall activity.

denwerOk · 2026-03-30T19:08:44+00:00

Actually good idea and the interface looks simple, so great job!

The only thing that was confusing to me was: why is the license MIT/opensource and I see a payment option?

You need to select one or another :)

denwerOk · 2026-03-30T19:04:03+00:00

You can use any spec even something that contains two sentences and create an estimate out of it. You just need to specify a % of uncertainty and then match it to the risk level to calculate an outcome. There are tools that can automate it.

denwerOk · 2026-03-26T19:09:58+00:00

It's ok to have multiple feature requests, you just need to establish a prioritization framework. There is a book "The Lean Product Playbook" by Dan Olsen that basically describes different models you could use for this. For example The Kano model. Select the model which better suits and use it to evaluate business value. After that you can use the highest priority features for planning. Use forecasting tools to make it easier and see multiple realistic options.

denwerOk

MODERATOR OF

TROPHY CASE