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

50243Re: [scrumdevelopment] Refactoring type work in Scrum

Expand Messages
  • Charles Bradley - Scrum Coach CSM PSM I
    Feb 3, 2011

      Let me see if I can address the framework issue, and then we can return to the Dev Items and Scrum.  I don't expect Adam to get on board with this at all because he seems to think that writing a framework is generally better than using a free one that already exists.  Maybe it was my use of the term "framework" that was incorrect, or some other language that bothered him.  I"m not sure.

      Let's say you've got a large webapp, with lots of legacy code.  Much of the webapp was built at one time using JSF.  The dev team has decided that going forward, that using Spring MVC, is a better choice.  They also believe that, eventually, this will improve their velocity significantly, for a variety of reasons.  Some of those reasons are that they think Spring MVC is easier and simpler to use.  Another reason is that it's getting harder and harder to find developers with a lot of JFC knowledge, and the industry seems to be trending more toward Spring MVC and similar frameworks/tools.  (Interestingly, Oracle has picked JSF up off of the floor recently, but I still have serious doubts about it) 

      As such, the Dev Team works incrementally to begin using Spring MVC for all new stories.  Things go great, and their velocity improves.  However, at some point, there is a relatively small portion of the app that is still using JSF.  That portion of the app is still pretty heavily used by users, but there haven't been a lot of feature requests(User Stories) in that area of the app as of late.  The team loves Spring MVC, thinks it is the way they want to go technically, and wants to convert the last part of the app that still uses JSF.  They estimate it will take about 2 developer weeks to do that, including time for testing, regression testing, etc.  They attempt to sell all of this to the PO.  The PO doesn't really understand the differences between JFC and Spring MVC, and thus doesn't feel like she can prioritize the effort against business value added stories.

      Does this help the example or hurt it? 
       
      -------
      Charles Bradley, CSM, PSM I
      Experienced Scrum Coach
      My blog: http://scrumcrazy.wordpress.com/



      From: Ron Jeffries <ronjeffries@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Thu, February 3, 2011 1:33:40 AM
      Subject: Re: [scrumdevelopment] Refactoring type work in Scrum

       

      Hello, Charles. On Wednesday, February 2, 2011, at 8:00:01 PM,
      you wrote:

      >> In the kindest possible way: is there any other approach that could
      >> work? If we didn't include this time, wouldn't we fall behind
      >> immediately and also ship a new crappy system instead of the old
      >> crappy system?

      > Approach 1: Spike Story
      > I think, in some of these situations, you could argue that doing a spike story
      > to get ramped up on the newer framework will help remove risk from estimating
      > backlog items that use the new framework. OTOH, removing large risk and "ramp
      > up time" are not exactly the same thing, so maybe this is not a valid approach.
      > In this situation, you'd estimate the Spike Story separately.

      Yes, though a spike, because its value is also not obvious to the
      PO, usually needs to be small. I took you to be saying that the
      framework was such that it was going to be impacting velocity for a
      long time. If so ... that's how long things are going to take, and
      I'd estimate them.

      If the PO would give me extra time to learn the framework, and you'd
      hope to hell they would at least understand that need, then I would
      still use that time by building the real features we need, since
      that would focus my learning.

      I always build new things by starting with a spike of a half-day or
      less. I would often just bake it into my estimate.

      I do share Adam's concern that the whole framework thing is a bad
      idea, especially since the starting premise here is that it's going
      to take a long time and slow us down. It's not easy to see why we'd
      choose something to slow us down.

      I also share his bias that most frameworks do in fact slow us down,
      unless they are very specialized. I would use a PDF-writing
      framework. I would use OpenGL. I would not use a general application
      focused framework unless it was clear that it would speed me up
      within the first week or two.

      > Approach 2: Dev Item
      > This is where I walk into territory that I'm not terribly comfortable in just
      > yet.

      > Here is one other approach(based on some statements in the Scrum Guide) I've
      > dabbled with in the past when coaching teams. Maybe I was going off the
      > reservation, or maybe I stumbled onto something interesting. Not that this
      > approach is not specifically stated in the Scrum Guide, though I think it is a
      > customization within the Scrum Framework that is also consistent with Scrum
      > principles (again as defined in the guide).

      > In the past, I've dabbled with the concept of what I'll call "Dev Items", but
      > there is probably a better term for it. These "Dev Items" are essentially one
      > or more tasks that the dev team creates in a Sprint Backlog. These items are
      > often not specifically related to what a specific backlog item describes. They
      > are more related to how the team decides to create a potentially shippable
      > product increment from the current Product Backlog items. "...Teams are also
      > self-organizing. No one – not even the ScrumMaster -tells the Team how to turn
      > Product Backlog into increments of shippable functionality..."[Scrum Guide
      > quote] Further, the dev team defines and makes visible, the "definition of
      > done."

      No one can put anything into the Sprint Backlog but the Product
      Owner, as far as I know. No doubt Dan or someone has another theory.

      Note, however, that Scrum can be used to manage anything, including
      cutting the grass at the stadium, so it can certainly be used that
      way. I do not advise Dev Stories, which sound exactly like Technical
      Stories to me, for two important reasons:

      As your question reflects, they are difficult for the PO to
      prioritize;

      All too often, if something is so large that the team wants to
      make it a "Dev Item", what is really going on is that they need to
      up their game in doing things incrementally. This is also one of
      Adam's concerns.

      The team can of course break that work into tasks (if they insist on
      making the mistake of breaking the work into tasks) and whether they
      do so or not, they can choose to do the work by any means necessary,
      such as using the framework.

      That's what I mean about baking the use of the framework into the
      individual stories. If we're going to use the framework on this
      story, and it is going to take another day because we're doing it,
      then that's the estimate.

      > As such , as it relates to the "new framework" scenario I've
      > described, if the dev team feels like they need to use a new
      > framework going forward, they can do so whenever they want to,
      > whether or not the PO is ok with it.

      Yes, and bake it into the estimates of the stories / features /
      Product Backlog items, however this estimation is done.

      > Interesting notes about Approach #2:
      > 1. I coach dev teams that these dev items MUST be made visible in the Sprint
      > Backlog, and MUST be communicated to the PO. The amount of time a team spends
      > on Dev Items should be a collaboration/negotiation between the team and PO, but
      > in the end, the dev team makes the final decision.

      This makes them sound like there are many items that are discernibly
      separate from individual stories. I would prefer not to do that.

      > 2. I coach teams that, because these items are not User Stories, they do not
      > count towards velocity. As such, their velocity might suffer, and that will be
      > made visible and should be discussed openly as well. This includes accounting
      > for velocity assumptions used for Release Planning, Sprint Planning, etc.

      Yes. I personally believe that they can almost always be avoided.
      That said, I completely agree with not counting them as velocity. I
      think that Dan, and Roy, and probably others would count them. We've
      talked about the pros and cons of that. I would not count them.

      > 3. Because all of these decision are made visible, dev teams should be careful
      > to only use this time for things that can be well justified to decision makers
      > and whoever ultimately "funds" the team. If the PO has a direct impact on
      > "funding" the team, then you'd better keep her happy.

      Note that in real Scrum the PO has the sole responsibility for
      getting the best possible product by the date. Dev stories make her
      job much harder, as no one (I mean no one) can properly prioritize
      them against a revenue- or benefit-bearing feature.

      Since as far as I know it is (almost?) always possible to do the
      technical work incrementally, I never recommend Dev Stories as a
      strategy.

      > I don't have this entire thing worked out, and I don't intend to be violating
      > some important tenant of Scrum, either. If anyone feels as if I am, I'd
      > certainly be interested in your thoughts on the subject.

      I believe the main tenet of Scrum that this impacts is that only the
      PO can select things into the Sprint Backlog. While it is true that
      the team can build the software using any technical approach they
      choose (subject to whatever the company enforces, which is probably
      also against a Scrum tenet about self-organization), the necessity
      of doing "Dev Stories" raises a very serious question about the
      team's ability to execute Scrum well.

      Most teams cannot execute Scrum well right out of the box, and in
      fact I would bet that most cannot execute Scrum well by my standards
      at all. So this is not a fatal flaw, since most Scrum teams probably
      get benefit from Scrum.

      "Dev Stories" are, however, almost always evidence that the team
      would benefit from learning more about working incrementally.

      Regards,

      Ron Jeffries
      www.XProgramming.com
      Some things are impossible. And some things people say are
      impossible are impossible because they don't know how to do them.
      -- Ron Loyd

    • Show all 25 messages in this topic