Jeff: Policies? We’ve got BINDERS full of ‘em [1]. And when you wipe the dust off of them they even shine up all nice and pretty-like.
As to whether this is “sufficient,” I assume you are asking “is this evidence sufficient to demonstrate we are performing this practice?”
I have no idea, but I’m skeptical [2].
Sometimes when people are adopting a process model like CMMI, they focus on the wrong things. Instead of considering the business reason that the practice is present to begin with, they attempt to reverse engineer it starting with the words and artifacts themselves. This seems clever at first. After all, the practice says, “Establish an Organizational Policy.” How hard could that be? We have the binder; end of story.
As it turns out, getting value out of policies is harder than it sounds.
The reason we have policies is to communicate what we expect people to do. But we can’t do that without understanding the “who, how, and what” of the expectation. [3]
It helps me to better understand the business value of GP2.1 (and others) by first establishing a set of model-agnostic User Stories that are designed for each end user, and then flipping that into a series of questions that need to be answered.
So, “Establish an Organizational Policy” within VER for software engineers might become:
As a Software Engineer
I need to perform code reviews
So that I can capture defects earlier and build great software products
Some people may be satisfied with that, but I think it raises more questions than it answers. To really understand what is expected, we need to go deeper. Hence the question(s):
• “How am I supposed to conduct code reviews?”
• “What is the company trying to accomplish?”
• “How much time/money should I spend on this?”
• “What is the code review experience expected to be?”
• “How do we know we are meeting expectations?”
It might be a simple matter to develop a code review process and tell everyone they have to follow it (well, simple enough to just tell them) but unless that process is tied to the true expectations of our organization how do we know we’re doing the right thing? Like artifacts, the behaviors behind our actions matter, and the presence of actions alone does not mean we are meeting expectations (or that we are “sufficient”). We have to be aligned with something.
When I conduct appraisals I like to explore the three primary components of a policy: Vision, Values, and Expectations. These three components are a trio and cannot add value without alignment.
A Vision is a statement of who we want to be, and exists at the company, organization, program, product, and team level. It is the baseline from which all behaviors are derived. An example of a Product Vision might be:
• “We will deliver the highest quality data compression product on the market that will sell at a premium price.”
OK, that’s a great start. I know what our process needs to support, but I need a little more.
Values describe how we will behave:
• We will trust our teams
• We will strive for transparency
• We will collaborate closely with our customers
• We will treat our suppliers like partners
Or, maybe we want something a little more “traditional” [4]:
• We will maintain strict “command-and-control” at all times
• We will manage tasks down to the hour and expect daily status reports
• We will limit communication with our customers
• We will maintain an adversarial relationship with our suppliers to keep costs as low as possible
I’m already feeling some misalignment between the second example and our Vision Statement. I call that an “organizational type-mismatch,” and too much of this will lead to eventual failure.
The 3rd component of a policy is expectations. Expectations help us understand what we will do to achieve the vision while still maintaining our values. Returning to our code review example, some expectations might be:
• We will hold iterative and incremental code reviews every two weeks
• We will invite our customers, managers, and other stakeholders
• We will record defects we find so everyone knows to avoid them in the future
• We will not focus on blame, but how to improve the process so a particular defect doesn’t happen again
In this example, we have direct traceability from our expectations, to our values, to our vision. This gives software engineers a crisp and clearly defined roadmap for designing a code review process that meets the needs of our company, organization, product, and team.
I’ll leave the media to you, but we know a dusty binder organized by Process Area and signed by the line manager in 1972 isn’t the answer. Instead, consider multiple media platforms including WIKIs, online and classroom training, all-hands meetings, newsletters, and performance reviews, and use your binder (or an undiscovered folder in SharePoint) as a backup.
To summarize: who are you, how will you behave, and what will you do to succeed?
End notes:
1. Thanks for the quote, Governor Romney!
2. I was going to say “It depends,” but that was never very funny.
3. I know this is shocking to most of you, but companies regularly don’t know what they are doing, or why they are doing it.
4. When I wrote this sentence, it seemed like this company would be an awful place to work…unfortunately it’s what of the 90% of companies in the world are like.
© Copyright 2015: Process Assessment, Consulting & Training and Broadsword Solutions
“Just the FAQs” is written/edited by Pat O’Toole and Jeff Dalton. Please contact the authors at pact.otoole@att.net and jeff@broadswordsolutions.com to suggest enhancements to their answers, or to provide an alternative response to the question posed. New questions are also welcomed!
Visit www.broadswordsolutions.com for more information about engineering strategy, performance innovation, software process improvement and running a successful CMMI program.
