We should probably chat. Not least around what "agile development" actually *is*.
Q1: Other than buzzword implementation, what does the company / business unit / team hope to accomplish with the change?
Therefore, Q2: What business processes is it aiming to change? How? With what effect on the business unit's (presumably internal) customers?
Therefore, Q3: What definition of "agile development" best fits? Or doesn't it actually fit at all?
All forms of development take the 3 corners of scope, time and staff/budget (I add a fourth: quality). Each of these corners is given to a stakeholder; the implementation team must hold at least one (if scope, time and budget are all fixed they grab the "quality" corner ;-) ). Conventional development hands scope and time to the customer; the IT team works out a budget and implements to that budget. Agile development hands budget and time to the customer; the IT team does as much of the scope as it can with the available resources.
We frequently do agile development for our customers - "do as much as you can for this much money" is surprisingly common. The biggest barrier has been when we say "... and we'll need frequent access to your stakeholders so that we can present what we've done so far, get feedback and prioritise the next bit." The usual response is "... so this development will take some of my key staff time? I thought I'd just be able to hand it over to you! Can't you do it some other way???" Presumably getting an application that actually does what the client wants is secondary.
Q1: Other than buzzword implementation, what does the company / business unit / team hope to accomplish with the change?
Therefore, Q2: What business processes is it aiming to change? How? With what effect on the business unit's (presumably internal) customers?
Therefore, Q3: What definition of "agile development" best fits? Or doesn't it actually fit at all?
All forms of development take the 3 corners of scope, time and staff/budget (I add a fourth: quality). Each of these corners is given to a stakeholder; the implementation team must hold at least one (if scope, time and budget are all fixed they grab the "quality" corner ;-) ). Conventional development hands scope and time to the customer; the IT team works out a budget and implements to that budget. Agile development hands budget and time to the customer; the IT team does as much of the scope as it can with the available resources.
We frequently do agile development for our customers - "do as much as you can for this much money" is surprisingly common. The biggest barrier has been when we say "... and we'll need frequent access to your stakeholders so that we can present what we've done so far, get feedback and prioritise the next bit." The usual response is "... so this development will take some of my key staff time? I thought I'd just be able to hand it over to you! Can't you do it some other way???" Presumably getting an application that actually does what the client wants is secondary.
Reply
Leave a comment