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

Re: Scrum in a less flexible environment and with junior developpers

Expand Messages
  • swanson_brad
    ... If you build the most important features first, and demonstrate working softare, the stakeholders may change their mind about scope; once they see 70% of
    Message 1 of 3 , Aug 29, 2006
    • 0 Attachment
      --- In scrumdevelopment@yahoogroups.com, "Olivier"
      <olivier.dedecker@...> wrote:

      > One of the components involved is highly innovative (functionnaly)
      > and a traditional waterfall approach to build this component has
      > failed (project delayed several times, budgets incrased, etc...).


      > We are currently trying to adopt Scrum as a method to run this sub-
      > project, i.e. defining 3-weeks sprints, having a daily scrum,
      > maintaining a product & sprint backlog, implementing (semi-)
      > continuous integration, burndown chart, etc...
      >
      > After 2 sprints we have made good progress in terms of team
      > motivation and productivity. However, we are having the following
      > issues :
      >
      > - There are no identified functionalities of the component that can
      > be de-scoped from the user point of view. Therefor, any de-scoping
      > during a sprint will automatically shift the global release plan. In
      > adition to that, when reporting to the Board we have to make strong
      > commitments on scope / budget / plan. We are questioning ourselves on
      > the adequacy of an agile method in such a context.

      If you build the most important features first, and demonstrate
      working softare, the stakeholders may change their mind about scope;
      once they see 70% of the features working, they may decide they really
      can get by without the other 30%.

      The best way to be confident about commitments on your plan is to run
      several sprints as measure your team's actual velocity. You said
      waterfall has already failed, so hopefully the board sees the folly in
      trying it yet again.

      > We have a feeling
      > that with scrum we adress the important issues first, but that we no
      > longer adress the longer-term vision in terms of architecture and
      > planning. We don't know how to reconcile both approaches ...
      > - Our development team has many junior developpers that don't have
      > the 'global picture' in mind. Letting them prioritize work sometimes
      > leads to inconsistencies since dependencies between pieces of work
      > were not taken into account.

      Who said developers are supposed to prioritize work? The product owner
      prioritizes work primarily based on customer input.

      The junior developpers also under-
      > estimated the workload at the begining of the sprint and had to de-
      > scope the sprint. We have a strong feeling that more team hierarchy
      > is needed and that senior developpers should coach / manage more
      > junior staff (i.e. only senior developpers should prioritize work)
      >

      No methodology can make up for having the wrong people on the team.
      That is one of the fallacies of heavyweight prescriptive
      methodologies: "If you just follow exactly steps A-Z, and document
      everything along the way, tehn anyone can build perfect software! "

      If your team is more junior, or doesn't have the right mix of
      specialists (programmers, DB developers, testers, etc.) it will
      probably have a lower velocity. At least with agile you can measure
      the teams true velocity early, and make adjustments if needed. If the
      team is truly self-organizing, you might be suprised how much they can
      get done.

      Strong coaching and servant leadership from a good scrum master can go
      a long way in this situation, IMO.

      Cheers,

      Brad Swanson
      Certified Scrum Master and Agile coach
      bsidebrad.blogspot.com
    Your message has been successfully submitted and would be delivered to recipients shortly.