Agile Zone is brought to you in partnership with:

James is a consultant, author, and speaker. He brings a rare combination of business savvy, deep technical understanding, and an engaging presentation style to his work, putting him in demand around the world. James is a prominent figure in the Agile community: he is an inaugural recipient of the prestigious Gordon Pask Award for Contributions to Agile Practice and one of the first ten people to sign the newly-released Agile Manifesto in 2001. James keeps a blog at and is co-author of The Art of Agile Development. James is a DZone MVB and is not an employee of DZone and has posted 61 posts at DZone. View Full User Profile

Rabu Workflow: How Do We Get Customers to Participate?

  • submit to reddit

How do we get customers to participate in Agile development?

An Agile team is supposed to be able to move full speed ahead at all times, making critical product decisions when they're needed without waiting for approval or clarifications. To achieve this, Agile teams are supposed to include full-time business experts who have the authority to make key business decisions. An established Agile team needs two business experts for every 3-6 programmers in order to keep moving quickly.

Sufficient customer involvement is crucial to Agile success, but it almost never happens. For whatever reason, the people most qualified to be customers on an Agile team usually don't want to take that role. Instead, I typically see overworked product owners assigned part-time to multiple teams. They often have limited decision-making authority and relay questions to the real decision makers. Defects and delays result, and it's no fun for the product owners, either.

Defects and delay. For many established Agile teams, the constraint isn't lack of programmers; it's lack of customers.

The Rabu Workflow

What if we accepted this constraint as reality? Even on the very best Agile teams, you can't have all decision-makers on the team full-time. Yet we need to collaborate with stakeholders. We can't expect them all to join our team, but we need to continue making progress anyway.

Rabu is oriented around this constraint. The core idea is that customers are much happier providing feedback on a proposal than writing on a blank slate. Look at it from their perspective: as a stakeholder, would you rather be put on the spot with an open-ended question like "what do you want," or would you rather critique a proposal?

In the Rabu model, the Agile team makes all the decisions about their work. They have the most information and are most qualified to do so. When they need feedback, they create a proposal--that's where the Rabu tools can help--and ask for feedback in tightly-focused meetings. Sometimes different stakeholder groups will have conflicting reactions. The team's job is to collate those responses and make the decision that's in the best interests of the product.

 Dev team wants feedback; Create straw-man proposal that facilitates discussion; Hunt down stakeholder group(s) and discuss proposal; Collate notes and make decision; Act on decision; Repeat.

By putting decision-making responsibility back into the hands of the team, this workflow allows the team to keep making progress even when outside feedback is needed. Stakeholders are more willing to participate because their time is being used well. Most importantly, the Rabu workflow doesn't require any special dispensation from the organization. It's something that most teams can start doing today.

Sign Up

Team Rabu is focused on creating exemplary customer relationships. Our first product is tools and ideas for product scheduling. (Read the announcement here.) If you'd like to be one of the first to try it, provide your email address here. I promise not to sell your address or use it for other nefarious purposes.

Published at DZone with permission of James Shore, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Mark Anthony replied on Fri, 2012/04/13 - 9:57am

We do often do this, sometimes more out of desperation than as a planned strategy, but I do think it's a good idea. In addition to mitigating the issues of customer availability, it also can allow the development team to inject good practices about security, usability, accessibility, etc. before the customer gets involved. This can head off a lot of problems later. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.