Like a Broken Record: Assume an Engineering Mindset

Posted by agilecmmi on Mar 7 2010 in Engineering | 0 comments
Engineering Mindset

I keep answering the same question over and over again.  On one hand, it’s good that interest in CMMI (and Agile) is growing.  On the other, I’d really like the development world to be able to move onto more interesting challenges.  I know it’s foolish to believe that answering a question on my blog will stop the questions from coming in, but at least once it’s answered, I’ll just point people here instead of repeating myself in emails and phone calls.

Whether the desire is to implement CMMI in an agile environment or a traditional environment, the key to making CMMI “work”, and by “work” I don’t mean “get you a rating”, or as people incorrectly call it, “get you CMMI certified”.  By making CMMI “work” I mean, incorporating CMMI into your organization in such a way that the resulting processes:

  • Add value to your organization and to your customers,
  • Are things people want to do,
  • Foster continuous communication and improvement,
  • Measure what matters, and still
  • Result in a desired rating (as a by-product, not the goal).

Here it is.  The “key” to making CMMI work is what I call, an “Engineering Mindset”.   Engineers realize that when they fail to be honest, precise, and thorough, things fail to work and many times this failure means someone is either disappointed, or worse, hurt or killed.  To avoid the undesirable outcomes, engineers have a sense of integrity. Not in the moral or religious sense, but in the sense that things are whole and complete.  An Engineering Mindset includes seeing things as problems or opportunities and their corresponding solutions or exploits.  So an Engineering Mindset has two elements: Integrity and Solutions.

For using CMMI, these two elements align nicely with what I’ve been saying for years.  These elements are not magic or glamorous, but people find them to be challenging, nonetheless:

  1. Be clear and honest with CMMI and how it works and what it really is and isn’t.  If you’re following in the path of Agile, you MUST also be honest with the Agile Manifesto. The “things on the right” *do* have value, and their value must be justified.  If you’re not all that concerned about “agile”, you MUST be concerned about value.  And for that you must get a grip on your work flow and be committed to knowing the value stream of your work flow and be committed to continuously and aggressively pursuing the elimination of non-value-added activities.  This often takes shape in investment in activities and a culture that appreciates and recognizes awareness, tools (methods, technology, assets, systems, etc.), LEARNING, pluralism, empowerment, and excellence.
  2. Recognize that CMMI PA practices are not processes but that each practice avoids some pitfall. Identify how your organization avoids that pitfall and you will have accomplished the intent of the practice. If how you avoid it is weak or absent, then it’s something you should build into your work.

Please pay attention to this next point: In my work, the organizations that embraced key point #1 had no trouble with key point #2, and, in many cases, required very little new or different to take them to any maturity level they wanted.

When we work with clients, we spend most of our effort to help them internalize #1 (if they need it).  When they’re able to do #1, they generally “get” #2 on their own AND they figure out where the value lies in the practices in CMMI they’re not already doing AND they figure out where and how to incorporate those practices into their own.

If your organization can’t figure out the value to your organization in CMMI practices, you’re not allowing yourselves to be creative enough and you’re not thinking like engineers.  An engineering mindset must exist first.  When it doesn’t, it’s a long and challenging road ahead.  Choose wisely.

This is another test….

Posted by agilecmmi on Mar 5 2010 in Uncategorized | 1 comment

This test determines whether my off-line blog editor works with our new blog.

hg_signature_blue_FNAME_sm

This is a test….

Posted by Hillel on Mar 3 2010 in Administrative, Uncategorized | 0 comments

Hello Everyone!

You may be wondering where have the videos and blog-posts gone?

Well, they’ve been on hold ever since we were given information that resulted in the need for us to migrate away from our prior blogging service and to a new service that gives us greater flexibility.

We’ve been working on the migration for a few weeks and, while we’re not 100% where we want to be, we’re close enough to give it a “live” trial.

For those of you snarky enough to wonder, “Did you follow a process?”  The answer is, “Of course we did!”  We used practices from requirements management (REQM), requirements definition (RD), technical solution (TS), product integration (PI), verification (VER), validation (VAL), project planning (PP), configuration management (CM), and a few others.

That’s not only how we know we’re confident in going live but also that we know we’re not 100% where we want to be.

We hope to be back up in “full production” of new blog entries over the next few weeks.

Be well!

Proper and Improper Use of CMMI

Posted by Hillel on Feb 2 2010 in Agile, Culture, Empowerment, Improvement, benefit, value | 2 comments

Just a few thoughts on some questions to pose as a sort of “guide” for whether or not you might expect benefits and value from using CMMI.  These also have the benefit of helping CMMI be implemented in a more lean/agile approach.

When implementing CMMI, Are you seeking . . .

  • Improvement or Compliance?
  • Empowerment or Definition?
  • Clarity & Awareness or Constraints & Rigidity?
  • Bottom-up input or Top-down direction?
  • To understand whether what you’re doing is working?  or Whether you’re doing what the process says?

In this case, we also value the things on the left more.

:-)

The things on the right are a longer road, with questionable benefits and many risks.  The things on the left get you to benefits and value sooner with less carnage and baggage.

Take your pick.

People over Process . . .

Posted by Hillel on Jan 24 2010 in Agile Manifesto, Audit, Coaching, Mentoring, Objective Evaluation, PPQA, People over Process, facilitation | 3 comments

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!

Do you have what it takes . . . ?

Posted by Hillel on Jan 17 2010 in benefit, commitment, honesty, learning, patience, respect, support, transparency, trust | 0 comments

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.

Contextually Relevant Experience & Why It Matters

Posted by Hillel on Jan 10 2010 in Context, Experience, SCAMPI, consultant, consumer, lead appraiser | 0 comments

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. . . .

Love & Marriage: CMMI & Agile Need Each Other

Posted by Hillel on Jan 6 2010 in Agile+CMMI, CrossTalk, Culture, Engineering, Experts, LoveAndMarriage, Professionals, SVC, Services, v1.3 | 0 comments

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!

Picking a Lead Appraiser: "Dammit, Jim! I’m a doctor not a bricklayer."

Posted by Hillel on Dec 27 2009 in Appraisal, Business Benefit, CMMI, Cost, SCAMPI, Time, consultant, lead appraiser, value | 2 comments

In this quote, CAPT Kirk wants Dr. Bones McCoy to do something he feels he’s not-qualified to do because he doesn’t know how to treat the species.

  

I’m using it to explain that organizations looking for a lead appraiser to work with them towards an appraisal and/or to perform an appraisal ought to think of what we do as they would think of a doctor, not a laborer or vendor. 

Do you really want the lowest price doctor?

For that matter, is the highest price doctor necessarily the best in town?

When reaching out and interviewing for a lead appraiser or CMMI consultant, you:

    • Want the person who is the right person for the job.

    • Want someone who is qualified (definitely not under-, but preferably not over- either).

    • Not the lowest bid.

    Seriously, whoever you hire for this effort has in their power the ability to make or break your future.  They literally have the health and well-being of your organization in their hands.  They can put you in the dump just as easily as they can take you to the next level.

    They should see themselves that way as well. 

    Unfortunately I’ve got too many sad stories of appraisers/consultants who definitely see that they can make or break you, but they don’t feel like they personally own the responsibility for what happens to you when they’re done. 

    If it costs too much?  So what?  
    If you get no value?  Not their problem.  
    Didn’t see any benefit?  Didn’t learn anything?  Things take longer and cost more and you’re not seeing internal efficiencies improve?
    YOU must be doing something wrong, not them.

    In an AgileCMMI approach, your CMMI consultant and/or lead appraiser would see themselves as and act like a coach, and would put lean processes and business value ahead of anything else.  And, an AgileCMMI approach would know that when the processes work, they add value; when they add value people like them and use them; when people like and use them, the next “level” is a big no-brainer-nothing.  You get it in your sleep.

    Let me know if you want help finding the right lead appraiser or consultant.

    Worse than Worthless . . .

    Posted by Hillel on Dec 20 2009 in Appraisal, CMMI, Discipline, Engineering, Prior Experience, Process, Process Improvement, SCAMPI, value | 5 comments

    Your people with prior CMM/CMMI experience are probably worse than worthless, they’ll probably cause you to fail.

    Why?

    Because what they (or you) think they (or you) know is probably wrong and the advice you’re getting, the expectations being generated are entirely off base.

    It all goes back to the many ways in which CMMI can be done poorly and the few, simple, but hard work ways in which it can be done correctly.

    Every time I meet with a new prospect I’m confronted with reams of inaccurate assumptions and assertions about what it will take to implement CMMI and how am I expected to “do all that” and still claim to be “agile”.

    My simple answer: I’m not going to do all that.  And, you shouldn’t be doing it either.

    Seriously, you’ve got to wonder about executives who will force their company into doing stupid things for the sake of a rating instead of doing their homework to learn about CMMI before they head out on an implementation journey.

    A recent client didn’t know any better.  They hired a consultant and an appraiser to evaluate their work against CMMI and to help them prepare for a SCAMPI appraisal.  Unfortunately, they got as far as the appraisal only to realize they weren’t going to get the target Maturity Level.  (I won’t get into some of the inappropriate behavior of the firm they hired.)

    However, when this client was confronted with:

    1. Do something stupid, or
    2. Find a better way to do something smart.

    They took option B and found a consultant and an appraiser who understood their context and found how to both be on a disciplined improvement path while also remaining true to their own business.

    Fortunately for them, this client had a strong engineering backbone and knew what they did worked and were confident in their processes.  Many companies have a while before they can claim that much.

    Next week:

    Picking a Lead Appraiser:  "Dammit, Jim!  I’m a doctor not a bricklayer."