--- In email@example.com
> 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
Strong coaching and servant leadership from a good scrum master can go
a long way in this situation, IMO.
Certified Scrum Master and Agile coach