GovernIT

Again let me remind you Jeet Kune Do is just a name used, a boat to get one across, and once across it is to be discarded and not to be carried on one’s back

- Bruce Lee, while describing Jeet Kune Do (JKD)

Over the last couple of months, I have been reading a large number of blogs, discussions, arguments, between purists on either side of the “Process fence” as well as middle-of-the-road liberals on what development model is best suited.

There are thousands of successful projects delivered using Agile, CMMI, SPICE, RUP and the hybrids in between, so clearly there is no single silver bullet. That begs the question, is there a single best way to develop software? Increasingly, I feel the answer is No. Even if you decide to go one way due to the needs of the project, it is not necessary to abide by a rigid set of rules prescribed in general by experts in that model.

How then do you decide how to develop software? The answer may lie in adapting JKD’s “The Way of the intercepting fist” philosophy, which, I believe, is closely aligned to Lean “thinking.”

Some thoughts:

• Start with understanding the nature of the project, the clients, the project teams and management needs
• Let this understanding drive the selection of the overall framework. For instance, if the project is to develop against an evolving standard, one of the Agile methods may be suitable. But if the team is not mature in terms of development practices, one of the iterative-but-process-oriented methods like the 2I or RUP may be better
• For engineering practices, use concepts and tools proven within the organization
• For project management, the established way within the organization or PMI’s methodology would be a good start
• Don’t be afraid in discarding practices if they are not useful, but be sure to substitute them with more useful ones. The easiest example I could think of is integration. A big-bang integration is not the norm these days, even in most process-oriented shops, but you can institute multiple daily builds instead of weekly or monthly ones. Another example is using Failure Modes Analysis (FMEA) to drive design decisions in iterations to prevent too much refactoring

There must be a term in psychology to describe this behavior: the moment we associate ourselves with something, we start believing that we must adhere to it 10o%, else the skies will fall on our heads!

As project managers, we must be careful not to fall into this trap, but carry a “toolbox” of practices which can be used in different situations. I am told that successful managers have this toolbox subconsciously, but are unable to spell it out exactly.

What about you? Do you think it is advisable to go with a single system of tried-and-trusted practices or have an assorted toolbox?

   Send article as PDF   

Your Process Improvement initiative or even a simple process definition has failed. You have taken the necessary steps to see that you are not defining a stupid process and provided guidance on how to define processes. It still failed, sob. Once you have gotten over it, read on.

The 3 most common ways you can fail at Process improvement, that I have personally seen are:

1. Blind Adherence to Frameworks

Process frameworks such as CMMI or SPICE are intended as guiding principles to help

you develop processes that, in turn, help you achieve your business goals. Trying to incorporate each and every aspect of a framework without regards to its applicability in your organization can result in bloated processes that no one can or will follow.

Usually, process improvement begins with Gap Analysis of existing processes against the chosen Process Framework. This is where you can take a wrong turn.

Understand the intent behind the Framework when performing the Gap Analysis. One tried-and-trusted practice is to extract the objectives from the process (in CMMI, these are neatly defined in the Specific Goals) and then use them to see if the goals are met by your current processes.

2. Committees

Yes, Practitioner-led process improvement is the way to go. But that doesn’t mean that you try to get “representation from every section” of people into your process definition team! After a certain threshold, an increase in the number of people is only going to hold you back.

From my experience, the magic range is 3-5, but that may vary if you are in a business process improvement scenario. One symptom of a dysfunctional large team is endless bickering over every word and its intent when drafting the process – in one case, there was a 2-hour discussion on using “measurements” vs “Metrics”!

3. Endless Alternates

This can be a standalone issue or an offshoot of the first two. I have seen teams debate over different scenarios which they might face, when the probability of these scenarios occurring is really small! Usually, there are a few critical paths where the teams might need direction and then there is a catch-all section (which is usually an escalation path for more guidance).

This situation arises when

• People don’t trust themselves and others to do the right thing and/or
• Managers are not very forgiving when their teams take decisions using judgement and then mistakes happen. Only a learning environment is a growing environment and without it, you cannot help people become mature. Without mature people, you cannot have a high-maturity organization!

Yes, there are more ways in which you may fail, but I’ll follow my own advice and stop from listing out all other scenarios . That, however, does not prevent you from adding your own experiences in the comments. They may be a bigger cause of failure!

Do share in your experiences in process improvement and of course, subscribe to the blog.

   Send article as PDF   

In previous posts, we have seen how to use the Six Honest Serving Men to define the elements of a process, while keeping it from becoming stupid. In the latter, one of the items we briefly touched upon was to make Process definition “Practitioner-led.” Today, we’ll dive into this inclusive way a little more.

[In industry jargon, Practitioners are the people who perform the tasks indicated by the process - software development teams, for example.]

Why Practitioners have to participate in process definition? Some common objections encountered are:

• They are not experts in process development
• It is not in their job description or they have other work to do
• If they do it, why do we need process specialists?

While these are valid to some extent, lack of ownership of the very people who have to use the process is the single biggest reason for failure of processes. This isolationist, ivory-tower approach results in processes that are out of touch with reality, do not take into account established practices and a general feeling of “process policing” among the development and project management community.

Most people that I encounter, including die-hard Agile champions, agree that some agreement on how things will be done is necessary when such activities involve many people. A process is such an agreement. When we trust people to develop mission-critical software for us, it is foolish to think that they cannot define an effective way of doing things!

Are you convinced yet? If yes, let us move on and see how we can implement this effective means of defining processes. The title points below are meaningful enough without me trying to elaborate on them.

• Assemble the right team
• Identifying process requirements
• Identifying current practices
• Defining the process
• Piloting
• Implementing

Assembling the right team is probably the most important part of this whole exercise. You need to bring in people of all kinds. You need process champions, critics as well as technical experts.

What about you? You are there to assist them in wording the process, doing the documentation work, creating simple flows and probably to see that process requirements are defined right.

One other thing I have found helpful is to incorporate as many current practices, documents and tools as possible. To do this, you as the process specialist have to talk to people, do the research and generally make it easy for the team to define the process.

A good Practitioner-led process improvement initiative reduces the inertia and encourages others to follow what has been defined by their fellow clan members.

In fact, many guidelines from the SEI show that the use of practitioner-led process improvement journeys lead to sustained improvements in appraisal ratings as well as in achieving project maturity.

Share with me your stories, criticisms and your experiences in the comments below.

   Send article as PDF   

In Process – How to develop one that is not stupid, we looked at how we can develop a process that empowers people to do to their thing and not stand in their way. But how do we actually develop one that can assist us in achieving the above goal? Using the concept of Six Honest serving men, we can define a system for activities that involve more than one person. Some of the following content may overlap with other posts, but that’s because they are all related (or maybe I am too dense to write one that explains all).

Why: As I mentioned in a previous post, without stating clearly why we are doing something, it is pretty difficult to convince people to even read something, forget about following it. The Why is often stated in grand terms, and since people are not stupid, they understand it is just for the sake of having it! Have a simple description of the outcome and why following it will help them (in their daily life and not something like, “It will make the organization compliant with the GRAND THEORY OF NOTHING”. Who cares?)

What: What defines the activities that need to be completed to achieve a certain goal. The inputs for this can be based on existing team practices or from best practices in other teams or (God forbid!) from frameworks.

When: When here does not relate to time, but the sequence in which the above activities should be performed.

Who: Code does not get written just because we have defined “Write code”. Someone needs to write it and someone else needs to test it. Mr. Who helps us identify the people to perform the activities in the desired sequence.

Where: This is the easy one. You ask me to enter the bug – fine. Where? You get the idea (please don’t create forms for every small bit of information!  Funny one here – http://www.bureauofcommunication.com/compose/romanticintent)

How: This is the most difficult one. If you list out how to do an activity in great detail, your process will be cumbersome and if you don’t give any details, it will not be useful. Err on the less side, since you can always add detail. This is easy to say, but difficult to implement and unfortunately, the answer for how much is, “It depends, at least for me. By the way, do you have any good principles for this? Share with me.

One of the easiest ways to spell out a process is the System flow chart or activity diagram coupled with annotations for inputs/outputs of the process. This makes the process simple, visual and clear.

If you are wondering if this can be used in Agile methods (not using Agile process, in case you are offended. Ha.), the answer is yes. A process is just a structured method of representing what needs to be done and does not mean it needs to be “heavy”; it can be as light as you need. If you come from a process mature organization and want to find out if you can use Agile methods or not, read this interview and then buy the book (disclaimer: I am not affiliated in any way with the author and have not yet read the book completely).

Go on, become a process specialist. May the Force be with you.

   Send article as PDF   

There are many classifications of metrics in the industry – here is one set that I find useful when defining metrics for your project. I find them useful, since they force me to think about my objectives as well as what other decision-makers want from them. These types are commonly used with the term KPI (Key Process Indicator) in many industries. Let us continue calling them as Metrics, as we are focussed more on the Project/Program level.

Lagging or Validation Metrics

These are “after the fact” metrics to show how we performed and if everything is going smoothly. These “validate” the current processes and may show deviation from the expected value. Typically, there is nothing we can do about the completed activities, but can take corrective actions for the next set of activities.

This is generally ok for repeated activities, such as bug-fixing, but not for activities that are unique in the lifecycle. For example, if we have metrics for measuring quality of design, having a report on the defects after the design phase (design defect density, phase containment defects etc) is not terribly useful (even in iterative projects).

Leading or Improvement metrics

These metrics give us early information on the quality or progress of activities that are currently being performed. Considering the same Design phase example, if we can get inputs on the quality of design as it is currently being done, there is scope to make corrections to the process. In software development, these tend to be more of engineering metrics, such as cohesion, coupling etc.

When defining a metrics program, we should be careful in having a balance between these two types of metrics. If Lagging metrics dominate, there is not much you can do if something goes wrong, except as Lessons learned (which I doubt are learned!). If leading metrics dominate, you don’t know how you performed against overall targets or compare against previous projects.

You must be wondering – what has satellite images of a storm got to do with metrics? An analogy that is possibly distant, but the intention is this – Your metrics must be able to show all 3 aspects – what has happened, where do we stand, what is going to happen in the immediate future. If you have defined the right metrics (its easy to define a lot of wrong metrics!), you will then be able to decide how to act.

If you are thinking on where to capture information on the type of metric, the Metrics catalog is a good place to put it in.

   Send article as PDF