Software Process Improvement - Critical Chracterstics

When you start work on improving your software development methodology, you feel that you need some framework or process to carry that task. Here I will try to put some guidelines about getting that exercise done.

Let's take a scenario; your assignment is to develop and deliver a development methodology framework for your client (or your team).

Your assignment should be,

1. Focused and Result oriented i.e. You want to see the results and are not trying to fill the file folders with heaps of good looking documents and diagrams. You know your objectives well.

2. Iterative process with milestones: You have a plan in place. You understand that you can not achieve all in one go and you have to make the improvements in multiple iterations.

3. High level of development team participation: You are not working alone in isolation. You are expected to incorporate the development team's feedback into your work as they are the real people who feel the pain.

4. Only necessary process documents and less garbage: Again, you have to be very critical of the documents that you suggest to be developed as part of the development process. First, only necessary documents, second, the documents should be precise and to the point. Prefer tables, charts over lengthy paragraphs to communicate the information.

5. Adopting best practices, only if applicable: No silver bullet syndrome. Best practices might not be appropriate for your environment no matter how 'hot' they are in technology world. Adopt them if you see that they will deliver the results, otherwise don't waste time.

6. Living documents: This is very important. Your process and practices will not always remain the same so should be the process documents. The process documents should reflect the current picture of the development environment. Ideally (yes ideally!), whatever written in the docs is what we practice.

7. Pilot implementation of newly developed methodology: Pilot implementation should be the part of the methodology development process. A pilot implementation would offer you a chance to test your recommended processes and practices. It will verify how practical those recommendations are in real world. Also it would help the developers in adopting the processes as they will have an end to end process sample to follow.

9. Communication Plan: Communicating the newly developed processes should be the part of the process improvement exercise.


Next time I will discuss specific steps that you can take to come up with some practical development methodology and framework.

Development is one thing, publishing is another

You may fail a methodology if you fail to publish it.

Success of some newly developed or adopted development methodology largely depends on how successfully it is communicated to the development team. For example, creating heavy documents and putting them on some network folders won't guarantee that the methodology would be followed and understood well by the development team.

There are few techniques,

-Publish the methodology on some local portal/intranet. The data should be highly visible, linked and searchable by the team. Preferably the information should be published in html format rather than in the word docs.

-Run training sessions for newly hired developers

-Prepare summary documents that could stick on the developer desks for quick lookup (like coding standards, process flows etc)

A lovely scenario
" a newly hired developer starts working on software design and need to know how to prepare design specifications document?, knowing a simple link http://ourportal/DevMethodolgoy, clicks there, opens the page, types in the search box 'design specifications', the result pages displays the design process with detailed guidelines about the activities, process flows, templates, roles and responsibilities, sample documents and archive of previously developed design documents. In few minutes the developer knows exactly what needs to be done and how"

Fix the basics first

A number of times when people start taking about developing or adopting some software development methodology, they start thinking about something new, unique, different that would help them in overcoming all the problems they face with their existing (or non-existing) methodology.
It is true that software industry is is continuously evolving and we are finding new ways to come closer to our dream of having a flexible, reliable, stable, secured, low cost, user-friendly, rapidly developed with a low-profile team and delivered on-time software as per client expectations (still a dream, isn't it?) but what is not true is that some methodology would make it happen in one go.
The key lesson is that if we only start doing the basic things right then it itself would resolve a number of problems we face in our environment.

So for some chaotic environment, the first step in creating a development methodlogy is to incorporate the practices you already follow but they are not delivering the results. Identify the causes of their failure and try to fix them in the new methodology. The new methodology might not look like a superb shiny silver bullet but if it starts working then this is all you need at this time. Later on you then can go to improve it further by adopting some more advanced methodology or techniques. Make it an iterative process! just like developing a software iteratively.