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.
blueskyline 