Silver bullet for improving development process

What can be done to improve current development process? Should one try to find answers from organizations like SEI or ISO or from some good books ? I believe that both are important sources but the most critical element is something else - actual experience with actual projects and preferably with actual people.

What I mean by experience is not some itchy feeling in the back of your head but concrete and explicit knowledge. The only way to get this kind of knowledge is by reflection - that is by taking few steps back and analyzing things. What can be improved, what went well, what happened etc - these questions should be asked on regular basis. Many agile processes suggest to have this activity after every iteration. I don't know how much people are currently doing this already but I think there is quite much room for improvement.

For example we could start writing these kinds of retrospectives for all projects and publish these inside the company so that others from other projects can also learn. It's human to repeat the mistakes of oneself not to mention the mistakes done by others but at least it would be interesting reading

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Comments (3)

 

  1. May 29, 2006

    Risto Alas says:

    I also have a small feeling that retrospectives might help, because most of the ...

    I also have a small feeling that retrospectives might help, because most of the time people don't seem to take the time to think about how to improve (non-obvious) things. And Martin Fowler also likes them (http://martinfowler.com/bliki/ThoughtWorksUK.html). However, I'm not exactly sure about how to do them in practice (how formal/informal to make them, how short, etc), and I have other priorities also.

    One more thing: it is also possible to trust your own experience too much (for example, people have tried TDD and found that it did not work, when in fact they simply did it wrong).

  2. May 29, 2006

    ahti says:

    How TQM (TotalQualityManagement) works is that they keep the goal "zero deffects...

    How TQM (TotalQualityManagement) works is that they keep the goal "zero deffects". This is done by trying to prevent problems instead of fixing. This means constant evaluation and improvements. TQM might drive crazy those who would like to just do his job well and not think outside of box how to improve development in overall.

    Implementing zero-deffect innovation takes a lot of resources and thereby ROI (return-of-investment) timeframe becomes pretty big.

    Otherwise a neat idea

    In practice, applying TQM takes usually 2-3 years to implement (not just software industry).

    Back to basics: it all starts with cvs commit message validation and modifications, code test coverage, formally defined workflows, common set of build scripts, easily pluggable nightly builds etc.

    And ideas for improvements like this start from practice and real-life projects.

    Reiterating Ürgo's post: we can "zero-deffectize" our development-life by improving it step-by-step: storing all our ideas for possible improvements in process and implement them according to feasibility and priority

    And yes, for this we don't need big processes upfront. Big process-planning is meant for organized prioritization for this kind of improvements. IMHO

    Remaining issue for me is how to be sure that a certain practice (i.e. TDD) is contributing enough to the prioritized goal?

  3. Jun 05, 2006

    Ürgo Ringo says:

    Thanks again for excellent comments! I must say that this TQM sounded a bit sus...

    Thanks again for excellent comments!

    I must say that this TQM sounded a bit suspicious to me first but now after having done light research on it I dare to say that maybe it's not that bad thing after all . Still Ahti maybe you could write a small introduction about TQM or point out some good source where to get an overview (I wasn't able to find anything too good myself).

    I agree also that we should go step-by-step and retrospectives are just one good way how to get feedback on each step.

    I think that there could be two types of retrospectives. The goal of the first ones would be to improve the process of ongoing project. These should be done more frequently possibly after every iteration. The second ones would differ both in scope and in frequency. These would be done at the end of a project and would look back on entire project trying to identify lessons learned that could be applied to other projects.

    Now about ROI. I don't think these retrospectives cost too much. Actually I see them as time savers as this kind of reflection can avoid doing same mistakes again and again. They don't need to be too formal. If having written artifact at the end of each iteration seems too heavy at first then we can start doing them only on some projects and maybe after every 2-3 iterations. However I strongly believe that the retrospective done at the end of a project should be a must.