Forums

By posting to our forums you are agreeing to the Forum terms of use.
Scrum Studios
Last Post 31 Dec 1899 11:00 PM by . 0 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Ian Mitchell
Advanced Member
Advanced Member
Posts:581
Ian Mitchell

--
02 Sep 2013 03:33 AM
    I have a public sector client who started an agile transformation about 6 months go. Their current position is one of WaterScrumFall. They have hired nominal Scrum Masters (some agile terminology has been pillaged), but as of yet are nowhere near implementing Scrum:

    - For any given project, there will be an extended period of hierarchical, epic-first requirements decomposition.
    - There is extensive up-front design and planning
    - In their SDLC, development sprints are encapsulated in a stage gated phase towards the end.
    - There will be one release at the very end of a project, with no intermediate releases either planned or to be delivered on demand.

    This is quite typical for any large organization that has agile ambitions, but which has political barriers and cultural practices that impede transitioning. There's no easy fix to this; it will take a long time and probably a number of failures before substantial change is attained.

    What is interesting though, is that this client has gone some way towards putting a "Scrum Studio" model in place for software development projects:

    - There are half a dozen Scrum teams.
    - If any project needs doing, one of them will be assigned.
    - This model theoretically provides continuity of teams over the course of many projects.
    - It's different to having one team follow a project all the way through to maintenance and support.

    The Studio model can be effective as an intermediate step in enterprise transformation, and I'd like to encourage it further. However, in this case, it has been compromised by the way each team in the studio is resourced. In short, project managers are making decisions about who goes into which team and when. This leads to instabilities in team identity, inspection and adaptation, and metrics. Retrospectives also indicate it is demoralising to the teams when their members are moved around.

    My contention is that it should be up to the teams themselves in a studio to make decisions regarding their composition and rotation. It's all part of being self-managing. I'd observe that teams can handle uncertainty in scope much better than they can handle inconsistency in their membership.

    Does anyone else have a view on how best to resource teams in "Scrum Studios"?
    You are not authorized to post a reply.


    Feedback