53889Re: "Developer owns a feature" versus Scrum. More cases needed.
- Jan 3, 2012I think you said it all already. Bottom line is this is not an effective way to work. It creates silos of knowledge which in the end will simply throttle the organizations ability to get work done. Additionally if you work this way, you're not really working in priority sequence. i.e. swarm the highest priority feature, get it done and move on to the next. Yes i have seen companies work this way and it's not good.
Hope this helps
--- In email@example.com, "JulienM" <julien@...> wrote:
> Hi all,
> A company I know has 5 teams working on the same product. A large product of millions LLOC (first ``L`` is to emphasize Legacy-LOC).
> They have about 20 large features to develop for next yearly - release. The features are very different and require many different and specific component and domain knowledge. Before they used Scrum, they had one developer(sometimes 2) being responsible for the success of each feature.
> He would even lead the effort to create the details of the feature.
> Given the specific domain and component knowledge required and the large code base, it was believed to be the most effective way to do things.
> Now, they have started to use Scrum.
> Now, these features are broken into user stories and prioritized.
> However, since the ``developer owns a feature`` system has not been officially abolished, the developers still want to work only on the stories of ``their`` features and they make sure at least one story related to their feature gets selected in a sprint and . the PO agrees to this.
> The underlying causes of keeping this ``developer owns a feature`` system is fear of missing the release date (working on the same feature being less efficient for a while) and also it is not an organization used to have teams as a whole (and not individuals) being responsible (see accountable) of delivery.
> Since developers know in advance what they will be working in the sprint, the sprint planning is very quick and does not lead to many discussion. The retrospective are related more to how to do Scrum better (more effective daily scrums ) than to how to improve how they make software .
> Also, there is tremendous work in progress during the sprint since all the stories start simultaneously .
> In brief, I think these teams are not teams and cannot become teams and Scrum can not work well unless they change this ``developer owns feature`` concept. It just totally goes against Scrum.
> It is obvious to me.
> The solution is obvious to me: abolish that ``developer owns a feature`` system and replace it by ``team owns a feature``, prioritize the product backlog in a more meaningful way, reduce the number of features worked on in a sprint to the least possible (1 or 2 features at a time). Pair much more. Do everything to reduce WIP inside a Sprint. It will be less efficient in the short term (people will have to learn about features and components they are less familiar with) but necessary to have real team work and improvement. So of course it will probably require changing the release planning and expectations which is the root of all the rest.
> They know they will have benefits from really using Scrum but they are way too scared of being slowed down for a while to let people work on stories from the same big feature. Is not it a big smell?
> Has any of you seen that ``developer owns a feature`` situation in the past? How severe was it?
> If yes, please share your stories. I would like to accumulate as many stories similar to this as possible. Just to make some cases and share similarities.
> By faith, I know they should just stop loose time and do it and see by themselves. However, this forum is full of people who have seen many Scrum situations and since faith does not always with everybody well your feedback and sharings are welcome!
- << Previous post in topic Next post in topic >>