One of the hardest parts of my role is getting projects started, and it sometimes feels exacerbated by poor attempts to use Agile mindsets.
The fact is that a project needs a reasonably clear set of targets and plans in order to start successfully, with a defined order and a some idea of timelines. This is especially important where multiple applications and owners are involved and need to coordinate their work.
From an Agile viewpoint, I’m quite happy to adjust the plans based on experience and refine the details as the project progresses. The one thing I believe very strongly though is that you must start at the beginning.
Of course your beginning depends on your methodology, you can pick requirements, epics, acceptance criteria, data, test cases, etc etc. It doesn’t really matter, although I suspect it helps if each application area chooses the same option (I’ve never done a mixed methodology project of any size, I’d be interested to hear what happens if you run requirements driven and test driven parts in one project).
In several recent projects I’ve found that people are diving right in to the middle of the analysis, with no agreement on useful things like goals, ownership or basic timescales. The culprits are often recent Agile adopters who haven’t done anything big yet outside waterfall, and just throw away all the planning steps and hope they can adjust later.
The problem is that the analysis never seems to finish – how can it with no definition of done… Instead, people jump from one analysis task to the next and we end up with a load of 80% complete parts that don’t add up to anything useful.
I believe Agile planning and analysis can be done successfully, but as with anything in software development you need to follow some basic rules which I would suggest are:
- Prioritise – some analysis has a fundamental impact on the project, some is detail or tweaking. Do the big stuff first, or you end up throwing away a lot of work from options later dropped.
- Have a definition of done. Nothing is ever analysed 100%, nor should it be. Define how much certainty is needed, and make sure it is sensible and consistent across all tasks.
- Write it down and Sign it off. Do it Agile if you can (stories in Jira, great), but make sure everyone is doing the same project!
- Timebox and Review. Make sure you are getting somewhere and doing so efficiently, using sprints and retrospectives or something similar.
Of course it isn’t easy to influence this in big projects where no one person is fully responsible, but I have found that by pushing these principles you can move things in the right direction. Retrospectives are particularly powerful in this regard if you can get good open participation.