Hacker News new | ask | show | jobs
by barrkel 2784 days ago
Usually, feature requests go through a product manager who can do analysis, integrate with road map, prioritize against other features, figure out if there's overlap with another feature (maybe one coming up soon) and so it shouldn't actually be implemented, etc.

There may be some communication between product and design to figure out how it should look and feel.

Then it'll go into a sprint most probably, but not the current sprint, because that would change the scope and affect estimates and possible delivery timelines. You'd only change the sprint scope if the team is running out of work to do or there's a major customer request or other panic.

There will be some measure of QA, ideally. Some people fly by the seat of their pants, and rely on fixing things in production if it breaks in production. This is using your customers as QA. Can work if you roll out gradually and are very responsive to any reports of regressions.

All in all, this is unlikely to happen in less than a couple of weeks. The processes are designed for predictable, consistent delivery and to minimize surprise. Shortening the chain will mean less integrated decision making and will increase the amount of surprise and inconsistency in the product and its delivery.

2 comments

The processes are also designed such that people do not feel overstepped and ignored. After all, most things in life are about social status, or more immediately about salary status and job position.

If someone secretly implements an awesome feature, others might be envious as it does not seem deserved if their idea did not receive the same level of scrutiny by the usual processes as other decisions did.

Theoretically, it probably won't cause much chaos at all if programmers are allowed to add small GUI tweaks and the product likely benefits from it.

The degree to which this would work probably depends a lot on the extent to which the programmers have reached Kegan level 5, so practically it probably won't work all that well.

http://i.imgur.com/K4AVFbW.png

It's pretty rare for someone to secretly implement an awesome feature. Usually the way that works is as you hint at: someone who already has high social status in the organization gets a lot of leeway to do his own thing while everyone else is constrained to the usual process.

The envy isn't about the awesome feature: it's about the fact that this developer gets even more attention and positive notice from leadership by means that aren't available to other workers due to social status (rather than merit).

To add to this good answer: in many cases you also don't want to overwhelm the users with frequent, unexpected changes, especially in 'enterprise' software.

This is not so much a problem when you add a new feature like this triple-click which doesn't change existing usage and workflows. But even here you want to add that to your documentation, inform your support staff about it etc.

For changes that affect the look & feel of the product, your users will curse you if you roll out multiple of those per week, even if everything is totally stable and free of bugs.