Re: Fwd: [scrumdevelopment] Scrum in a less flexible environment and with junior developpers
- Hi Olivier:
Thanks for your mail.
>> Yes, there are several (5) sub-projects that all have several sub teams. The team that adopted scrum has about 15 people.You have one Product Owner it seems. Whats the constitution of the teams itself? Does each team [or the team you are working with] have a product owner who can accept or reject the sprint work? Does the team have a SCRUM Master? Have the team workers been told that its their responsibility to plan the course of action in "discussion" with product owner? Have they been told that architecture/ designing is also their responsibility?
>> 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.
It seems that Business Analysts and Lead Architects need to be part of the sub-team. How long are the sprints and do architects only define for the sprint? How is architects work validated?
It seems that requirement gathering exercise is already over robust. However, I am not sure if understanding of the requirements is good or whether team finds the requirements documents useful at all [if developers are not able to pick it up and gather what the system is all about].
Have you considered having a Sprint where developers become familiar with the system [just enough] and consequently the amount of work at the end of sprint would be low?
>> Because the component is complex and has many dependencies & intercations with other components.The way you have phrased this it seems that your lead architects/ BAs seem to be doing a spectacularly bad job - if they are not able to design a system that is exactly opposite of what you say currently exists.
>> Also, before adopting scrum, the developpers were not encouraged to learn or understand what the others were coding. Today, with the daily scrum, this ischanging.
Do you imply that it is no longer the case? If yes, then you are already on your way.
>>However a junior developer is not able to anticipate all the effects of his work in the rest of the system.Why not?
Olivier <olivier.dedecker@...> wrote: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
Get your email and more, right on the new Yahoo.com