GovernIT

“Process” in the software development world has been characterized with colorful adjectives. I am here to defend it.

What is about the word “Process” that makes people run fro cover? I see a lot of people who turn to Agile, not because they realize its worth, but because they think it frees them to do what they want, how they want. Agile is discipline, folks and you can do it only if you have the maturity to handle that discipline on your own.

Here,  I am defending a process that is simple, provides clear roles and responsibilities, is changed appropriately when needed and most importantly, the one that is applied well. I am not defending a rule book written in circa 1800.

I hear you. You are saying that process as I defined is not the one that you see everyday in countless organizations. Right. But I ask you, is that the fault of the process? Did it slowly creep into your organizations? No, we wrote it. We are the ones implementing it. We are the ones hiding behind it.

A process is nothing but a set of steps we write to accomplish a particular task. We write it down so that others may follow the path easily and when we have thousands of people doing the same task, we don’t want everyone to do it differently, unless circumstances require.

These exceptional circumstances occur more frequently in the SW dev world than in other places like manufacturing (that is why concepts in manufacturing don’t lend themselves well to SW, but that is for another day).

So what do we need? We should define processes that result in desired outcomes. We need to create awareness that a process needs to be adopted and adapted as the situation changes to make it effective. Let us look at some things that we can do to define a process that is not stupid.

1. Define the Why

There is a better chance that people will follow the process if it is clear why and the why is “reasonable”

For example, for software configuration management, the “why” is to ensure that code is checked-in frequently (to avoid crashes or overwrites), follow naming conventions (to easily determine what the file does/belongs by looking at the file name), follow the structure (to modularize code) etc.

2. Minimize Forms

If people have to fill out forms for every step of the process, be sure that will never be followed. While some amount of paperwork is necessary, it should not detract from actually performing the task. The biggest mistake I see people make is trying to get a lot of information filled out, even when that information is not required or may not be used. There are two reasons for this:

• Incorrect interpretation of process frameworks like CMMI or ISO
• When something goes wrong, find out where and why. The failure points are minimal, but to have some documentation for those failure points

3. Practitioner-led

Every activity, whether defined by a process or not, has to be done by someone. Why not ask those people to define the process? It is well-recognized that when a team of practitioners own the process, the adoption is much higher. Do we want someone sitting in an ivory tower to tell me what to do? Nah.

4. Automate

Look for ways to automate as much of the process as possible. If you are capturing information, don’t provide forms for people to capture data. Use tools or write scripts to capture and present that information.

5. Teach people to change it

Make it clear that the process is not sacred. When people start to feel it is not working or not comfortable any longer, change it. Fiercely implement a culture where people can voice their concerns about something that is not working for them.

6. Never talk about the stick

We all know about the “Carrot and Stick”. In this case, however, never ever use the stick. Are we cattle to be driven ahead? Lead us and we’ll follow. What this means is don’t penalize when someone does not follow it. It could be that the process is not usable under stressful situations or the leadership does not care about it. If the manager asks the team to forget about the process just for this urgent request, it shows that the manager does not think the process is useful!

If we follow some of the common-sense principles, any process can be made simple and usable. Otherwise, we will end up defining a complex “Agile” process!

Do you still think Process is stupid? What would you do to help people follow a method that can help them be productive, yet have fun?

   Send article as PDF   

One of the most controversial elements among IT staff is the use of checklists to verify accurate completion of activities.

Most implementations of IT frameworks, particularly in application development and IT services, strongly advocate the use of checklists as the first record of verification and/or validation. The reasoning behind it is quite simple – verify if critical activities/items have been completed and the resultant output meets the requirements.

At the outset, people create a checklist to verify a long list of things to be checked, with the opinion that all of them are important! Over a period of time, “Process improvement” adds more items to the checklists, resulting in a checklist that takes more time to fill than the activity which it verifies. Result – no one uses it in spirit, defeating its very purpose.

A look at other industries shows a different trend though. Manufacturing, construction and even pilots routinely use checklists to ensure nothing of relevance is left out. Let us a take a detailed look at the Airline industry.

Pilots use a number of checklists, before, during and after takeoff  – sometimes using as many as 17 different checklists for each flight:

• Pre-flight checklists on safety, external inspections, cockpit inspections, before engine start, starting the engines, before taxiing, during taxiing
• Take Off checklists – before take-off, line-up, during take-off, after take-off, Climbing, Cruising
• Landing checklists – Descent, before landing, going around, after landing, shutdown, before leaving aircraft.

In addition, there are other checklists for abnormal conditions, such as emergency landings, loss of cabin pressure etc.

Two things differentiate checklists in other industries and checklists in IT – one, the target for applying is potentially infinite in IT and the items are not necessarily sequential.

Checklists in IT usually check for standards adherence and may have some questions to check for common mistakes. The problem with this is that standards have to be checked through the output and may occur hundreds of times, which may not be humanly possible.

The best way is to automate the standards verification process, through tools such as static analyzers, scripts to check authorized installations of software across the enterprise etc. Checklists must be used only for checking logical errors, common mistakes in applying principles and other areas, where automation may not be optimal.

Unfortunately, most IT Frameworks mandate organization-wide definition of standard checklists that become outdated quickly. Effectiveness can be improved exponentially by requiring that checklists be used by IT, but the contents of the checklists can be defined by the teams themselves. This is a COBIT-style approach, where control points are defined, but it is left to the teams themselves to define how they will pass the control point.

The Personal Software Process by Watts Humphrey (SEI CMU), for example, recommends that software developers create their own checklists based on their work style. For more information on PSP, visit the SEI website.

   Send article as PDF   

With the alphabet soup of IT Frameworks, it is easy for small and medium businesses to get overwhelmed or confused. Getting a consultant on-board early helps, but it is difficult to get good consultants who can interpret the frameworks in a way that is suitable for the size of the organizations.

Most consultants assume unlimited resources are available (they call it “management commitment!”) for implementing a framework.

The clamour to become certified has reached levels where it has become a sort of polluted noise. In the midst of this chest thumping, a group of people chose to help people regain their sanity. Core Practice (CoPr), pronounced as Copper, is a set of minimum standards, that small and medium businesses can implement across the organizations, while choosing to go for higher levels in core business areas.

According the Core Practice guys, not everyone needs the gold standard in all the areas. Copper is good enough in non-essential areas. Copper does not mean you are unruly or indisciplined – it just means you don’t put a lot of controls and processes in those areas. This is quite similar to the Continuous model of the CMMI, where you an choose to be at different levels in different processes.

The Core Practice team is looking for people to join and help the Institute of Core Practice (IoCP) enrich the community with implementation experience. There are also some resources you can go through before joining.

Core Practice (http://www.corepractice.org)

   Send article as PDF