[PaulKeeble]

In the one place I saw Scrum work really well it wasn't because of scrum we succeeded it was the amazingly talent team that groked their goals and understand how to build software well. The complete lack of an enforcer manager was a huge win, being connected directly into your customers and letting them drive what they needed and balancing it with the engineering, that worked really well. They executed well despite scrum and ultimately used Kanban with on need for the biweekly meetings since they were releasing many times a week.

Scrum was a small part of a package of process, the important bit that made that possible was the engineering processes not the task management ones. The business needed to work out what matter most to it and the developers certainly helped more as their expertise in the subject matter grew but what made it all slick was the automation and engineering. Engineering is where the time goes on a software project and doing that well is what matters. As an industry we focus so much on something that is a few hours of effort a week on planning and tracking and yet the big time goes into the actual work. If you spend a lot of time doing planning and tracking and not producing software you are doing it wrong regardless of whatever process you say you are using. Scrum is not remotely sufficient, it ignores all the important bits.

[jariel]

"being connected directly into your customers and letting them drive what they needed and balancing it with the engineering,"

Lucky you however, letting 'raw' Engineers interface with customers is usually a disaster. Engineers build tech, the company builds products, and they are very, very different things. A lot of pieces in there - support, training, docs, price, risk, leverage, IP, know-how, relationship management, legality, confidentiality.

Experienced Engineers who have a lot of exposure to Product, Sales etc. can do this, there's usually a role there for a highly technical person to support sales.

If it were only a matter of 'the customer saying we need XYZ and Engineers doing that' then great, but it's almost never that.

[PaulKeeble]

You need the right customers. We were really lucky the lady in charge of the business team learnt enough of how the development worked to sit in that middle ground between her team of experts and ours to guide the direction well. I would say she and our engineering principle were what made things work well. If you are working with generic customers out there in the world then its much harder to utilise customer focussed requirements.

[sergeykish]

That's the idea - allow people to take responsibilities, learn, grow, communicate. It takes effort and time. And sometimes right person. But when it works it is a joy. I've seen young developers in what was their first project. It is bad but that moment I felt envy.

So often people complain about specification. Here you craft them as they fit you (as long as they resolve customers need).