Long term focus
AGILE methods emphasize realizing short-term OBJECTIVES rather than creating long-term objectives and trying to satisfy them.
I completely disagree with this statement. I don’t agree that short terms objectives are the emphasis in Agile methods and I don’t agree that short term objectives are preferred over long-term objectives. I think that Steve’s misunderstanding is rooted in the fact that he has only read about Agile methods, and not practiced them. I think that it is impossible to get a deep understanding of Agile methods by reading without experiencing. Therefore, I’d like to encourage Steve and others talking about Agile methods to try to get some experience before making such statements. I’d also like to offer an explanation that attempts to clear up this particular misunderstanding.
Steve described (in a telephone conversation) “the good old days” when he would spend weeks or months documenting the objectives of a project in a detailed way that could be tested. He noted that Agile projects don’t do this requirements definition phase. So far, so good. He then, however, made a leap to the conclusion that this was an indication that the long term objectives are deemphasized. Bzzztt! Wrong answer.
Agile methods emphasize the long term objectives every iteration–or even every day. I’ve previously blogged about What is Agile? In that posting, I noted that the fundamental definition of Agile (in my mind) was “the use of feedback that is
- aligned with our desired goals
That “aligned with our desired goals” includes the long term goals. Indeed, short term goals are mostly subservient to the long term goals.
The short term objective of delivering working software at the end of every sprint or iteration is a tool toward meeting the long term objectives of the Customer or Product Owner. As the Agile Manifesto Principles state
Working software is the primary measure of progress.
They state this because working software can be compared against the long term objectives to see if those objectives are being realized, how much of those objectives have been realized, and if those objectives still represent what the Customer wants in light of what has been learned.
So, what’s happened to the expression of those long term objectives that used to be entombed in detailed requirements documents in “the good old days?” Those objectives are now expressed in conversations with the Customer/Product Owner, who doesn’t “send the developers away to build two weeks worth of software,” but remains engaged in the process, clarifying, learning, and steering the project toward long term success.
At least, that’s the way it happens when things are done well. There are often people playing the Customer/Product Owner role who came from the same “good old days” that Steve remembers, or whose organizations have a culture bound strongly to that phasist vision of software development. In some cases, development does proceed without a vision of the long term objectives. And yes, Steve, things don’t work so well when that happens. This post is written to help those people understand a more effective approach that doesn’t throw out the baby of good things they know with the bathwater of phasist, predictive software development approaches.
Steve, I’ve tried to represent your position as clearly and fairly as I can. If I’ve misinterpreted anything, please let me know or leave a comment here.