More on Date vs Scope – Solution: Staying Releasable?

My discussions with Paul at BMC continued, and I think we arrived at a reasonable conclusion as the thread below illustrates. (You might want to start at the bottom and read to the top.)

Paul,

Ah, I think you have found the keenest insight on the thread:

” being releasable within the iteration” (and release)

Indeed, when this is accomplished, the decision to release or not is either obvious or moot. You can release now, and again later if need be (subject of course to all the significant issues outside the organization in supporting a release). In general, the date vs scope problem is largely mitigated.

Of course this is based primarily on solid engineering practices, not management practices, and all teams struggle with staying releasable. I would have to say that I do see teams able to release almost weekly (each iteration is indeed a potentially shippable increment of functionality), but I will have to be honest and say that I have never seen a team or application of the scope of performance manager yet achieve that objective. So when it comes to TDD and continuous integration at your scope, you are pioneering new ground, so take a deep breath, and dive back in to “staying releasable”.

Dean

—–Original Message—–

From: Beavers, Paul

To: Dean Leffingwell

Dean,

Thanks for the response and the thought provoking ideas. Your explanation makes sense to me. To be honest what we strugglle with the most is still being releasable within the iteration. If we could fix that issue we would rarely be faced with the end game decision of to ship or not to ship. Seems there is some value in optimizing such that the decision doesn’t even need to be made.

Thanks,

Paul

Fixed Date or Fixed Scope at Enterprise Scale?

Well, the “fix the date and adjust the scope mantra” of agile is still subject to ongoing debate in some circles. In general, I stand by my suggestion that the easiest way to establish an agile, quality-based, software delivery rhythm is to fix ALL the release dates well in advance and adjust scope so that they are reliably met. Of course, there are exceptions to every rule. For further illustration, I thought you might benefit from an “up close and personal” discussion with some of the executives at BMC (provided with permission of course).

First, the question from Paul Beavers, a Development Director at BMC:

Dean,

“I would like your opinion on our thoughts / dilemma here. As you know we have implemented Scrum across the entire BPM organization, today it touches about 250 people.

Frequently, we find ourselves at the time in which we scheduled to release our products to manufacturing faced with a decision. Typically, the decision is do we ship the product at the scheduled time or do we put in one critical late breaking feature. Often times, this decision is around whether or not to fix a bug and slip the date or release with the bug. Often times we know the answer to the second question based on the severity of the defects. My belief is if we evaluate early enough and decide to add a hardening iteration and move the date, it is not particularly in violation of good agile practices, as long as the manner in which the date change is made is controlled and systematic. As I am sure you have encountered, there are purists who say ship on the originally planned date no matter what. My view on the matter is being Agile and following Agile principles does not allow us to relinquish responsibility for “thought” in each business situation.

I would like to understand your views on taking a hard line on the dates versus being flexible. What are the drawbacks to each approach?

I look forward to discussing this with you.”

Paul

============================

My response below:

From: Dean Leffingwell

To: Beavers, Paul

Subject: RE: A couple of ideas and advice related to Agile

Hi Paul,

I know you know that there isn’t a “right” answer to your question. Indeed, I have had some interesting discussions with Jim Highsmith on this very topic and the “fixed scope or fixed date debate” will go on for years to come. But here are some (please consume then in parallel, ie initially unrelated) thoughts for context:

1) I’m one of those that pushes hardest to meet the date because agile is dependent on a team meeting its near term commitments. (long term is so uncertain, something has to be relied upon). Moreover, holding the date forces effective scope management, so teams learn that they can’t just shove more scope into a scheduled release because the date is firm and the resources are committed. That forces prioritization on the part of product owners which is requisite for agile development, and yet product owners are very reluctant to prioritize until forced. In addition, prior to agile, teams haven’t been meeting their dates generally, so insisting on date commitments resets the standard of accountability in the organization and highlights one of the major benefits of agile. “we meet our commitments”. It also forces moving testing forward in the lifecycle. (“the end date is known and soon, I have to be testing now”). It also allows outside organizations, marketing etc, to depend on software delivery time-lines, often for the first time in their careers!

2) One question for the organization is what is “routine” and what is “exceptional”. If it is routine to slip the date and add features at the last minute, we know that doesn’t work because of the inevitable quality slippage, death marches, etc. , and that does not characterize agile. If we slip it one time and one feature, why not slip it the next time and add 3 features; pretty soon value delivery lags, and agile or not, the organization is not delivering reliably. But if its exceptional for a specific purpose, for an organization that routinely meets its commitments, and otherwise follows solid agile practices, then it can be highly useful at times to take the exception.

3) One of the most memorable agile mantras I’ve heard is to defer decisions (admittedly, design decisions form the speakers perspective) to the “last responsible moment”. That should give enterprises the flexibility to do the right thing, whatever that may be, and to decide later in the cycle than would be the case with waterfall methods.

Vignette 1, I once saw a great agile team extend one iteration to three weeks from two, because of interdependencies and conceptual integrity of the iteration. This is completely counter to all advice of keeping all iterations exactly the same length. And yet at the time, I thought it was brilliant, but only because they had shown that they could deliver reliably iterations every two weeks for almost six months first, and I had no fear that they would decide they liked 3 weeks, or 4 weeks, or 5 weeks better than two, because they had truly mastered agile. In this case, scope wins.

Vignette 2: I’m working with a development stage company right now, and the only thing I can tell them for certain is the date we will ship, even though we are clueless as to what that might actually be! In this case, date wins.

So no, I don’t take a hard line always on fixed date, but I’m about 80-90% biased that way, and nearly 100% biased early in an agile transformation.

Happy to talk more.

Dean