Re: [scrumdevelopment] Re: Hansoft Project Manager is it any good?
To Ron and Bud: Point taken, I guess that I am trying to make an argument against something that is obvious.
After reconsidering we have decided to gradually setup independent teams, and agree with them on goals/backlog items to commit to. This approach will not solve the interdependency issue at first, since some people will be missed once they join a Scrum; however I believe that the interdependencies will become more visible, since they will not be solved by having everybody running around trying to communicate with everybody anyway. My hope is that the interdependencies will be visible to the Scrum Masters who will be responsible for ensuring that the matter is investigated at a higher level (if not resolved). Again this properly won't solve the problem but rather make them more visible. And force management to make priorities.
It should be noted that I myself is new to this organization, but have performed both Scrum and XP successfully in the past. I totally agree with any of you that proper training is needed, but as of current (this means the next 2 months) we will not be able to pull our project leads away from the project. And it is my strong opinion that something needs to change immediately, since the current feedback mechanisms are not working anyway. Communication tends to be ad hoc across the teams, and management is trying to catch up with a plan that is already outdated the moment they finish updating it. My argument would be that it is better to attempt to do Scrum than say you are doing a plandriven project that in fact is more like adhoc/chaos.
The team has previously worked with setting up small task oriented groups, so this development approach is not new to the team, and even if we had not chosen to apply Scrum we would still have made these Feature Pits as we call them. My point being that even though we don't nail the Scrum practices in the first go, the process of setting up small task oriented groups will help boost both morale and productivity.
I read the paper by Hubert Smith and Dean Leffingwell, it gave some good insights but I think it will be hard to actually go by their playbook in my current situation. Reasons why I think this is mainly because we only have one big project at the company at the moment – the company is the project. Therefore it is hard to introduce it gradually since no matter where you start it will affect the entire team. As Bud correctly pointed out it doesn't make sense to have a Scrum (or any agile activity) nested in a matrix organization, especially not if the entire organization is doing one big project.Thanks
/asbjoernOn 9/26/06, Hubert Smits <hubert.smits@...> wrote:
Not bad advise at all, thanks for this. I wrote about it with Ken Schwaber, which maybe helpful for Asbjoern and maybe others. Have a look at hubert.blogs.com for a whitepaper called CIO playbook.
--Hubert--On 9/26/06, Bud Cookson < Bud.Cookson@...> wrote:asbjoern - since you don't seem to be getting much in the way of useful traffic on this topic, I will step in with a few recommendations.First, you are looking at this move to agile/scrum from a classic Project Management point of view. Not a good thing. Your first step is to forget about your classic approach to creating and managing projects and start over. But, to do this, you need to understand the concepts.Once you have thrown away your classic approaches, go get one of the XP or Scrum books and read those. It will give you a better idea of what is involved. Then, find yourself a good Certified Scrum Master class and take that. This will give you a better idea of what is involved in executing Scrum on a daily basis.After all this, you still have two steps. You will need to get a good Scrum Coach that can help you organize and manage the pilot project(s) (a very good idea) and get you off the ground. The move to Scrum is a very complex combination of organizational and operational changes that CANNOT be done over night.Finally, your pilot project(s) will need to be organized in cross-functional teams. This means that your programmers, artists, 3D, AI and producer will all need to work shoulder-to-shoulder as a single team. No more functional groups. A matrix organization WILL NOT work in an agile environment.These are just the high level concepts but will give you a good path to moving your investigation on agile forward to a pilot project.As far as software is concerned, don't worry about that right now. The agile approach of doing notecards on a cork board is the way to get started. The software will come later.Best regards and good luck. BUD
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of asbjoernmaltesoendergaard
Sent: Monday, September 25, 2006 9:48 AM
Subject: [scrumdevelopment] Re: Hansoft Project Manager is it any good?
--- In email@example.com, Ron Jeffries
> Hello asbjoernmaltesoendergaard, thanks for your ideas. On Monday,
> September 25, 2006, at 4:55:55 AM, you wrote:
> > We need to be able to monitor a project of approx. 85 people working
> > in 7-8 teams. These 8 teams are constantly requesting support from
> > other teams and we need some way of formalizing this and track a
> > request (task) from one team to another.
> What is preventing you from setting up teams that are self
> sufficient, rather than linking them together in some kind of
> dependency chain? The dependency chain will slow you down, with
> mathematical certainty.
The project I am working on is a video game, which differentiates
itself from more traditional software products. The biggest difference
being that only about a 1/4 of the team are programmers. There is a
department of approx 10 animators, approx. 20 visual artists, and 20
game designers plus the approx. 20 programmers plus a R&D team of
approx. 15. Some of these departsments are split up in sub teams.
All these departments are all heavily dependent on each other. For
instance does the animation department need to cooperate closely with
both the people coding the animation system, and the people modeling
the 3D models.
In this sense all departments are each others customers one way or the
other, and it is very difficult to isolate the teams completely by
locking the sprint backlog since building a game on an unproven
technology demands a high degree of collaboration between departments.
Eventually we are aiming towards creating multiple teams that process
a higher degree of cross disciplinary mix, for instance making small
Scrums of animators, visual artist and programmers combined. But for
how we have decided to attempt to implement Scrum in the existing
teams first (one by one), it would simply be to big a risk to apply
this to the whole organization in one go.
Even tough we will get these cross disciplinary teams up and running
we will still need to have some Scrums that are highly specialized and
still dependant on the other teams.
> > Further more we would like to be able to get an instant overview
> > of the project progression on a daily basis, which I believe is
> > only doable if we have some sort of formal tracking.
> What kind of decision making are you doing, on a daily basis, with
> respect to these projects? I'm having difficulty imagining just why
> managers of this many projects would be making daily changes.
Well this is properly unrealistic to obtain completely, but the reason
why I bring this up is because this would enable us to track
impediments the different groups encounter and make sure that these
impediments are addressed as soon as possible. Some impediments are so
severe that we might need to allocate resources to this immediately in
order not to stall a whole team for a longer period of time. Further
more having this overview would enable us update the product backlog
for the team that needs to adress the issue as quick as possible.
> Are you using Scrum?
I am currently evaluating different software packages so we will have
software support when the organization is ready to adapt it. I have
been practices Scrum and XP before but never with a team this big,
hence I have never needed formal tracking procedures in form of a
software package before.
As of now we are not using Scrum, but since our MS Project file has
evolved to be a constant struggle to update the plan rather than a
tool that can be used to actively address planning concerns we have
decided to try to implement Scrum gradually. (Hence we are looking for
a new software package.)
Our initial step to implement Scrum in the organization is to start
out with two small teams tracking the process with excel spreadsheets
(not some smart software :-) ) in order to give focus to the process
on a smaller scale.
> How long are your Sprints? Are you making changes inside the Sprint
In the hope that we will be able to lock the sprint backlog during the
sprints we have decided to go with 2 week sprints. Ultimately the
success of this experiment will be higly dependant on our ability to
avoid changes to the sprint backlog.
> Ron Jeffries
> Keep away from people who try to belittle your ambitions. Small people
> always do that, but the really great make you feel that you, too, can
> become great." -- Mark Twain.
All opinions in this message are my own, and are not necessarily shared by my employer.