N.B. This is an early draft of something I am currently writing. Please feel to comment and give feedback. The full ebook will be published in the next few weeks and I will follow with another blog so you can download it if interested.

How you can implement processes to improve quality, reduce stress and lower costs

Introduction

A lot of application development teams, and to a lesser extent operational IT teams, have either no or limited process. They depend on a combination of individual expertise, informal conventions and team habits (some good and some bad); and being prepared to put with all the problems of poor quality and unpredictability. It does not have to be like that and this ebook presents some 'low hanging fruit' you can pick to make your teams more productive – the approach is simple and practical. This document is written for smaller teams who spend their time doing a combination of maintenance and new feature requests on an existing application. This actually covers the majority of software teams because, much as we all want to work on green-field projects and deliver Rel 1.0, most of our work is done on existing systems. This ebook lists seven keys process areas (PA) that you need to think about: Metrics, Planning, Release, Testing, Issue1 management, Version control and Communication. These represent broad headings across the Software Lifecycle than contain the low hanging fruit we can pick early and I chose them because we can (almost) focus in each PA individually. After some initial informal success teams can look to expand their improvement initiatives and use more formal and complex methods – which is beyond what can be covered in this short document. The resources section lists places that you should look for more information and different perspectives. There is no magic to software process improvement – it's a question of: common sense; team and personal discipline; patience; attention to detail; and a strong desire by everyone to improve the current situation. Also what works will require you to experiment and use judgement (obtained by experience) to decide what will work in your projects. There is no 'one size fits all'. Agile Processes : The tools and techniques presented here are written primarily for the benefit of more traditional teams. If you call yourself an agile team, but have no process then I recommend you engage a reputable agile coach; or take a step back into more traditional software lifecycle, improve your processes (using this ebook and other resources) and then step forward again.
1Issues in this context is a very broad term that covers requests for new features, bug reports, internal development tasks and questions