Loading ...
Sorry, an error occurred while loading the content.

"Developer owns a feature" versus Scrum. More cases needed.

Expand Messages
  • JulienM
    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
    Message 1 of 4 , Dec 30, 2011
    • 0 Attachment
      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!

      Thanks,
      Julien.
    • avinap77
      Hi Julian. I sympathize with your situation, I ve seen it too. Being scared is one of the biggest impediments to any change, not only in software development.
      Message 2 of 4 , Dec 31, 2011
      • 0 Attachment
        Hi Julian.

        I sympathize with your situation, I've seen it too.

        Being scared is one of the biggest impediments to any change, not only in software development.
        From what I read, in your case management is scared of failing and the team is scared of management..?
        Making a change into scrum will require some courage and faith from both parties, and willingness to fail for the sake of learning.

        In this case I doubt if more cases will convince anybody. The faith will have to be built incrementally out of small successes.

        You did't mention what your role is in the organization or what power you do or don't have to make changes, but if you can - I would suggest abandoning the current so-called-"scrum" and instead take say 2-3 developers and work with them as a real team. Focus your efforts on running scrum with only them. Management might be willing to try this small change, you can call it an experiment or just call it having one developer helping another. If their features are somewhat related this could be accepted without too much resistance. See how this works for several sprints and then re-asses if you want to spread this to the rest of the developers or just continue with that small team. Use the sprint review meetings to show off to management the successes of this team, and maybe they will be more willing to take it a step further.

        Have patience and savor your own small successes.

        HTH,
        Avi






        --- In scrumdevelopment@yahoogroups.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!
        >
        > Thanks,
        > Julien.
        >
      • JackM
        I 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
        Message 3 of 4 , Jan 3, 2012
        • 0 Attachment
          I 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
          jack
          www.agilebuddy.com

          --- In scrumdevelopment@yahoogroups.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!
          >
          > Thanks,
          > Julien.
          >
        • JulienM
          Thanks for your comment guys. It is absolutely a fear problem and the illusion that divide-and- conquer by user stories(mainly because the code is very large
          Message 4 of 4 , Jan 7, 2012
          • 0 Attachment
            Thanks for your comment guys.
            It is absolutely a fear problem and the illusion that divide-and- conquer by user stories(mainly because the code is very large and knowledge very fragmented) being the more efficient.

            I started to coach them. And indeed I found a team that is much more suitable for a real adoption. Remove fear by example. That is the best way.

            Thanks,
            Julien.
          Your message has been successfully submitted and would be delivered to recipients shortly.