If you're gonna do it... DO IT!
I was on the phone yesterday with a prospective client talking about bringing CMMI into an environment where the developers themselves have requested tighter processes. I was also told that they're adopting Scrum (and possibly other Agile) methods.
In line with not wanting to pursue CMMI practices for the purposes of the appraisal and expecting to focus on the improvements, one point of potential resistance to change (which I find common at most companies -- heck among most humans for that matter) came from the perceived expectation "from CMMI" for so-called 'documented' evidence.
First-off, I explained that the evidence required by the appraisal didn't have to be a document, nor does it have to be created after-the-fact of the actual work captured by the evidence. This discussion took us into some particular areas of CMMI's practices and the "findings" from the discussion are where the title of today's post comes from.
Part of the resistance was from the potential burden on team leads and project managers to capture information from the daily Scrum meetings. I pressed for some examples of how their teams manage each Scrum, their Sprints or their backlogs and learned that all of that was rather ethereal as well.
In which case (if our conversation were on a Webcam, I could have emoted much more expressively), I was quick to point out that Scrum is a discipline. If they aren't doing the things expected by the actual Scrum"™" approach, they're not really doing Scrum... they're just making themselves feel good about calling what they're doing by a recognized Agile Method.
Not having a way of managing one's work but calling what's not being done by a name isn't the same as actually managing the work. This is true regardless of whether there's an attempt to implement CMMI. Certainly, implementing CMMI will cause this company some serious shifts in practice. But no more serious than actually following Scrum.
2 Comments:
It has always been a tenet of mine that everyone is entitled to an opinion up until a decisions is made, but after the decision is made, everyone needs to commit to it 100%. An equally important piece, however, is a management commitment to process improvement. These two approaches reinforce each other.
When attempting something new, it is impossible to have all of the issues resolved ahead of time. Also, some of the predicted problems will not come to light and those that do may not have the impact feared. I have always found it most productive to proceed with uncertainty coupled with the confidence that the team and I can resolve whatever issues arise.
For a team to take on a pioneering attitude, it must be supported by an upper management commitment to adapt the process to handle unforeseen circumstances. This is the point where agile vs. CMMI raises its political head, when neither outside force will adjust to the needs of the team. Often a team feels forced to follow two processes leading to rejection of both. Without hope of these difficulties being resolved, a team will often reject a new approach in order to avoid being trapped into a lifetime of duplicated steps.
To learn something new, one needs to jump in with both feet. One also needs to have reassurances that when difficulties arise, there will be upper level support in addressing them. Having a team try a new approach and then responding to its comments with approapriate adjustments will give the team a feeling of ownership of the process. Failing to adjust when necessary will only give the team feeling of bureaucracy.
Beautifully said.
Commitment at the working level can only exist when there's committed support at the management level.
Management can want things all day long, but if they don't actually understand what it takes to achieve those things then their words of commitment ring hollow in the ears of those who are expected to make good on management's expectations.
Part of commitment from management must also include a dose of involvement, ownership and responsibility. Especially in small organizations, when management's sole demonstration of commitment is writing checks, it gives everyone the impression that management thinks it can buy its way towards things like improvement.
Just saying the words isn't enough. Making themselves available to attend status meetings, actually taking an active interest in how changes effect company performance, and changing arbitrary deadlines so that management can be involved are some of the ways management can really show commitment.
In fact, the whole deadline thing...? That's a complete relinquishing of any actual commitment. It belies the idea of commitment. It says to staff: "This is your job to deliver these results, not ours. Get it done!" Because if there were real commitment behind the deadline, then management would say, "... you know... we couldn't keep up with our own expectations... because we couldn't get involved, we need more time to see what's going on."
But then again... for management to think that, they must already understand what _actual_ commitment looks like. When they set a deadline, don't show up for meetings, don't really know what goes on behind the curtains, and still expect the results, their commitment is just a bunch of smoke up you-know-where. It's too bad everyone but management sees that for what it is.
Commitment is clearly a key factor to success. In my opinion, companies who succeed without management commitment did so because of dedicated workers, not management excellence.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home