|
|
|
|
|
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. |
|
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