There’s one very simple rule that works not just for software engineering but for the way people think and act:
If you want to be able to do something successfuly – do it frequently.
It relates to both complex tasks and tasks that you think are simple. Based on our experience for software development process, this boils down to following tips:
- Build and deploy interim versions of your product as frequently as you can. Do it at least once per day.
- Demonstrate new builds (“demonstrate” doesn’t mean “release”) to your customers and to the end-users. Demonstrate builds every week to the customer and arrange for demoing it to selected end-user at least once per every two-three weeks.
- Illustrate your questions, comments, ideas using current build making your product a “communication platform”. Do the same with each software developer in the team. “Here, take a look at my monitor…” or “let’s run a WebEx session” should become neccessary daily practice.
- Release software frequently and perform necessary software testing. New features always complicate configurations and maintenance process, so be ready. Release every 4-8 weeks.
- Measure system performance every software development iteration (1-2 weeks) and take actions when improvement needed.
- Look for potential technological improvements and consider options every iteration. See if you can esily migrate to a better Ajax framework or switch to different indexing model in your DB or improve your algorithms or else… this keeps the team up to innovations and really improves the product during the entire product lifecycle.
- Business people meet up with engineering team as frequently as possible, product management, product marketing and engineering teams synchronize as much as possible.
- Develop a habit of talking to other software development teams, consultants, business people, even a software programmer or a software developer. If you did find a better Ajax framework, share it with others and they will share their view with you what a good new distributed version control system they now use. Constantly give and receive back.
One may say there’s considerable intersection with agile methodology. Indeed this is true for some of them. On the other other hand to avoid typical illusion, like that the team becomes agile as soon as it calls themselves an “agile team”, I just wanted to emphasize very simple but useful idea or making risk-eliminating tasks a habit for the team.