Cargo Cult Agile (2008)

Post by flukus » Thu, Apr 13, 2017, 2:53 AM UTC

UK-AL wrote: post #51

flukus wrote: post #23

Earlier quoted context omitted.

> their estimate for a very minor change added up to several months... It sounds like they had an issue with technical debt (and that had led to a lack of trust from the rest of the company) and thought they could fix it with a process, correct? I don't think you can help someone that won't recognise the root cause.

The reason for technical debt is the process. If you have a very waterfall like process like at a lot of large companies, everything has to go through change control. Every change has to have business case, and becomes very bureaucratic. As a result no one proposes any changes to fix technical debt. You can do it under the radar by attaching it to existing tasks, but these companies tend to be so project manager driv…

I really don't think the process is responsible for technical debt. If anything waterfall is better because you can do larger scale refactorings. But at the end of the day, time needs to be assigned to address that debt and no process will give you that time.

Post by UK-AL » Thu, Apr 13, 2017, 11:09 AM UTC

flukus wrote: post #111

UK-AL wrote: post #51

Earlier quoted context omitted.

The reason for technical debt is the process. If you have a very waterfall like process like at a lot of large companies, everything has to go through change control. Every change has to have business case, and becomes very bureaucratic. As a result no one proposes any changes to fix technical debt. You can do it under the radar by attaching it to existing tasks, but these companies tend to be so project manager driv…

I really don't think the process is responsible for technical debt. If anything waterfall is better because you can do larger scale refactorings. But at the end of the day, time needs to be assigned to address that debt and no process will give you that time.

Well agile techniques recommend you don't fix scope, and budget at the same time. Allowing you to go back fix your code that has turned out to be wrong. You're allowed to learn and to adjust your plan as you go a long.

Waterfall people have to meet a deadline and a defined scope, so when being told that you have to refactor some code, the response is to ignore it to meet the deadline. In order to meet deadlines and a defined scope the plan MUST NOT change, otherwise the deadline or scope has to be changed as well.

That is until you reach the deadline and find it doesn't work the way the customer wanted anyway because you refused to change the plan.

For agile techniques the measure of progress is working software, not meeting set deadline and scope.

Re: Cargo Cult Agile (2008)

Re: Cargo Cult Agile (2008)