[madsohm]

At my previous company we did Scrum with a capital S. We did planning poker, daily stand-ups (where we actually stood up), bi-weekly retrospectives and so on. However, we (the engineers) had also made it clear to management that we needed time slots for technical debt, which of course we got. It was a pleasure to work in a so oiled machinery.

So while we were still chasing features, we also had a say in when to do technical debt and could plan it out in a similar manner to new features.

[barrkel]

How often did features come from engineering, from an insight into what the technology could do?

[cyberdrunk]

For most software it's obvious what the software could do - the technology (web etc.) is mature and easy to understand by product managers. That's why engineering input is not valued - the product owners can generate ideas as well, but their ideas are better because they understand business needs.

[madsohm]

My team probably did 10-12 tickets per sprint and at least one of those were always technical debt related in some way.

[barrkel]

That's great, and probably better than average.

However, my comment wasn't referring to technical debt.

[melvinroest]

At the company I work at, Triply, I also have this experience.

One of the companies I had as a client, Healthy Workers, I had the same experience.

So I wouldn’t say kt is that uncommon in my experience.

Both companies are Dutch. I wonder if it is a culture thing too.

[danjac]

Scrum works when you have the right management and engineering culture and alignment of goals. When you don't it just adds more process and overhead with little gain. Unfortunately many companies think that Scrum will magically fix their culture, rather than fixing their culture first as a prerequisite to Scrum.