"Side Bar" WTF

Re: Speechless moments

czedryk — Tue, 06 Mar 2012 02:53:02 GMT

Yes I agree that not all procedures should be followed blindly, that there are exceptions but if management saw that a certain procedure is not achieving its goal, why let it stay?

But in our case, our procedure is working well. It's just that management is so focused in making the customers happy (sort of) by delivering softwares earlier than necessary by bypassing most of the development procedures that was implemented.

Re: Speechless moments

morbiuswilters — Mon, 05 Mar 2012 23:46:13 GMT

TheCPUWizard:
ps: 100% agreement that software *might* be done when no one is using it anymore, but not always - consider systems that have been "retired" only to find that some critical piece of data needs to be retrieved, perhaps years later - I have made some very good money during my career doing such forensics on "extinct" systems.

Too true.

Re: Speechless moments

TheCPUWizard — Mon, 05 Mar 2012 22:32:20 GMT

boomzilla:
morbiuswilters:
Also, I've never seen all of the requirements for a project being captured. That's because projects adapt over time. If a piece of software is done, it's because nobody is using it any more.
It's also very difficult (impossible in all but the most trivial cases?) to foresee all if the issues you need to in order to fully capture the requirements.

The point of Agile, is that you do not "foresee" them, as they become known, theyt get "captured". But one can not write proper code, until one knows what the code is supposed to do; therefore the requirements must be captured at some point.

ps: 100% agreement that software *might* be done when no one is using it anymore, but not always - consider systems that have been "retired" only to find that some critical piece of data needs to be retrieved, perhaps years later - I have made some very good money during my career doing such forensics on "extinct" systems.

Re: Speechless moments

Cassidy — Mon, 05 Mar 2012 21:56:23 GMT

morbiuswilters:
That doesn't mean agile is always done correctly...
Additionally, requirements evolve over time which is why it's important to get prototypes into user hands ASAP and then refine from there.

TheCPUWizard:
Correctly done, Agile does indeed capture all of the requirements. The primary difference being that they are captured "just in time" rather than at the begining of the project.

I think you've just agreed with Morbs there. Didn't know that part about "when" they're captured, though - I just took it as read that the requirements were treated as being fluid.

boomzilla:
It's also very difficult (impossible in all but the most trivial cases?) to foresee all if the issues you need to in order to fully capture the requirements.

This was cited as a major drawback of waterfall (as well as the concept that reqs would never change throughout the project lifecycle) and spawned Agile, wasn't it?

Re: Speechless moments

boomzilla — Mon, 05 Mar 2012 20:56:57 GMT

morbiuswilters:
Also, I've never seen all of the requirements for a project being captured. That's because projects adapt over time. If a piece of software is done, it's because nobody is using it any more.

It's also very difficult (impossible in all but the most trivial cases?) to foresee all if the issues you need to in order to fully capture the requirements.

Re: Speechless moments

morbiuswilters — Mon, 05 Mar 2012 20:48:58 GMT

TheCPUWizard:
Correctly done, Agile does indeed capture all of the requirements.

Where did I imply otherwise? Also, I've never seen all of the requirements for a project being captured. That's because projects adapt over time. If a piece of software is done, it's because nobody is using it any more.

TheCPUWizard:
If the capture triggers "rework" (not refinement) of something that could have been avoided by earlier capture, then the capture was too late.

Wouldn't refactoring be rework? Refactoring is an integral part of agile. Also, you seem to still be of the impression that requirements don't change. All you're suggesting is capturing them on-the-fly rather than up-front; you still believe them to be static. Requirements change all of the time. A requirement triggering rework wasn't necessarily "captured late", it didn't even exist previously.

Re: Speechless moments

TheCPUWizard — Mon, 05 Mar 2012 19:52:01 GMT

morbiuswilters:
Cassidy:
DaarkWing:
That is why more Agile programming models have propagated in the last 10-20 years relying on less defined requirements and more on team interaction.

I thought Agile was more about embracing change throughout the project lifecycle, rather than be a stickler for the original specs and thus deliver what the customer wanted then, rather than what the customer needs now - which suits the fast pace of IT-based projects (are you listening, 3D Realms?) Isn't there also something about the customer using prototypes early so reaping earier returns whilst continuing to refining it (spiral evolution?)
You are correct. That doesn't mean agile is always done correctly, but the idea is that hard-coded requirements often create an inferior product, outside of a few industries (medical, nuclear, warfare..) Users rarely know what they want up-front and specifying detailed requirements in-depth results in wasted time and incorrect requirements. Additionally, requirements evolve over time which is why it's important to get prototypes into user hands ASAP and then refine from there.

Correctly done, Agile does indeed capture all of the requirements. The primary difference being that they are captured "just in time" rather than at the begining of the project. The secondary difference is how they are captured. In most cases, it is by interacting with Iteration "n" that the requirements for Iteration "n+1" are finalized.

A good rule of thumb, is that if "a requirement is captured" and then no specific action is taken on the requirement for a significant period of time (typically days), then the capture was too early. If the capture triggers "rework" (not refinement) of something that could have been avoided by earlier capture, then the capture was too late.

Re: Speechless moments

morbiuswilters — Mon, 05 Mar 2012 19:35:23 GMT

Cassidy:
DaarkWing:
That is why more Agile programming models have propagated in the last 10-20 years relying on less defined requirements and more on team interaction.

I thought Agile was more about embracing change throughout the project lifecycle, rather than be a stickler for the original specs and thus deliver what the customer wanted then, rather than what the customer needs now - which suits the fast pace of IT-based projects (are you listening, 3D Realms?) Isn't there also something about the customer using prototypes early so reaping earier returns whilst continuing to refining it (spiral evolution?)

You are correct. That doesn't mean agile is always done correctly, but the idea is that hard-coded requirements often create an inferior product, outside of a few industries (medical, nuclear, warfare..) Users rarely know what they want up-front and specifying detailed requirements in-depth results in wasted time and incorrect requirements. Additionally, requirements evolve over time which is why it's important to get prototypes into user hands ASAP and then refine from there.

Re: Speechless moments

Cassidy — Mon, 05 Mar 2012 17:43:07 GMT

TheCPUWizard:
While there are sematic issues with the above, I believe it to be quite accurate (especially if one replaces "requirements" with "objectives" as other have for easy of reading)

DaarkWing:
In general, a requirement needs to have the following attributes:

Ohhh.. I like those. SMART++ ...?

DaarkWing:
That is why more Agile programming models have propagated in the last 10-20 years relying on less defined requirements and more on team interaction.

I thought Agile was more about embracing change throughout the project lifecycle, rather than be a stickler for the original specs and thus deliver what the customer wanted then, rather than what the customer needs now - which suits the fast pace of IT-based projects (are you listening, 3D Realms?) Isn't there also something about the customer using prototypes early so reaping earier returns whilst continuing to refining it (spiral evolution?)

Re: Speechless moments

DaarkWing — Mon, 05 Mar 2012 14:14:24 GMT

From a SQA perspective, all requirements need to be testable. In general, a requirement needs to have the following attributes:

Correct (Does it satisfies input documents and applicable regulations, standards, etc?)
Consistent (Does is use standard language within doc and with input document? Does it conflict with another req?)
Complete (Do all the requirements define the system as a whole?)
Accurate (Do the calculations and interfaces statisy the input documents accuracy requirements?)
Unambiguous (Is the requirement unique within the document and only have one interpretation?)
Testable (Does there exist some cost-effective process to confirm the product meets the requirement?)
Traceable (Both backward to input documents and foward via a unique reference?)

Customer requirements whether they come from use cases or user requiements specs, need to follow these rules. (Though I truely understand how difficult that is). Other posters have touched on the reason. If your contract is based on the user requirements, then the less fudge factor in them means more contractual arguments and more rework by the programmers without additional funds from change orders.

In an ideal world, the user requirements would be the bid document and the programmers would provide a (functional/requirement/insert term here) spec to state what they will do to meet those user requirements. When the programmers are rewarded the contract, it is this spec which is the contractual document. This usually makes it easier to control costs and features.

There are many industries that require this control: pharmaceutical, medical device, nuclear, aerospace, financial, etc. However most don't get this lucky even within these industries. That is why more Agile programming models have propagated in the last 10-20 years relying on less defined requirements and more on team interaction.

Re: Speechless moments

boomzilla — Mon, 05 Mar 2012 13:58:11 GMT

erikal:

Cassidy:
"why didn't you use your initiative?"
"nobody told me to..."

Dangerous one that. The same people that demand initiative tend to let the whip lash when people show initiative "because they should have discussed about it first". Initiative really only exists outside of working hours, doing things on your own dime. IMO of course, or should I say "in my experience".

I would have thought "using your initiative" meant bringing up these new ideas for improvement for discussion, not a cowboy implementation behind the team's and the customer's back. Of course, every situation is different, but there's nothing you said that's really incompatible with showing initiative in general.

Re: Speechless moments

erikal — Mon, 05 Mar 2012 13:34:57 GMT

Cassidy:
"why didn't you use your initiative?"
"nobody told me to..."

Dangerous one that. The same people that demand initiative tend to let the whip lash when people show initiative "because they should have discussed about it first". Initiative really only exists outside of working hours, doing things on your own dime. IMO of course, or should I say "in my experience".

Re: Speechless moments

Cassidy — Mon, 05 Mar 2012 08:38:13 GMT

TheCPUWizard:
czedryk:
Our senior executives once told us that 'Procedures should not always be followed'... WTF!!!
Blindly/Always following proceedures is the real WTF. There will inevitably be cases where the proceedure is not appropritate, and the correct action is to either modify the procedure (so that the new proceedure can be followed) or obtain an official waiver of the proceedure.

That. Procedures refactor the majority of situations, modelling expected output for usual input... but there are exceptions.

The process docs should have some guidance to when the process doesn't apply, or when deviations require additional management engagement.

"why didn't you use your initiative?"

"nobody told me to..."

Re: Speechless moments

TheCPUWizard — Mon, 05 Mar 2012 05:50:48 GMT

czedryk:
Our senior executives once told us that 'Procedures should not always be followed'... WTF!!!

Blindly/Always following proceedures is the real WTF. There will inevitably be cases where the proceedure is not appropritate, and the correct action is to either modify the procedure (so that the new proceedure can be followed) or obtain an official waiver of the proceedure.

Re: Speechless moments

czedryk — Mon, 05 Mar 2012 05:04:25 GMT

Our senior executives once told us that 'Procedures should not always be followed'... WTF!!!