XP Day: Don’t Try This at Home

It was good to be back at XP Day a few weeks ago to see old friends, meet some new people and have some interesting discussions. I decided to pitch an open space entitled Don’t Try This at Home to discuss agile practices that had crashed and burned for people in the past 12-24 months and to explore why. The table below is a write-up of the discussion and some of the conclusions/suggestions that came out of it. Thanks to everyone who took part.

What Symptoms Why
Customer collaboration
1/month team visits to customer
Customer is: Busy, far away, not onsite
Team don’t deliver what customer wants
Different person goes to capture stories each time
Stress to sort it out
Department manager (product owner) too busy
Department manager not a good BA
Department manager needs to be a real proxy – needs time with real customer
Possible solution: Get a product manager
Process improvement
Long engagement – years
No discussion/unclear about hose budget it comes out of
Technical debt/refactoring is under the covers
There is a customer/supplier relationship rather than collaboration
Possible solution: Can you make it clear that process improvement is part of your BAU development?
Visual design
Look and feel – apps for iPhones
Fear of wasted effort
Engineers block waiting for UI design
No sign-off for UI – not high-fidelity enough
Want to be working in parallel
Possible solution(s): Can you interleave UX and development cycles?
Maybe experiment with slicing the work in different ways: vertical slices front-to-back, broader scenarios, etc.
Can you mock the functionality needed for the scenario to support this?
Should you just accept that rework will be needed and educate the customer/PMs?
Retrospecctives
1 every 2 weeks
People just address low-hanging fruit
Otherwise they have accepted the pain of the things that are not right and don’t get fixed
Short-lived projects
Possible solution(s): Not sure there is one
Daily scrum
1-month cycle
Low energy
No communication or too much of it
Looking at the manager and not at each other
Going round people in a very rote way
There is not really an understanding that it is a team tool and not a management tool
The people who lead it are not necessarily trained
Scrum master insists that they run the standup
Possible solution(s): Own your story (talk about stories rather than round-robin)?
Understanding the motivation/training for the team on standups?
Generating some team motivation for changing the standup
Shorter cycles – 2 weeks?
Better ceremony – work the board from right to left – 3 passes (blocked, slow, issues) – pass the token to person who is responsible for the given story
Swap people running the standup
Planning sessions Team are nervous to commit
Everything is spiked to make estimates firmer
People give in to the biggest mouth
Team feel compelled to complete everything they put in the iteration backlog
People defer to senior developers
Blame culture
Possible solution(s): Take senior developers out of the meeting?
Make it clear that there is no expectation that everything estimated will have to be delivered.
Be strict about planning poker (everyone votes at the same time)

I wrote up a little about standups in another post.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s