What to do with the best practices?

Have you ever tried to google for “software best practices”? I’ve just did before writing this short post and I’ve got “Results 1 - 10 of about 88,800,000 for software best practices”. Incredible, isn’t it?

We are bombarded with best practices, organized in methodologies, process models, bodies of knowledge, etc. Should we want to get better at development, which one to consider? Very difficult to say.

Let’s pick CMMI-DEV, the process model developed by the Software Engineering Institute (http://www.sei.cmu.edu/). The best practices are called specific and generic practices, grouped at first level by specific and generic goals, and finally organized in 22 process areas assigned to five maturity levels. For more information please consult the model itself at http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html.

All is nice and fit, but there are over 300 practices. And we want to implement them all, as we like the idea to get the benefits as shown by the SEI statistics. And why not, to prove we have a certain maturity level.

Over 300 you say? Well, first reason to give up. But stop! … We recognize most of them. We have them implemented already. Or at least that’s the first impression.

We decide to do a Gap Analysis, or alternatively a SCAMPI C (Standard CMMI Appraisal Method for Process Improvement). For the challenge, we target a maturity level, that means a predefined set of process areas, or we handpick the process areas to appraise. The results are telling us which practices we already implement and which ones are new to us.

What to do with the latter? Let’s don’t forget they are considered best practices, which, if implemented, will bring us measurable benefits.

So the first idea is to identify those benefits. If we can, we are happily producing a business case to identify the ROI and later to come up with a plan for process improvement. If we cannot, let’s at least try to identify and address the risks of not having them implemented. We may be in for some surprises and wonder how comes we haven’t realized so far how many critical problems had been so close to materialize. Funny to say, we might perform this risk management on the Risk Management specific practices.

What if we can identify neither the benefits nor the risks? I don’t know a “one size fit all” answer. It depends on the context. We may accept the situation and go on with our lives without caring so much about those “orphan” practices, and consequently about achieving a CMMI maturity level. Or we can trust the model and implement them anyway. Sooner or later we’ll realize if they are good for us.

Nicolae Giurescu
http://www.3pro-lab.ro/

We may be small but we are complex

"We may be small but we are complex"

Who said that? Someone from a small setting in USA -we wish we knew who.

It's what we also think about our company, BIS.

When we first started the SPI (Software Process Improvement) all we knew about CMMI were the acronym and that it will be difficult. Someone told us it's a huge headache waiting for us due to the bureacracy CMMI will bring. That it is by no means suitable for our small organization.

After some training and a bit of self evaluation, we came to the conclusion that in fact CMMI is about the essential practices of the industry.

We develop software for financial institutions - we need these practices to be competitive and survive a rocking-and-rolling environment.

Size of the company is of course an issue in adopting the practices, even on maturity level 2 ; resources are not easily found when you are small.

But regarding the implementation of the CMMI practices, we've discovered soon enough that this doesn't automatically bring bureaucracy in the company. It depends greatly on the solutions you choose. CMMI is telling in fact what practices you should have, not how to do things.

In a way it's like when you prepare for a hiking in the mountains.

A quote from the page http://www.associatedcontent.com/article/6807/6_essential_items_to_bring_on_a_hiking.html

" A few rules you should hike by are to always tell someone where your going and when they should expect you to return. .... Also hike with a buddy or group whenever possible......When heading out for a hiking trip there are some definite basic items you should bring along. The most important has to be food and water.....

Remember anything can happen at anytime, don’t assume you won’t need it.....etc etc"

These are recomended practices regardless of how many days you're planning to hike, how big is your party or how difficult the trails are. They tell you what you need to stay safe and have fun!

It's the same with any organization, regardless of the size. You need configuration management, project management, quality management and so on. The essential practices - take them with you and you will have a better chance to stay safe and even survive in a crisis situation.

How you implement those practices is a different story and it's the most difficult part of the game. The tricks of the hiking expedition and of the SPI project.

Regarding the size problem, I don't think we are telling news when we are saying that the main issues of our SPI project were:

- the budget allocated to the SPI project

- time

- human nature, naturally not allways open to changes, especially when changes demand personal effort.

- creeping bureacracy

These can be found in fact in any SPI project but, in a small setting, dealing with them is a little bit more difficult due to lack of resources.

Let's consider what we found was the most difficult process area: measurement and analysis.

In this case, bureaucracy can creep and destroy all good intentions.

One must be very very careful in defining objectives and selecting metrics and indicators. "If we don't need it, we won't do it" must be written on all walls. Think "money", think "time" - analyse the resources needed to collect and measure and analyse results.

Such measurement and analyses activities can divert most-needed resources from projects.

Our first MA plan had more than 30 metrics and after 3 months we discovered only a couple were applied.

Then we've defined a small set of objectives more realistic, intelligent and suitable for our business. We've chosed 5 "good" metrics and started with them the journey.

We came to the idea that automation is a must in collecting and validating measurement data and collecting data must be embedded in the daily activities.

This has brought Microsoft TFS and the Sharepoint technology in our path and we've been good travel companions ever since.

Andreea & Emilia