Thanks for responding to my post. Indeed we are looking for a deep /
long-term change in our method and we expect to continue to adapt our
processes and organization as we go along.
> Is the team
of 150 divided into sub-teams?
Yes, there are several (5) sub-projects that all have several sub
teams. The team that adopted scrum has about 15 people.
> Who has the knowledge of what is to be done - requirements?
Another team of 4 business analysts (lead by one person who is
ProductOwner) . There are also two architects that do detailed design
work, based on the requirements.
> How are those requirements gathered?
Through user interviews. Use cases were written, but they merely
describe the basic course of action. There are also GUI
specifications. All the detailed business rules are not always
described before the start of a sprint. During the sprint the
developpers have interactions with the business analysts.
> How familiar are users with existing system which needs to be
The users know the existing system quite well.
> Finally, why dont Junior Developers have the "big picture"?
Because the component is complex and has many dependencies &
intercations with other components. Also, before adopting scrum, the
developpers were not encouraged to learn or understand what the
others were coding. Today, with the daily scrum, this is changing.
However a junior developer is not able to anticipate all the effects
of his work in the rest of the system.
> Olivier <olivier.dedecker@ ...> wrote:
> To: scrumdevelopment@ yahoogroups. com
> From: "Olivier" <olivier.dedecker@ ...>
> Date: Mon, 28 Aug 2006 15:31:17 -0000
> Subject: [scrumdevelopment] Scrum in a less flexible environment
and with junior developpers
> Being new to this discussion group I'm not sure if this
> already been
answered and I apologize in advance should it be the
> I am working on a large-scale IS re-engineering programme (multi-
> project, multi-year, overall programme size > 150 people). The
> objective is to gradually replace legacy applications by a
> based architecture.
> 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.
> adition to that, when reporting to the Board we have to make strong
> commitments on scope / budget / plan. We are questioning ourselves
> the adequacy of an agile method in such a context. We have a
> that with scrum we adress the important issues first, but that we
> 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
> leads to inconsistencies since
dependencies between pieces of work
> were not taken into account. 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)
> Has anyone had a similar experience in such a context ? How did you
> adress those issues ?
> ------------ --------- --------- ---
> Get your email and more, right on the new Yahoo.com