Joining the resistance
I often agree with technology professionals who try to resist change. Most of my career has been using guerilla tactics, developed by Industrial Psychologists, to overcome resistance to change. But my years of working in software process improvement have definitely changed my view of what should get done in order to improve application quality. I resist change, especially software process improvement, unless it is absolutely necessary. My approach is obviously not what you read about in the process improvement literature and of course many of my colleagues disagree with my philosophy. What we need is a process improvement underground to resist meaningless change.

Searching for what’s broken
I often  hear my colleagues complain about problems in their development environments that adversely impact application quality, productivity, morale and of course corporate profitability. I am thrilled when I hear about these problems because challenges help me focus on what really needs to get fixed. The easiest way to search for what is broken is to ask people what they do well and what best practices they would share with others. Professionals are often quite honest with describing the problems that impact their development effort and that is an excellent tool for identifying what really needs to be changed in order to improve the software development process and, of course, application quality.

Frameworks are often right
 Frameworks such as the CMM, Six Sigma, Agile and XP often do accurately predict what needs to get fixed in order to improve application quality. However, SPI practitioners cannot and should not assume that they know what is wrong in an organization until they have conducted a reasonable assessment and become more familiar with existing processes and, especially, the corporate culture. I have worked in financial trading environments where everyone thrived on risk and trying to eliminate risk would be rejected immediately by all concerned. However, the first time that developers cannot rebuild a production release is your ticket to immediate process change and improving application quality.

Experience counts for a lot
The same problems do often repeat in different organizations. I often ask a developer to describe how he builds and deploys a release. However if I ask to do a test build from another user account, the process is often obviously very broken. It often takes at least three tries for my colleagues to tell me the required environment variables and steps necessary to complete a successful build. Too often they have forgotten what they did a year ago to get their build environments setup and even worse people on the same team are usually building the same application differently. This can be a source of many application defects, and of course, challenges in supporting release management.

Problem identification
 Once we’ve identified a serious problem or limitation, making significant change is much easier to accomplish. Focusing on the reasons why we must do things differently is essential and showing respect for our colleagues is a core value for any process improvement professional. I always try to be hands-on for at least a couple of releases. This means that I have to keep my own technical skills sharp, but it also helps me respect the skills and abilities of my colleagues. If I can demonstrate that I understand what is going on and intimately understand what is broken then it is often possible to generate considerable support for change and improving the development process.

Where do we start?
So the truth is that we really do know what goes wrong in any application development effort. A good place to start is to ask if they are tracking problems/defects in a database. Are there formal requirements and how are they communicated between the users and the development professionals who are writing the code? Listen for the problems and challenges faced by the team. Usually management does not have a reliable way to know if a project is on track or not. Often delays are not communicated until the very last minute, which is bad for all concerned. Risk is not usually understood and technology professionals are often afraid to communicate that a new approach is not well understood (and of course has associated risks).

So maybe there is wisdom out there
It is not a coincidence that the CMM starts with a focus on Project Planning, Project Controls and Requirements gathering. These are classic areas where many major development efforts fail. It is also no surprise that Configuration Management is the backbone of most software process improvement methodologies. It should be and that is why many of us work hard to develop Software Configuration and Release management processes. Managing vendors and subcontractors also requires well defined processes in order to assure application quality. In many projects, testing, training and code reviews are often not given the priority that they deserve. 

Process Improvement
Defining what needs to get done, by whom and how each step is communicated is the very basis of Software Process Improvement.  SPI professionals need to approach each engagement with an open mind because teams often have their own “ecosystems” which may or may not have the same problems as encountered in the last engagement. Showing respect for our colleagues and being open and honest are also core values that every SPI professional would do well to practice. Improving application quality should start with an honest and open look at what is working and what needs to be improved. Industry standard methodologies and process improvement frameworks are essential tools for every SPI practitioner. A good place to start is to search for what is broken and engage your colleagues in a collaborative effort to improve the development process and of course application quality.

 TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed