24972Re: SV: [scrumdevelopment] To SCRUM or not
- Nov 4, 2007--- In email@example.com, "Martin Jul - Ative" <mj@...>
>take a few of the practises:
> Even if you don't want to change entirely to Scrum I would at least
>value - implement the most business-valuable features first, and deliver
> First, I would introduce iterative development driven by business
production-ready, running, tested software in small increments, say
bi-weekly. Since you are on a tight deadline this takes a lot of the
risk out of the project - or rather, moves the risk to the lowest-value
features rather than any feature.
>experience is that they get inspired at the demos of working software
> Also, even if management does not think there will be much change my
and see all the missing features and the features in the spec that are
not really needed.
>(see my post Iterative Development Gone Wrong about the Mini-Waterfall
> Inside an iteration make sure that you are not doing a mini-waterfall
. Rather, try to teach people to complete the application
>such as a burndown chart is really useful, too. If you are used to
> Using a daily stand-up meeting to talk project and a status indicator
estimating in hours you can use this - you don't need to learn user
stories to get benefit. Just track the total estimated-time-remaining
for the tasks in the iteration every day and you will have good
visibility into you status.
>impediments in your organisation - so even if you don't call your
> Also, if you have to deliver frequently you will see all the
project manager a Scrum Master, listen to the team and try to help the
team work around the dysfunctions of the organisation - or change it for
the better if possible.
>wording, so I guess it is kind of a Trojan Horse approach to
> I realize the above has most of Scrum in it, albeit with other
implementing Scrum - or at read it as an advice to get the "frequent
delivery of valuable business functionality" cycle going and then take
it from there.
I find your description appealing, yet for me there are some gaps that
1. You refer to prioritising feature development by business value. In
the absence of a formal sprint planning session, how does the team get
to know what to do?
2. You refer to delivering production-ready software bi-weekly
[fortnightly?]. In the absence of a formal review, to whom are these
shown or delivered and how does the team know that they are, indeed,
3. You mention the team seeing the impediments in the organisation. In
the absence of a formal retrospective, when and how does the team expose
these or examine and improve its process?
4. You mention listening to the team and trying to help them. Who does
this? What (Scrum) skills does she need to do this?
I'm always curious to learn more about managing people's fear of change.
- << Previous post in topic