I rambled a little while ago how Geospatial and agile just do not seem to match. I have actually checked agile projects I've worked on and wanted to list some findings (relevant for Geospatial parts of projects)
1) if customer knows even some of their user requirements, agile might not ba a go
2) typical project cost for agile can be as much as 3 times more than waterfall
3) typical project duration can be as much as 1.5 times times waterfall project
4) customer representation in project gets exactly what they want, but end user will get something quite different than what they asked for
5) no low priority tasks will be done
6) data model, architecture and development middles include a lot of workarounds and irrelevant (bloated) code
So that sounds pretty bad, but usually the application itself for users is very easy to use and often customer is satisfied enough. It just buggers me as things could be so much better, cost-effective neat.
So is there a way to do agile with Geospatial? Yes, it is not perfect, but it certainly is plausible. Here are some suggestions on how to do Geospatial modules in agile way:
1) start with a prototype or pilot for mapping interfaces and data. This enables the whole team to get their heads around what we are trying to achieve and some insight in layers, views and functionality
2) create a "want" list of data layers, priorities these and decide layering order. Also think on relationships between layers. Note that data definitions and model are not needed at this stage
3) go through a tick list of functionality groups your app might need - every Geospatial app has a finite number of functions in use and most of these are same across industries
4) create a backlog of al layers, views and functionality that you know you need, you suspect you need and that you might want
5) use that backlog to power your sprints - design for example should look at the whole backlog as this way we reduce rework
One last thing- rework is the biggest issue with Geospatial and agile. The problem is that in Geospatial everything adfects everything else; adding a layer at the time changes all functionality - even the ones you did not expect.
1) if customer knows even some of their user requirements, agile might not ba a go
2) typical project cost for agile can be as much as 3 times more than waterfall
3) typical project duration can be as much as 1.5 times times waterfall project
4) customer representation in project gets exactly what they want, but end user will get something quite different than what they asked for
5) no low priority tasks will be done
6) data model, architecture and development middles include a lot of workarounds and irrelevant (bloated) code
So that sounds pretty bad, but usually the application itself for users is very easy to use and often customer is satisfied enough. It just buggers me as things could be so much better, cost-effective neat.
So is there a way to do agile with Geospatial? Yes, it is not perfect, but it certainly is plausible. Here are some suggestions on how to do Geospatial modules in agile way:
1) start with a prototype or pilot for mapping interfaces and data. This enables the whole team to get their heads around what we are trying to achieve and some insight in layers, views and functionality
2) create a "want" list of data layers, priorities these and decide layering order. Also think on relationships between layers. Note that data definitions and model are not needed at this stage
3) go through a tick list of functionality groups your app might need - every Geospatial app has a finite number of functions in use and most of these are same across industries
4) create a backlog of al layers, views and functionality that you know you need, you suspect you need and that you might want
5) use that backlog to power your sprints - design for example should look at the whole backlog as this way we reduce rework
One last thing- rework is the biggest issue with Geospatial and agile. The problem is that in Geospatial everything adfects everything else; adding a layer at the time changes all functionality - even the ones you did not expect.