Use Cases and object oriented analysis and design

[ConvertFromOldNGs]

by Hugh McColl >> Wed, 9 May 2001 11:45:51 GMT

Jim focusses on software development management but does not explain how his ideas fit with fixed quote contacts.

I think the intent of the 'Retiring Lifecycle Dinosaurs' article was more to challenge conventional thinking and to provide readers with a taste of what Adaptive Software Development is about than to explain in detail how ASD handles project initiation, and costing. Those issues are most likely covered in Jim's book:

Adaptive Software Development: A Collaborative Approach to Managing Complex Systems Highsmith, James A. III (2000) Dorset House Publishing.

Martin Fowler in 'The New Methodology" http://www.martinfowler.com/articles/ne ... ology.html explains:
"A fixed price contract requires stable requirements and hence a predictive process. Adaptive processes and unstable requirements imply you cannot work with the usual notion of fixed-price"

Jim bemoans resistance to changing software development and management

practices, but do these changes require corresponding >changes to software sales practices?

Sounds like a good idea to me!

Or to the way that customers 'buy' software, as something that has, as Jim describes his brave new world, 'shades of grey'. Sounds like bugs to me!

It sounds like you have taken Jim's 'black and white' versus grey metaphor out of context. This metaphor was used in a comparison between optimising and adaptive cultures under 'Toward The Future'.

Some of it is just the same tasks we do now, or the same ideals we strive for now, but rehashed with different names. Also, some ideas do not scale.

Neither do the proponents of adpative methods claim such scalability, quite the opposite in fact.

Martin Fowler admits: http://www.martinfowler.com/articles/ne ... ology.html
"One of the biggest limitations to these new methodologies is how they handle larger teams. Crystal has been used up to about fifty people, but beyond that size there is little evidence as to how you can use an adaptive approach, or even if such approaches work at all."

And Highsmith of XP: http://www.cutter.com/ead/ead0002.html
"I must admit that one thing I like about XP's principal figures is their lack of pretension. XP proponents are careful to articulate where they think XP is appropriate and where it is not. While practitioners like Beck and Ron Jeffries may envision that XP has wider applicability, they are generally circumspect about their claims. For example, both are clear about XP's applicability to small (less than 10 people), co-located teams (with which they have direct experience); they don't try to convince people that the practices will work for teams of 200."

[ snip ]

Then who pays for any unplanned speculation/collaboration/learning cycles?

In ASD, a dynamic Speculate-Collaborate-Learn cycle simply replaces the static Plan-Design-Build of the conventional waterfall based paradigms; far from being unplanned, it is an essential facet of the ASD methodology.

[ConvertFromOldNGs]

by Darrell Duniam >> Wed, 20 Jun 2001 0:08:15 GMT

Jim Highsmith has produced a paper termed "E-Project Contracting", which discusses the issue of fixed-price contracts. He uses the term "Delivered-feature Contracts", and I quote:

"With a delivered-feature contract, at the end of each short delivery cycle the development team demonstrates features to the customer. The customer evaluates value delivered, and if acceptable, the development team and customer proceed to replanning the next cycle based on current information. Commitments for the next iteration are based on delivered value and the next iteration's plan. There are, of course, overall targets for schedule, cost, and scope -- but these are not contractual obligations on either party.

Delivered-feature contracts are the ones that make the most sense in this environment, because they best fit the problem domain, how the work should be accomplished, and the necessary working relationship with the client. But actually, if you have the first three, nearly any type of legal contract can be made to work. If you don't have the first three, no type of legal contract will work."

Of course, the sales people need to be "educated" to appreciate the concept, and to negotiate the contract(s) accordingly.

I have a copy of this paper if anyone is interested.

darrell.

[ConvertFromOldNGs]

by Hugh McColl >> Wed, 9 May 2001 8:33:52 GMT

It's a fixed quote world.
The customer wants to know what it's IT spend is up front, and once fixed, is reluctant to change.

That's probably true in the majority of IT business relationships; I suspect that's why the Software Industry as a whole has such an abysmal success rate (at delivering sofware that works, on time and under budget). Customers and suppliers that believe they can operate sucessfully and competitively within the constraints of a fixed price contracts are well suited to each other.
INCIS is a classic example of a fixed-price contract you can guarantee was high on ceremony, documentation and contract negotiations that went over-time, over-budget and delivered virtually nothing of value to the customer!

Martin Fowler has some words of wisdom on these issues: http://www.martinfowler.com/articles/ne ... ology.html

In particular, check out: The Unpredictability of Requirements, Is Predictability Impossible? The Adaptive Customer

On 'The Adaptive Customer", Martin Fowler had this to say:

"In an adaptive process the customer has much finer-grained control over the software development process. At every iteration they get both to check progress and to alter the direction of the software development. This leads to much closer relationship with the software developers, a true business partnership. This level of engagement is not for every customer organization, nor for every software developer; but it's essential to make an adaptive process work properly.

The key benefit for the customer is a much more responsive software development. A usable, although minimal, system can go into production early on. The customer can then change its capabilities according to changes in the business, and also from learning from how the system is used in reality. "

To effectively manage resource and cash-flow, the supplier also wants the value of a contract to be fixed.

Doesn't help when the project overruns budget, the likelyhood of this occuring increases with the complexity and unknowns.

The supplier may remember having it's fingers burned by overruns ... these are typically blamed on insufficient scoping (understanding of, or definition of requirements)

There will always be scapegoats when any project fails. As Fowler correctly states, the ability to get this right i.e. scoping (understanding of, or definition of requirements) depends on predictability. In today's changing world predictability is not the norm (and we are not just talking about user requirements).

... so driving ever more comprehensive documentation.

For those that prefer to stick with the old world predictive methods ......

Does the budget need to be as flexible as the developers?

Not a bad idea. If the supplier can demonstrate the ability to deliver valuable working software frequently and incrementally, the customer can see the value they are getting for each deliverable. Why not put an upper limit on the cost and a negotiable price on deliverables, payed on acceptance of each deliverable? Seems to me a lot better than the all or nothing big bang approach that is doomed to failure.

How much value did the NZ Police get for close to NZ $200 million in tax-payers money with a so called fixed-quote contract?

Finally another quote from Jim Highsmith:

"In an adaptive environment, learning challenges all stakeholders - developers and their customers - to examine their assumptions and to use the results of each development cycle to adapt the next." [Highsmith]

[ConvertFromOldNGs]

by Hugh McColl >> Mon, 7 May 2001 11:44:16 GMT

If you like books and have some money to spend, check out Scott Amblers recommended reading list on 'Software Process'

http://www.ambysoft.com/booksSoftwareProcess.html

At the top of Ambler's list:

Adaptive Software Development: A Collaborative Approach to Managing Complex Systems
Highsmith, James A. III (2000) Dorset House Publishing

"This is very likely the best book about software process that you will ever read. Highsmith has captured the fundamentals of how to succeed at software development in the modern age, presenting a framework of concepts and philosophies that can help your organization to adapt to the current realities of software development. Instead of following a strict set of tasks and processes, and then optimizing them over time, Highsmith instead suggests that your organization should strive for an adaptive culture that recognizes that uncertainty and change are the natural state. The material in this book is an excellent addition to that of eXtreme Programming (XP) and will help you to temper your tailoring of the Unified Process, OPEN Process, and/or the process patterns of the OOSP by also addressing the cultural aspects of your software organization."