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

Re: [scrumdevelopment] Re: Multi-functional teams and single sprint goals

Expand Messages
  • Michael Jones
    Hi Wouter, Ben, Interesting, thank you. I can definitely see the benefit of the team working on a common goal. I think it can go too far though, and having a
    Message 1 of 6 , Dec 23, 2011
    • 0 Attachment
      Hi Wouter, Ben,

      Interesting, thank you.

      I can definitely see the benefit of the team working on a common goal.

      I think it can go too far though, and having a single sprint goal can be a straitjacket.

      Perhaps it's that our features are too small to be a sole sprint goal for a 2 week sprint involving 7 developers.

      For instance embedded video might take 2 person days of DTD/XSLT work, 3 days of frontend work, and no Java work. Yet it might be the most important item in the backlog and therefore worthy of being a sprint goal.

      Perhaps it makes sense to have a succession of sprint goals, layered within the sprint - so the first 2 days in the above example would be devoted to video (assuming 2 XSLT and 2 frontend developers), but perhaps the Java developers would be picking up the 2nd feature of the sprint. The XSLT and frontend developers would only move on once they had completed the video work to Done. Then they would join the Java developers on the 2nd feature.

      I appreciate within the sprint timebox the team self-organises to deliver the work, so perhaps this isn't a question I need to answer! I guess I'm just trying to understand logically what approach might work well.

      Thanks for any thoughts,

      On Thu, Dec 22, 2011 at 2:25 PM, bendaygupta <benday@...> wrote:

      I think that Wouter's idea of using pair programming to cross-train the team is a great idea.  It scales nicely, too.  If you take a velocity hit in a sprint and cross-train your devs then you'll be able to spread the work around in subsequent sprints.  If you *don't* ever cross-train your devs, you'll carry that skills bottleneck with you for the entire project.   

      Crafting a clear sprint goal takes some work.  I like to keep the sprint goal as simple as possible.  Ideally, there's just one big thing ('epic') and all the PBIs for the sprint relate to it.  I've

      If you have an easy-to-understand sprint goal, you can read it off in the standup and quickly make sure that the team is still focused on delivering this goal.  The team acts like a team.  When team members discuss what they did yesterday and what they're going to do today and whether they have any impediments, it's relevant to everyone because everyone is working toward that single goal.  

      If the sprint goal is a fuzzy mess, you tend of have everyone on the team working on different stuff.  It's not a team of x number of developers, it's now x number of developers sitting in the same area.  You can see this in the daily standup, too because no one will care a lick about what anyone else is up to.  Why?  Because everyone's got their own assignments and there's little or no overlap.   No one can really wrap their head around the sprint goal and it is quickly ignored.  

      Just a thought -- If the sprint goal is difficult to establish, this might be an indication that the backlog isn't adequately prioritized (ordered) or understood by the PO or the team.  If everyone has a decent idea about what the priorities are for the next few sprints, establishing a goal becomes a lot easier.  


      --- In scrumdevelopment@yahoogroups.com, Michael Jones <michaelhardwinjones@...> wrote:
      > Hi Wouter,
      > Thank you for that, makes a lot of sense and introduces a new angle I
      > hadn't thought of - pair programming to facilitate cross-education in the
      > team. Maybe it's not so inconceivable that the developers could work on the
      > range of technologies. In our company this would be a revolutionary thought
      > as we think in terms of these technology silos.
      > You mention variety in the sprint - in your view (and anyone else) is it
      > acceptable to have different user stories / features focused on different
      > things in the same sprint - e.g. embedded video, a content carousel, etc.
      > Or should each sprint have a single goal / focus?
      > Thanks again,
      > Michael
      > On Wed, Dec 21, 2011 at 10:48 PM, Wouter Lagerweij wouter@...wrote:
      > > **

      > >
      > >
      > > Hi Michael,
      > >
      > > The first thing that comes to mind is that the different areas of
      > > expertise you mention aren't all that far away from each other, so some
      > > cross-education (by pair programming) doesn't seem so far fetched to me...
      > > Most Java developers should already be familiar with XSLT, velocity, etc.
      > > Or at least able to learn it quickly.
      > >
      > > Another thing that comes to mind is that if there's only one story in your
      > > sprint (assuming 'feature' == 'story', which might not be the case), then
      > > your stories are too big. Split them up (NOT by technical specialty!) to
      > > limit risks of failing sprints, etc. And going more fine grained will allow
      > > you more flexibility in getting more variety into the sprint.
      > >
      > > Even then, though, it will make sense for the people with the
      > > different specialities to learn each other's work. Pair them up, and see
      > > how that works out. I think you'll be surprised how quickly the
      > > specialities either disappear, or at least become much less important.
      > >
      > > Wouter
      > >
      > >
      > > On Wed, Dec 21, 2011 at 4:32 PM, Michael Jones <
      > > michaelhardwinjones@... wrote:
      > >
      > >> **

      > >>
      > >>
      > >> An interesting real-world challenge
      > >>
      > >> We're forming a Scrum team to work on feature development for an online
      > >> journal (things like embedded video, etc).
      > >>
      > >> Our publishing process involves XML files being rendered as HTML via an
      > >> inhouse XML transforming application, plus Velocity macros. Occasionally
      > >> data needs to be retrieved from various databases and content stores, using
      > >> applications primarily coded in Java.
      > >>
      > >> In our team we have developers proficient in a) XML transforming and XSL;
      > >> b) Velocity development (and associated HTML and CSS coding); and c) Java
      > >> application development.
      > >>
      > >> Our product owner believes that in Scrum we're supposed to have one
      > >> sprint goal per sprint - i.e. all team members work on the same feature
      > >> together.
      > >>
      > >> But what if a particular feature requires a lot of Java development and
      > >> hardly any Velocity development?
      > >>
      > >> Doesn't it make more sense to have the team work on a set of features
      > >> together, perhaps focusing on a single one as the priority but then picking
      > >> up further items where there's capacity?
      > >>
      > >> In an ideal world, each developer would have the skills to pick up any
      > >> item, relating to any of the three technologies - but that doesn't seem
      > >> realistic in our case. We'd be asking highly specialised developers to
      > >> retrain.
      > >>
      > >> Grateful for your thoughts, thanks,
      > >>
      > >> Michael
      > >>
      > >
      > >
      > >
      > > --
      > > Wouter Lagerweij | wouter@...
      > > http://www.lagerweij.com | @wouterla <http://twitter.com/#%21/wouterla>
      > >
      > >
      > >
      > >

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