Have We Finished Yet?

Submitted by srobertson on Tue, 2007-03-27 08:58.

by Suzanne Robertson

In his keynote talk on dependable software at the 2005 Requirements engineering conference, Daniel Jackson’s urged us to “move away from infatuation with completeness”. This started me wondering – how often does anyone ever finish anything? In our everyday lives we say we have finished cleaning the bathroom, cooking the dinner, watering the garden, ironing the shirt, cleaning our teeth and a myriad of other things. But we don’t really mean that we have finished. Instead we mean that we do not have any more time to devote to that task and we have done the best that we can within that constraint. We accept the fact that we have limited time and that few of life’s daily tasks are finished to one hundred per cent perfection. Why should building software systems be any different?

A common complaint of software developers is that they don’t have enough time to finish a project. People in other professions for example engineers, architects, doctors, composers have the same problem but they have learnt to treat this as a normal constraint of their profession. They accept that:

there will always be more to do than fits into the time available
dynamics of the world mean that there will be changes that necessitate negotiation and replanning
they need to be able to communicate their plans to their clients.

This perspective is about how software developers can use these principles to free themselves from “infatuation with completeness”.

Attachment	Size
Have We Finished Yet.pdf	183.88 KB

» login or register to post comments | printer friendly version | 2598 reads

Expectations about completeness

Submitted by einarsen on Tue, 2007-03-27 16:19. *

I'm beginning to think that I live in a different world than many of the other BAs here. A harsher world, a less cooperative world. I'm a bit worried that it's me, but I don't think it is...

This article is fine as far as it goes, and illustrates a very "Agile-like" mindset about requirements... create a list and do as much as you can and ignore the lower priority ones.

My world isn't like that. If I started with 50 business functions and the client was prepared to pay $50,000 for those 50 business functions I would get a very different response to the following quote from the article:

ME:
"We have implemented software to support these 35 business events and we can show you precisely which business requirements are supported by which pieces of software and what business value is being provided. The current plan is to add the remaining 15 business events to the second version of the software when the funding is approved.”

CLIENT:
"The plan shows 50 business events for $50,000. I'll pay you $35,000 now and pay you the remaining $15,000 when you've completed the remaining 15 business events."

The underlying assumption with all Agile-like methods of work is that the client understands and accepts that software is impossible to predict. I have simply not worked with these clients yet nor have I had any luck converting clients to that way of thinking...

Thanks for the article, very thought-provoking...

--Brad Einarsen

» login or register to post comments

Yes - incremental payments....

Submitted by sammyc on Tue, 2007-03-27 22:36. *

You are correct - the ideal scenario for iterative and incremental delivery is "pay as you go"....and most companies have not figured out that a customer should pay for the delivered pieces and....get the best quality since more time is spent and fewer business events were delivered or promised. The solution provider must be prepared to deliver incrementally based on highest business value and return to the customer. It MUST be a Collaborative effort to achieve the best quality for the least amount of money....

My experience has not seen many, in fact very few, that will understand and risk this arrangement - the customer often likes to appear ignorant about what they really want when they see it and the solution provider is typically not trusted by the customer to deliver what they REALLY want! Yet the solution provider continues to bill the customer for rework that drives the project costs up - leading to sunk costs and often applications that never get deployed.

And the dance of project management continues.....

» login or register to post comments

Mis-conceptions of Agile methods

Submitted by mike.krige on Wed, 2007-03-28 01:33. *

I think you are illustrating one of the key mis-conceptions of people who do not fully understand Agile methods, and probably one of the key reasons that business people and clients are hesitant to accept working with Agile proponents. No client will ever be prepared, nor should they be, to pay for LESS than what was promised. Because you are working in an Agile method will never imply you can deliver less than what you promised and expect to get paid in full. What Agile does imply is that you may get DIFFERENT functionality at the end of the project. So if you contract to deliver 50 business events for $50,000 you will deliver 50 business events BUT they may not be the same 50 that are identified up front AND it is the CLIENT who decides during the project which 50 he wants and in what order. ALSO if you are being truly Agile the CLIENT can cancel the project after you have only delivered 25 business events and pay you half the amount because he has already got the functionality that he REALLY needs from the system. If more developers would negotiate on this basis then more clients may be prepared to work in Agile ways.

» login or register to post comments

re: Mis-conceptions of Agile methods

Submitted by einarsen on Wed, 2007-03-28 08:01. *

Mike,

You are spot-on, that was my misunderstanding.

Now I understand how to sell this... We sell it as putting the client in the change control seat and tell them that they can change anything they want, any time before it's built. We (the technical firm) act as advisors to try and shepherd them through the process so they don't make a silly decision, but if they decide that Functionality B is not required half-way through the project then that's fine, we dump Functionality B and build Functionality C.

Of course, the client has to be educated that that decision must be made BEFORE Functionality B is built... :-)

In fact, we already work in a way similar to this. We present clients with an a la carte menu of options with estimates (in my business they are really fixed-price) and the client can pick and choose.

This was very illustrative, thanks Mike!

--Brad Einarsen

» login or register to post comments

Agile breaks down, when the lawyers aren't agile!

Submitted by behret on Wed, 2007-03-28 12:46. *

Mike,

I think you brought it to the point.
I think an agile approach can solve some problems we have in the world, especially in a world of trust.

BUT: I have consulted for large companies that are challenged to integrate outsourcers, service providers, product companies. The product life cylce extends far beyond what agile methodologies consider. The contractual framework with these parties in this case dictates the process. If you have to establish a fixed price contract dictating functionality, cost and time - you need to "agree" it, trying to resolve dependecies over multiple organisations!
The cost to establish this contract is not low at all. Hence, you don't want to do this too frequently (here comes the agile lawyer!).

The world would look different if it was a time and material approach resulting in a different contractual framework allowing different processes!

So my point is simply that agile works for certain problems, ... very well. And I think we should adopt things that make a difference .. for the right problem. But I think we cannot let the agile approach redefine the problem to fit the solution.
In this case we will fail. That's lesson number one in the RE / BA camp, isn't it?

Best,
- Thomas

» login or register to post comments

No silver bullet

Submitted by mike.krige on Thu, 2007-03-29 02:03. *

Hi Thomas,

I totally agree with you that there is no ONE solution that fits all problems. I've worked long enough in IT (hate to have to admit how long) to know that there are a multitude of different problems that we are trying to solve. I have seen too many 'ultimate solutions' come and go to believe that a single Agile methodology can be applied to all problems. Agile methodologies are by implication Agile! So the process needs to be changed to fit the problem not the other way round.

The Agile Alliance and Agile Modeling community recognise this fact and hence do not recommend a single methodology to fit all problems. They rather have a set of principles and best practices that should be followed no matter what methodology you are using. So the challenge is to find the best methodology to fit the problem AND the people involved in solving the problem. In some situations you will be able to be more Agile than in others but I firmly believe all problems will be solved more effectively by following as many of the Agile principles that the situation allows.

Regards,
Mike

» login or register to post comments

Then fix the problem

Submitted by ScottWAmbler on Sun, 2007-04-01 20:01. *

Instead of just accepting that the contracts aren't ideal, that the business folks will self-impose a working strategy which may not be to the best advantage, that the lawyers/accountants/... aren't agile why don't you try to do something about it? Why not get involved with the contract setting strategy to begin with? Why not help the customer to understand that they have choices, that the fixed-price serial approach actually proves to be rather dysfunctional in practice.

Have you ever stepped back and asked why contracts are written the way that they're written? Is it because everyone involved is stupid? No. Is it because they're evil? No. It's because they don't realize they have better options. It's because they're trying to control risk the best way that they can.

In an agile environment the stakeholders have control over the scope, the budget, and the schedule. If they choose to step up to this challenge they are put in a much better position to manage risk than when they're doing fixed-bid serial with an "iron-clad" contract. As professionals I believe it's our responsibility to help business people understand the options that they have and to provide opportunities to enable them to do that.

- Scott
Scott W. Ambler
Practice Leader Agile Development, IBM
http://www-306.ibm.com/software/rational/bios/ambler.html

» login or register to post comments

How many ....

Submitted by behret on Mon, 2007-04-02 11:07. *

Thanks for your views Scott!

The number of grey hairs I have, proove the number of fights I have been engaged in... and lost. Do you walk away (the purist passionate approach) or do you try to mitigate where you started? I am not saying do not try, but I am asking what to do when in some instances you can only make it better gradually.

How many situtations did you have where you were convincing to affect the change you describe above?
My last experience: 5 companies - 5 different roles; the one person these companies bring to the first meeting together with the sponsor is not a requirements engineer (I wasn't there;-), but a lawyer.

- Thomas

» login or register to post comments

Many times

Submitted by ScottWAmbler on Mon, 2007-04-02 23:27. *

I've been able to do this many times. My "trick" is to get people talking with each other, to get all the protagonists together and discuss why they're doing what they're doing. Very often we find out that some people assume that other people need to work this way, and vice versa. Together they then choose to work the new way. Sometimes we discover that people didn't realize that they had other options. Sometimes we discover that there is such a lack of trust between the various groups that they won't choose to work together effectively (hence the presence of lawyers).

Yes, sometimes the organization is really messed up and unable to change at the current moment. Yes, I do walk away from these situations because if I can't help them then why stick around? I'd rather work for organizations where I can actually have an impact.

- Scott
Scott W. Ambler
Practice Leader Agile Development, IBM
http://www-306.ibm.com/software/rational/bios/ambler.html

» login or register to post comments

Expectations about completeness, and money, and . . .

Submitted by renglish on Mon, 2007-04-02 12:22. *

Brad, I am a BA with a permanent position so I don't have the payment problems you describe. However, stakeholders in my world often don't understand key aspects either.

You cite the follwing quote from the article:
"We have implemented software to support these 35 business events and we can show you precisely which business requirements are supported by which pieces of software and what business value is being provided. The current plan is to add the remaining 15 business events to the second version of the software when the funding is approved.”

If I said that, the response in my world would be:
"Great! So we're done then!" (In other words, forget about getting funding for the second version of the software. We're happy that something got done and we're ready to move on to the next thing we think is cool.)

This is just one example from my world, but you probably get the idea.

» login or register to post comments

User login

New forum topics

Recent blog posts

Upcoming events

Have We Finished Yet?

Comment viewing options

Expectations about completeness

Yes - incremental payments....

Mis-conceptions of Agile methods

re: Mis-conceptions of Agile methods

Agile breaks down, when the lawyers aren't agile!

No silver bullet

Then fix the problem

How many ....

Many times

Expectations about completeness, and money, and . . .

Recent Articles

Partners

Recent comments

ARCHIVE MENU

Sponsored Announcements & Special Offers