When you develop a software product lot’s of adverse things may happen during development: product idea may fail, idea is good but the feature set isn’t right, features good but software’s too buggy or not delivered at all, software’s delivered but performance is not sufficient to handle even easy user load or configuration management ain’t appropriate and you lose user data or system badly crashes but you inquire about that from TechCrunch…
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 product development 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 among developers 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. New features allways conplicate configurations and maintenance process, so be ready. Release every 4-8 weeks.
• Measure system performance every 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 it’s entire 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 habbit of talking to other development teams, consultants, business people. If you did find a better Ajax framework, share it with others and they will share their with you what a good new distributed version control system they now use. Constantly give and recieve back.
One may say there’s considerable intersection with agile techniques. 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 habbit for the team.
