The Ideas Table - Obtaining Commitment

Last year we attended a very interesting presentation at SPI conference. "Interesting" usually brings in mind some positive thoughts like "the presenter has an extensive experience and we've found some good advice in what he or she presented". Well, this time it was a little different.

We knew from hear-say that the presenter’s company was quite successful at that time but with a high attrition rate and other staff problems and we were really curious to know why.
The first phrase stated that the success of a SPI Programme depends greatly on the people involved and on their commitment to the programme. Nothing new, we'd say that the success of any project depends greatly on the people involved and in their commitment.

So far so good. Ok, so how can one secure the commitment of the team?

We endured some slides offering all kind of formulas, such as
Motivation Potential Score = (Variety + Identity + Significance) / 3 x Autonomy x Feedback
Oh boy, maybe this is the rule and it is ok for many cases, but it's a software development company we're talking about. It’s about highly trained and extremely smart people and we wouldn't even think of trying to jump to conclusions based on some curious statistics.

We won't bother you with other similar ideas from that presentation - clearly taken from some smart books and applied "as-it is" to real life.
We will deal only with one quite dangerous practice explained largely in the presentation:

Project progress was reported at the team member level, and there were bonuses involved for each extra-success reported.

More people in the audience thought this to be a mistake. Software Development is team work.

Applying this practice will eventually induce an unwanted "bad internal competition", each member rather focusing on their own job and their own good image , than on the performance of the whole team.

Not to mention that the individual report was quite detailed, so that each team member would waste quite lot of time just for reporting purposes.

Also a curious system of rewards and penalties was set in place to ensure that these reports were obtained as planned . For example, one could be the best programmer in the company but wouldn't receive any incentive for lack of reporting progress as planned.
Other “great idea” was a black and white balls reward/ punish system for doing something good/ bad for the SPI project.

This is used with quite a success in some kindergartens in Bucharest and elsewhere. We wouldn’ t implement it in a high tech environment, especially in Romania (our sense of humor is so developed that this system would die of too much laugh).

Now we understand the high attrition rate and the staff problems. We have some difficulties to understand the company's success. For how long, we wonder.

Andreea & Emilia, Business Information Systems

 to be continued

Management Style in SPI Projects

Recently we had a SPI Conference in Bucharest, Romania.
The 3rd Central and Estern Europe Conference for Software Process Improvement (CEE-SPI) has been quite a succes as participants were more than eager to share ideas. One hot debate has been on the management style in SPI projects.
Democracy versus Autocracy. Different opinions, most of them in favor of democracy.

Let's take a closer look at the definitions.
Autocracy
government in which one person has uncontrolled or unlimited authority over others; the government or power of an absolute monarch.

Democracy
government by the people; a form of government in which the supreme power is vested in the people and exercised directly by them or by their elected agents under a free electoral system.

Autocracy in SPI Projects? Mmmmm, no way. You're going to loose them, for sure.
Democracy? Maybe, but with a flavor of autocracy, we'd say.

When defining processes, democracy is a "must" in a software company, at least. We woudn't know of other type of companies. Everybody in the team, including juniors must have a chance to express an opinion.
A collaborative platform with a forum to debate processes are essential.

Why? We say: software development is still more "art" than "engineering". Software people are quite a special breed of artists. Or, if you prefer,  as Mr Radouane Oudrhiri has told us at the Bucharest SPI Conference:
"Software engineering is a particular engineering discipline where the work is mostly
on models and rarely on real world objects. All deliverables from requirements, to
architecture, to design are just models, including the final product itself (i.e. Software
or an Information System); it is a representation of a real world situation. The quality
of the final product lies in the modelling power and techniques used to express the problem."
(Read more here on this subject)

So, ok for democracy.
However, if at one point, debates are too hot or there's a "never ending song of love" playing, the Company's Process Group must draw the line, choose a solution and be satisfied with processes not so perfect.
Once adopted and approved by the Top management, democracy is out and eveybody should conform. Software Development is about creating products which must conform to the product requirements and this means a lot of discipline.

Of course, there is still room for improvement and any opinion should be welcome.
Periodically processes should be reviewed by the team a.s.o.

Emilia and Andreea, Business Information Systems BIS

IT Security and The Great Wall of China Lesson

The Great Wall of China , one of he world architecture wonders, built, rebuilt and maintained between the 5th century BC and the 16th century to protect the northern borders of the Chinese Empire became useless in a single day when one man who disliked his Emperor opened the gates.
We are now in a different world but the Chinese Wall Lesson is more than ever to be considered, especially in IT systems protection.

Whatever the security tools you use, from already classic antivirus programs to sophisticated devices and software which would make Orwell's Big Brother pale with envy, beware !
The whole security edifice could collapse due to one person.

This person doesn't necessarily have to hate the boss but stupidly, unaware of all the perils of the great Internet could fall victim to an ingenious www terrorist.

Whatever the reason of the "treason", tools are not enough to prevent the failure of your security system.
I won't discuss how to prevent the potential harm due to hate, greed, sheer stupidity etc.
This is thousand years history and we still have a lot to learn.

So I'll presume that everybody in the company has good intentions, loves the job and the related benefits and fears the consequences of some inadequate action.

An approach based on best practices, politics, procedures (updated and disseminated rapidly in the whole organization) is a must. People should be trained to understand them and apply them on a daily basis. Processes related to security should be defined, implemented and monitored.

More than that, you need a collaborative platform with a functionality that will offer some important benefits:
- ensures that everybody stays informed and nobody can complain that one was not informed
- all politics, processes, procedures and instructions that implement all company's best practices (including security related) are up-to-date and are visible to everybody anytime (in a normal day business or in a crisis situation).
- bad news and good news are rapidly spread

- tools for risk management, of course
- easy access to an efficient internal helpdesk which will prevent small incidents becoming disasters

- tools for monitoring of planned events. Don't forget that moving a company or replacing a server or upgrading software can cost more than a fire or a flood if not properly dealt with.
- easy two way communication. Management should be able to communicate rapidly all decisions related to security. The humblest person in the company should be able to communicate all others issues or ideas.
- a Business Continuity plan, procedures and tools to monitor crisis situations.

Such a collaborative software will surely change the culture of the organization.
Sharing essential information is as vital as the technical infrastructure.
As some gurus of the Management systems say: "knowledge is power" should be replaced by "shared knowledge is power".

Emilia Dragne

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

An Interesting Speach on Software Aquisitions

I've just read the speach of Paul D. Nielsen, Director and CEO of the Carnegie Mellon Software Engineering Institute before U.S. House of Representatives.
You can read it too here: http://www.sei.cmu.edu/about/press/releases/nielsen-testimony.html

Very interesting for everyone in the software industry, including the 10 reasons for software aquisitions failures:

1. Technology key to program success is new to the organization
2. Software issues are considered too late in the system-development process
3. Inadequate planning and estimating
4. Size matters – large projects get into trouble more frequently than smaller ones, all projects grow larger over time
5. Software objectives are not fully understood or specified; they change frequently (and grow) during the project
6. Inadequate experiences and trained project management
7. Inadequate process emphasis and erosion of process discipline
8. Inadequate contract incentives to encourage use of proven software engineering practices
9. Acquirers and developers lack experience working as a team or the resources to do so
10. Insufficient senior staff and inexperienced software engineering cadre

In the last 10 years I have found these problems in speaches and presentations, every now and then.
Statistics showed a real improvement in companies that adopted solid models and methodologies. A lot more remain to be done.

I quote what I've enjoyed most in the speach:
The "unlimited" complexity of software is neither well understood nor well appreciated by many. Software is not rooted in the physical world like other engineering disciplines--civil, aeronautical, electrical, or mechanical engineering. Without physical constraints, the design space is so vast for large programs that you need strong architectural principles, disciplined processes, and talented people to be successful. The larger the program, the more important this is—and, as you are aware, many defense programs are very large.
Additionally, software is invisible; people don’t buy code - they acquire systems that satisfy requirements. And software is intangible—you can’t touch it or kick its tires. Nevertheless, in most defense systems, software is critical to the very success of the program. The systems just don’t work without software.

I remember one "funny" experience we had recently in dealing with one of our Governement Agencies.
We in Romania have inherited a system in which the company has to paint/ stamp an inventory number on each object it owns. So far so good, it doesn't hurt.

But when that Government Agency requested that we have to paint those inventory numbers on our software, we gasped, and laughed, and choked and got nervous and exploded.
We've had this stupid request for years and years in several state owned institutions. Usually we dealed with it by presenting to the bureaucrats a CD or diskette or a licence sheet with an inventory number painted on it. Here Ladies and Gentlemen is your software !!!

This time we debated if we should refuse to obey. Enough is enough. This aberation, a favorite of old bureaucrats, has to stop. Dear all, software is invisible, intangible, is not an inventory object. Give us a break.

Finally, we gave up. Fighting bureaucracy was too much time consuming. We made however a technological progress. At the agency request, we put a label on a computer.

Ladies and Gentlemen, beware, BIS software is inside!

People CMM and Small Organizations

I fully agree with this quote. People CMM has the best practices needed by an organization to attract, develop, motivate, organize, and retain the workforce.

If you are a manager in charge of a whole organization or a team or a HRM Department, People CMM is the model to follow.

People CMM version 2 has just been released - see the SEI site for all information on this model.

The People CMM model helps organizations to establish a culture of professional excellence which is the best remedy for brain drain.

Today, People CMM has been implemented in various types of industries (Banking / Financial Services, Governement, Insurance, Utilities, IT of course etc.)

The People CMM model must be interpreted flexibly especially when applying it to smaller organizations so that bureaucratic activities are minimized.

Pay attention to the fact that "size" for organizations in Romania (and other small countries) is not the same as in North America. What in Romania we say "large" in USA is "medium/ small". Only telecom organizations, the first 3 banks, several international companies might be considered "large".

From the point of view of People CMM Model, most of the organizations in Romania should be considered small/ medium size and as such, the model must be carefully interpreted.

We've had enough bureaucracy so far, no need to increase the forrests devastation.

I will add this: a collaborative platform, simple to use and affordable yet with a powerful functionality can make the difference between a successful implementation of the People CMM model and a new nightmare in a small/ medium size organization.

As I'm from BIS and I have been using successfully the collaborative software BIS Esfera Suite on a daily basis for more than 7 years so far, I can say Esfera is an interresting option. We are now in the course of migrating the product on Microsoft Sharepoint technology and People CMM proved to be extremely useful in improving the product requirements.

Emilia Dragne

BIS SPI Project Manager