24 January 2010

People over Process . . .

The agile manifesto makes clear the authors’ value of people over process.  With that, many readers/users of the manifesto somehow misconstrue this as “People.  No process.”

Others, being more intelligent and reasonable, do see the value of having and using processes, they’re thinking a little beyond the next 11 seconds and are reflecting a bit deeper on the roles of and interplay between people and processes.  Such people are seeing that the real question isn’t about people or process, but that what they struggle with is how to find value in what people do and the processes they perform.

Value.

That’s a powerful word.  I love this rich word.  You can get all sorts of people to stop and think about what they’re doing when you ask them the value of their effort.

Asking about value can come full circle – even for process people.  What’s the value, for example, of checking on a process?

Many use process audits, but what’s the value in it?  Especially if the process works fine, and, there’s a cost to check on it – with a net result that you spent time (= money) checking for something that didn’t and might not happen.

Calling them “objective evaluation”, CMMI® is replete with efforts that are expected to check on processes.  (GP2.9, PPQA, OPF, et al.)  Though, CMMI® is purposefully thin on exactly how to accomplish this, many have chosen to carry out “objective evaluation” using ‘audits’.

Audits not only invoke a confrontational and defensive entrenchment, but also have the attribute of easily devolving into “process policing” and other non-value-added paradigms.  Don’t misunderstand, we’re not saying it’s not important to keep tabs on your processes, but there are more and less value-added approaches to how you go about doing them.

At the risk of sounding too much like advice from an Eastern mountain top, I propose that you allow people to be the process.

That is, imbue a cadre of people whose jobs are to know the processes best.  Not CMMI® processes, not Agile practices, but the processes the organization wants everyone to know and use.  How else will anyone know what to do?  Great organizations do this all the time.  No one questions their use of such people.

Clearly, it would be out of character for me to suggest that you don't have processes, or that you create “lottery sensitive positions” (i.e., critical, single-point-failure positions whose loss would be severely disruptive to success).  So, this is not what I’m saying.

But if the idea is that you want everyone to be on the same page, that you want to create processes that people want and love and that they can identify with;

if you want to create a reliable culture of excellence where everyone truly participates in creating exquisite results;

where everyone is fully invested in the organization and its success;

in the language of CMMI® -- where the processes are firmly institutionalized;

that people who know the process very well and whose jobs are dedicated to helping everyone else learn and use the process are out in the projects coaching and mentoring teams in the process, facilitating retrospectives, demos, peer reviews and whatnot...

There isn't a non-CMMI® or a non-Agile thing about this!

We’re talking about coaching, mentoring, and facilitation.

Self-directed, self-organized teams still have coaches, Scrum masters, and someone to turn to when things are stuck or just don't seem to be working correctly...

... you want to grow an organization where everyone knows what to do without being told?  Use coaching and mentoring of your patterns in your patterns

There can be a smaller organization of just such coaches, mentors and facilitators, with others rotating in and out of on some regular cadence, these people can also gather lessons, collect information, spread new ideas, create experiments, and routinely check to see whether and how well what teams are doing is working. 

If/when there are new and better ways of doing things, these coaches can help refine them and make them usable by other teams, when things are broken, they help fix them. 

Why do audits want to know whether the process is being followed?  If it’s compliance, then it might very well be a waste of time. 

The real reason is to learn about the process and to use the audit as an opportunity to learn about and share what’s working and what doesn’t.  So, instead of audits, why not jump straight to the real purpose behind them and ask, “what are you doing?” and  “how’s that working for you?”

You’ll get the same benefit without all the baggage, waste and negativity.

Doesn't everyone know this is what having a defined process is?

Doesn't everyone understand that this is how process evaluations or audits are supposed to work? 

No?  Really?  Huh!

People over Process, Right?  Great!  Let people *be* the process!

Labels: , , , , , , ,

17 January 2010

Do you have what it takes . . . ?

To pursue CMMI and/or to reap the benefits of agile requires more than just desire at the working level.  It takes:

  • honesty
  • learning
  • transparency
  • respect
  • support
  • trust
  • patience
  • commitment (to excellence)

Not just from people who will feel the changes most immediately but from the top-most person in the company on down to those people whose work support the people who will feel the changes most.

If you have an executive who declares: we want "maturity level __” by such-and-so date, and doesn’t themselves bother to take the time to understand what that means, you don’t have what it takes.

If you have an executive who declares: we want "to be more agile” but doesn’t allow developers to organize their workspace or their time, you don’t have what it takes.

If you have an executive who doesn’t care how negatively a drastic poorly considered change will impact the developers, you don’t have what it takes.

If you have an executive who expects everyone but themselves to change or expects that hiring an outsider can eliminate the hard work needed to move from the present situation to the desired state, you don’t have what it takes.

Might I recommend this course for getting to know CMMI, at least.  It can be attended in person or on line.  Live.

Labels: , , , , , , , ,

10 January 2010

Contextually Relevant Experience & Why It Matters

Imagine what would happen if you went to a doctor (or any specialist) who had no experience in your specific condition or situation.  Has this every happened to you?  It has to my family when I was young.  Let me tell you, it wasn’t pleasant.  What was frightening was that the “professional” didn’t know that they didn’t have the right experience.  What was just as bad was that my family didn’t have the knowledge or experience to know that the person we went to was not qualified.

This is a situation encountered by many organizations when seeking advice and/or appraisal services from a CMMI consultant / appraiser.  However, in business, you should at least know enough about your organization and ways of operating to do your homework before picking someone to help you with CMMI.

What you may not have known is that CMMI and the appraisal method are not as clear and obvious as other means of performance evaluation and that you must choose your consulting firm and appraiser very carefully, and among other factors, consider their contextually relevant experience. . . .

Labels: , , , , ,

06 January 2010

Love & Marriage: CMMI & Agile Need Each Other

An article in this month's CrossTalk periodical, is now out.1001FrontCover-300

See it here.

Download it here .

Enjoy!hg_signature_blue_FNAME

 

 

 

 

P.S.  There are other great articles in the issue as well.  I'm in great company with an article by my friend, colleague and client, Jeff Dutton.  And, don't miss out what's coming next in v1.3 from my buds Mike Philips and Sandy Schrum!

Labels: , , , , , , , , ,