Methodologies The project team will use the Scrum method…

You certainly have a schedule to report to the customer. The key is in the level of detail.

Having the level of detail match (inversely) to how far ahead you’re planning — it very much applies to customer communications.

It’s obviously damaging to promise something very specific and tied to technology with significant risks (e.g. we will deliver a SQL-based filesystem with the Vista release in 2004), rather than something general and tied to customer pain (with the next release of Windows, we will make it much easier to find information scattered around your computer).

So, just as for internal planning, you match detail to (1) how far out in time you’re planning and (2) how risky your domain is.

For frequency of communication, see pitfall #4. Just like every customer doesn’t want to see every daily build or monthly internal release — a good schedule will be constantly shifting and adjusting, and most customers won’t want to see all that on the same short cycle that your internal teams will and should.

All that said, the more transparency the customer wants and the more you’re willing to provide, the better. If they can truly see the ups AND downs of progress, and not freak out about the downs, the more they can be strong, reliable partners in helping you deliver the right product for them.

Note I’ve spent most of my career in large product companies (not consulting) — so apply my advice in a domain like consulting with a grain of salt.

[Updated after clarifying my thinking] Ken Schwaber , one of the co-creators of Scrum, claims to not…

“First, the Toyota Motor Company has an annual plan. This means the rough number of cars…to be produced and sold during the current year. Next there is the monthly production schedule…Based on these plans, the daily production schedule is established in detail and includes production leveling.”

–Taiichi Ohno

Since my big project team operates with a strict one-piece pull, we’d get lost pretty quickly without some kind of planning guidance. Using a Rolling Wave model allows us to prioritize just enough to keep the backlog full of high-value work, helps us identify and manage dependencies and risks, and gives us context for process improvement goals.

Rolling Wave might not be necessary for service processes like David’s sustaining engineering process, but I can’t imagine doing a lean project without it.