2 ms·

This is extremely common in corporate software engineering, where a contract specifies exactly what will be delivered. In practice, those change requests are u

by smackfu 14y ago

This is extremely common in corporate software engineering, where a contract specifies exactly what will be delivered. In practice, those change requests are usually rejected, because the people with control of the money aren't the people using the product, and the customer ends up paying for something they aren't happy with. A lot of Agile methodologies are a response to this extremely strict change control.

mindcrime 14y ago
A lot of Agile methodologies are a response to this extremely strict change control. The problem, from what I've seen, is that developers understand agile development, but the "money people" don't. To them, "agile" is just a buzzword that means "good" and they aren't actually interested in participating in the process. So now you get people who don't understand, or aren't interested in, attending demo sessions, prioritizing the backlog, or reading/writing user stories. And when things don't proceed along a nice, smooth, water-fall like sequence, they get stressed and start complaining. One place I'd say the Agile movement has fallen on it's sword, is in terms of promotion, education and buy-in from the "business community" to the point that they understand that Agile processes require their active participation.
- PeterisP 14y ago
  If you want to do Agile development, then you also have to do Agile billing - i.e., not a pre-agreed price limit for "thingamajig that does X, Y and Z", but in essence renting the team for each sprint with an understanding of what you'll get in each development (and billing) cycle.
Silhouette 14y ago
A lot of Agile methodologies are a response to this extremely strict change control. Which is useful in some contexts, but also why Agile isn't taken seriously in others. The most popular Agile methodologies (if that isn't itself an oxymoron...) are fundamentally incompatible with processes and practices that can be useful in real projects, particularly very large projects where there are many participants to co-ordinate and many stakeholders with an interest in the results but not necessarily the same interest. At some point, a more formal process is the only way you can get anything useful done, and that includes a sensible but controlled process for handling changing requirements.

by smackfu 14y ago

mindcrime 14y ago

A lot of Agile methodologies are a response to this extremely strict change control. The problem, from what I've seen, is that developers understand agile development, but the "money people" don't. To them, "agile" is just a buzzword that means "good" and they aren't actually interested in participating in the process. So now you get people who don't understand, or aren't interested in, attending demo sessions, prioritizing the backlog, or reading/writing user stories. And when things don't proceed along a nice, smooth, water-fall like sequence, they get stressed and start complaining. One place I'd say the Agile movement has fallen on it's sword, is in terms of promotion, education and buy-in from the "business community" to the point that they understand that Agile processes require their active participation.

PeterisP 14y ago
If you want to do Agile development, then you also have to do Agile billing - i.e., not a pre-agreed price limit for "thingamajig that does X, Y and Z", but in essence renting the team for each sprint with an understanding of what you'll get in each development (and billing) cycle.

Silhouette 14y ago

A lot of Agile methodologies are a response to this extremely strict change control. Which is useful in some contexts, but also why Agile isn't taken seriously in others. The most popular Agile methodologies (if that isn't itself an oxymoron...) are fundamentally incompatible with processes and practices that can be useful in real projects, particularly very large projects where there are many participants to co-ordinate and many stakeholders with an interest in the results but not necessarily the same interest. At some point, a more formal process is the only way you can get anything useful done, and that includes a sensible but controlled process for handling changing requirements.