Yesterday I wrote about the five signs you might see if you’re practicing mini-waterfall when you think you’re agile.
In retrospect, that list seemed rather glum, so here’s five possible remedies to a mini-waterfall problem:
- Break user stories down into the smallest possible deliverable thing: if a story takes the whole iteration to develop then it’s too big; break it down. I’ve written previously on here about the importance of breaking things down.
- Embed a product owner in your team: that way stories won’t become blocked waiting signoff because the product owner is around to make the decision and unblock them. If you really can’t have a product owner embedded in your team, at least have an empowered proxy who can unblock requirements.
- Bring forward pain points that will take time at the end of the project: if promoting to prod is painful, try releasing to pre-prod each week. If UAT is going to take 4 weeks at the end of your project, do it once a day every fortnight to get earlier feedback. By the time you get towards the end your users will be some familiar with it they’ll be much more comfortable taking less time.
- Empower team members to change the agile process as they seem fit: they need to be responsible for their actions and be flexible to change again if needed, but don’t let your team members live in fear of change or retaliation.
- Release often: this will most probably be the hardest one to change as it’ll encounter the most resistance. You can start in small steps. For example, you could agree to release your application services/database more frequently than your user interface to see how it handles in production. Or you could release new functionality with a feature switch so that it’s disabled in production to rehearse and refine the release process. There’s no point in delivering working software every iteration if you’re only ever going to release it once or twice a year.