What single aspect of agile development should we implement first to improve our development process, and why?
I’m in a situation that’s requiring me to ‘tweak’ my process, rather than re-engineer it, and ‘agile’ seems to be the mantra of the day. If we can make only one change that will improve something–quality, time to market, documentation, transparency, etc., what will have the most visible, positive impact?
If we choose correctly, we’ll be able to make a second choice. 🙂
Update: What is your current SDLC?
Environment: essentially ‘restartup.’ A small handful of developers; legacy products with 10^5-10^6 LOC and tens of thousands deployed worldwide; products are strongly interdependent; significant features added over the years, including many one-offs, w/o refactoring; tight schedules; superficial QA; no post-mortems or ‘process guru.’
Typical process:
- Create design/spec. Review by all stakeholders.
- Code one or more features/fixes.
- Revise design/spec to account for surprises.
- Test features, record defects.
- Prioritize new and remaining tasks.
- Revise design/spec/schedule.
- Return to Step 2 as necessary.
- Release for beta, record feedback.
- Return to Step 2 as necessary.
- Official release.
Thanks for so many helpful suggestions and insights!
Related Questions
No related questions found
I’m a big fan of mix-and-match, and an incremental change of the development process. I agree that iterative development should be your first goal, but I think you can approach it in even smaller steps.
From my experience, I would recommend the following order – pick the first you don’t do already:
Fix Bugs First. I wish I wouldn’t have to say that. This is the call of sanity, and also required to have shorter cycles.
Small steps. Train the habit of implementing the smallest change that is a visible step towards the next feature, then compile and test. Break down all your tasks into <1h units before starting to code. Aim for buildable, functional code at least every 15 minutes. This doesn’t require much infrastructure change – except maybe fixing the incremental build and having fast machines.
Yes! Start with making sure developers have fast machines. How much better advise could get?!
Build Everything Daily. Set up a double-click full builds from Source Control to installation medium, ideally on a separate PC. This are the first step to the frequent builds, but they help a lot on their own already. For us, it was a crucial step in getting reliable, reproducable build results.
Start writing Unit Tests. Don’t bother about coverage yet, don’t enforce ‘write tests first’, but put the framework in place. Write tests for new code and changes. Then run them with your daily builds.
Short Cycles. Now it’s the time, you have all tools in place to make weekly or two-weekly in house releases: The codebase is in a deliverable state many times a day, making the build is a double-click away, and at least something is working.