For a time, I hosted the Portland Software Development Roundtable. For a few of these sessions, I took notes and published them here.
The materials that follow are very rough outlines of our discussions: you won't find polished articles here. These outlines don't necessarily reflect my point of view or the point of view of all of the attendees.
How do you encourage lead customers to be fully functioning members of an agile team?
Background reading material:
The XP books from Kent Beck, Martin Fowler and others.
My own experience:
As I am implementing a user story I often find that I have to make many decisions that require quick feedback from the lead customer. I find that the best way to flesh out the details and make a good decision is to have a face to face meeting with the lead customer. This may involve a white board and a lot of back and forth questions and answers. In a quick meeting we can flesh out the details of the story, capture any decisions made, and hopefully make great progress on the user story.
But if the lead customer is not immediately available I have to either schedule a meeting and wait, send out a request for information in some form, or make my own decision and move on. Since an agile process is designed to keep the lead customer responsible for user story definition, it seems like a good idea to keep the lead customer involved in any story changing decisions.
Of course there are many communication options such as email, instant messaging, telephone, virtual meetings, etc. But these just don't seem as good as meeting face to face together with a whiteboard.
So, how do you deal with an agile team, where for whatever reason the lead customer is not physically available and may be slow to respond in other communication media? If this is a long term situation, how do you encourage product owners / lead customers to be fully committed and functioning members of an agile team?
- Rodney Bell
- Karen King
- Randy King
- Rebecca Kun
- Diana Larsen
- Jim Shore
Notes from our discussion:
- What is "agile?"
- See the manifesto
- What is "customer?"
- Product manager
- Shouldn't it be the person paying the bill?
- Gold Owner vs. Goal Donor
- For a product, if you don't have a member of marketing, you will fail
- Only those with experience in software realize this
- Start with management
- Culture of organization is also a factor
- Customers who want to be involved in everything -- even code reviews
- Customers available until they get busy with other things, then they disappear
- What about customers who don't represent the market?
- Engineering will succeed and product will fail
- Challenge is when you're entering a new market
- Agile is helpful - explore ideas, get customer feedback
- Where I've seen agile customers succeed, there was a customer team
- Best customer teams are product teams
- Business success/failure based on software
- Government IT sees users as slaves
- Opposite perspective: IT seen as guys fixing the laptop--throwing requirements over the wall
- There's a need for education on the business side
- Not a lot of cooperation between business and IT
- Keeping biz engaged over multiple releases is also a problem
- Story of large goverment software product in Oregon:
- Continuously involved users over 8 years, 19 releases, 6 major releases
- 1000 users around the state
- Moved 7-8 users to Salem for six months at a time to work out detailed requirements
- Large user groups did extensive testing close to the release
- Elaborate feedback channels
- Had to commit a huge amount of money to user involvement
- Backfilling employees who were moved
- Management buy-in
- Never seen anything like it
- Initially, engineering succeeding, users happy, but management didn't see benefits
- At first, there were no business benefits
- Had to ramp up
- Work process had to be changed
- It was worth it.
- How did this happen?
- Consulting firm running the project said, "this is the way it has to be."
- A counter-example
- Consultant didn't involve users directly
- Two years of detailed analysis and design
- Were going to send it off-shore
- Cancelled while test scenarios were being created. No code had been written.
- Arrogance to believe someone can completely understand someone else's job without ever doing it
- Especially since the person doing can't even fully describe it
- Another story
- Terrible deadline issues
- Project manager didn't want to talk to customers in fear of scope creep
- The only way out was to call it "success" and get rid of everybody (except two engineers) and start over with users on-site
- New product manager had serious customer focus--all she cared about was what the users could get out of it.
- Went from worst-regarded project to award-winning tool.
- Because of customer focus
- How do we get people to do this?
- Buy-in. In heirarchical organization, top-down.
- ROI (but it's very hard to measure)
- "If you want us to do this project, this is what you have to do for us to be successful."
- "If it's not important enough for you to devote these hours, why are you doing this project?"
- Is the agile community writing about this?
- Angela Martin's Ph.D. research
- She's also a practitioner, not just a student
- Standish Group's CHAOS report
- Linda Rising & Mary-Lynn Mann's Fearless Change: Patterns for Introducing New Ideas
- Very pragmatic, fantastic
- Glimpses of the blindingly obvious
- That's what patterns are all about
- Customer proxy bias
- Customer proxies (e.g., product managers) who think they know what the customers want and project their own bias
- A story of a proxy who is also paying for development
- Proxy is also the user--but not a typical user
- Thinks his usage is typical usage
- Enough money to go this way for a while
- Personas--"I wonder if there are other types of users"
- "Reverse the roles" role-play
- Tough to get the buy-in to take this seriously
- Are you enabling this behavior?
- Yes, lots of people are
- Walking away is a statement of last resort
- An intermediate step is to give direct, honest, clear feedback and be prepared to take the consequences