Instead of the traditional lecture and slide presentation,
Jonathan Addelston took the workshop approach at the last
DC SPIN meeting. He said he did not
”want to do a death march kind of presentation.”
Addelston indicated he wanted to address the concerns of those
“who show up for meetings.” Turning to an easel, marker in hand, he asked attendees what aspects of software process improvement they wanted to discuss. Attendees asked:
Is there a
Capability Maturity Model(CMM) for
”the small guy?” Small companies are told by their government sponsor that they must be CMM compliant in order to continue to bid on work.
If a company has a few projects, how much effort is required and how do you organize process improvement?
How do you develop and manage sponsorship for process improvement? How do you develop and manage participation?
How do you determine how much process improvement your organization can handle?
What about templates?
Should process improvement be organized top-down or bottom-up? Also, where are you likely to encounter resistance (general laughter). Addelston interjected,
“Where will you not encounter resistance?”
What are the
business drivers that work? that don’t work? How do you maintain and sustain motivation?
How does measurement and analysis in CMM compare to measurement and analysis in
Capability Maturity Model Integrated(CMMI)?
Would you be better off with
six sigma black belt project managers? Addelston said that leadership of software process improvement was the most controversial area and one he has seen
”carefully done wrong.”
A longer discussion followed on which questions were of the greatest interest to participants. Addelston promised to address them in the course of his presentation. He started his presentation with quotes from
Watts Humphrey:
If you don’t know where you are going, any map will do.
If you don’t know where you are, a map won’t help.
If the map disagrees with the terrain, trust the terrain.
Addelston said that process improvement teams should
”stick to real projects, not small, backwater projects of little significance to the business goals of the organization.” Many companies have only one division certified instead of the entire company. Addelston reminded attendees that the Software Engineering Institute now publishes
SCAMPI ratings. If you only have one division within your company rated, your SCAMPI rating will indicate that only that division is compliant.
Particapants asked a series of questions about what was necessary for certification, or rating for CMMI compliance. One attendee wanted to know what is the least you can do and still qualify for CMM compliance. Addelston replied that the glib answer is
“more than your nearest competitor.” Another participant asked what was the minimum project size for certification. Addelston said you should look where your business revenue comes from, small projects or large projects. The lead assessor decides what is the minimum project size. Here, a participant interjected that
“in the real world corporate management chooses the best projects.” Another said,
“Everyone is in bed with everyone else.” Addelston was clearly distressed by these questions - saying that he did not consider himself naive, but he had never seen situations such as were described. He stressed the benefit of process improvement: the capability to develop quality software on time and on budget.
Addelston said companies can and should choose recently completed projects for evaluation. This is the only way a company can show that it can complete a project and ship product. He said process improvement should involve two to three percent of your organization. He emphasized your organization cannot get the benefits of the higher levels of CMM without the
infrastructure of the lower levels.
He stressed the importance of process definition, including definition of standards, and the development of forms, templates and notations; he said,
“You can’t get started without this.” Process improvement should be treated as a project and conducted by the principles of process improvement. The process improvement team should set an example.
Addelston concluded with a discussion of the risks of process improvement. Sponsors give too much attention or too little. He described the case of a large company that spent 3.2 million a year for three years without result. The assessors discovered that seven of the scheduled quarterly meetings with management had been canceled.
Addelston described the clever office politics that can often ruin process improvement, such as malicious obedience.
“You want a project plan? I give you a 1,500 page project plan that no one will ever read.” Workers will often engage in delaying tactics waiting for the process improvement team leader to get fired. Then there is the case of the Hobson’s choice, the worker who sets you up for the anti-process answer, such as
“Do you want me to complete the customer’s order, or do you want me to work on process improvement?” Process improvement can be ruined by dilution of effort: too many projects, too many deliverables. Failure to hold the project manager accountable spoils many process improvement efforts.
Technoflak hopes Addelston’s workshop approach will be used by other presenters. The meeting was lively, and many issues were flushed from cover.
