Re: [scrumdevelopment] Re: Nitty-gritty detail of updating Scrum artifacts
- On 6/30/06, Alex Pukinskis <alex@...> wrote:
> Of course, this requires having an open space with desks that allow forNo, they're not convinced so I have work to do there... I agree 100%
> pairing; this means not using the L-shaped desks designed for people working
> Does your team pair in the open space?
that pairing makes a team more resilient against distractions, but the
team members (all young people in their twenties, so technically
skilled but relatively junior with respect to development methods,
good practices, etcetera) think that working alone with headphones on
And we have indeed these L-shaped desks, which makes it hard to do
pair programming.We had an interior wall moved out by half a meter and
we have some spare desks now that a couple of people have moved away,
so coming week I'm going to experiment with the free space and free
desks to see whether another arrangement works better. I'm a bit
hesitant to throw in my weight re. pair programming if we don't even
have an environment that makes it available. As soon as I have found a
workable arrangement, I am going to ask them to try it for a couple of
Another hurdle: there are three teams in that room - small teams, in
fact too small. One mini-team of 2 people maintains a separate website
and they work for someone else so I can't tell them to start
pairprogramming. "my" teams don't want to disturb them, because that
website makes lots of money and they like these guys. And if we, the
other 8 guys, start pairing and they still work as lonesome cowboy
coders, well... that'd be quite a disturbance, 4 conversations going
on all the time :-). So I'm working to have them relocated, closer to
their PO. Having that done will probably be another prerequisite for
my pairing experiments (no, we don't work on laptops so we can't go to
the restaurant and work there...).
So, in the meantime, all I can do is try to keep things silent...
- When I read about an organization with rampant context switching,
siloing and resource fragmentation, I believe it is management's
responsbility to figure out how to address the organizational
dysfunctions rather than blame the developers for not being able to
commit to what they can get done in short time frames under such
To say that the problem appears to be that the developers are slacking
off exhibits so much arrogance on the part of management, my gut
reaction is to suggest that if management has no more problems to
solve and yet the development throughput is unsatisfactory, then maybe
the organization needs less managers and more developers.
On 7/4/06, Wolfgang Schulze Zachau <wolfgang@...> wrote:
> The unfortunate lad reports to a different team, and I am allowed to make
> use of approx. half his time.
> I don't need to suspect. I *know* they all do things that are unrelated to
> sprint. This is due to all of us having to do day-2-day IT support for
> approx. 50-60 other staff (who range from almost complete computer
> illiteracy to somewhat advanced homw users), plus everyone has their
> personal career development objectives, which they need to spend 4 hours a
> week on doing.
> The support work is on average not enough to keep a full man busy, so we
> have decided to rotate this around, then at least everybody gets 4 days of
> relatively uninterrupted work per week.
> Have you sat
> > down with Jimmy and his partner and pointed out that they are
> > failing to meet their commitments, and asked why?
> Yep, I have. And that's when the excuses come alive. Which is why I wanted
> them all to report back how exactly they are using their time when not
> working for the sprint.
> There used to a habit here that other staff would just walk up to a member
> of the IT team, state their demands/requirements/wishes and expect things
> get done on the spot (supported to some degree by the MD himself). I have
> pretty much stopped that and now at least these folks either go through me
> or they log their work requests in the (ever popular) bug tracker, so that
> we can prioritize them and then schedule them.
> But then, we are an e-commerce company, our IT systems are the very blood
> that keep this company alive. There are numerous justified occasions where
> emergencies need to be responded to right away. I simply want them tracked.