*Sigh*... At the top, it's still a snail's world...

A lesson in marketing.

I've got an article in a local publication (Washington SmartCEO) which immediately garnered two highly qualified prospects, maybe more -- but until they contact me they're not in my queue. Each of whom can become significant sources of business.

You'd think I'd be thrilled.

Well, I am. Don't get me wrong.

Deep down, I'm still an engineer. I'm still a geek. And, I really see a brighter future for the world at large, and business in particular thanks to technology.

What never ceases to impress me is the enduring power of physical, printed matterial.
It also points to a reality about marketing that can never be ignored.

Even when your target audience/prospects/clients are themselves technology companies, it doesn't automatically imply that their leaders are as plugged-in as their employees. It also does imply that you must still seek to communicate to people in the manner in which they are most likely going to respond.

The down-side for technically-oriented business like mine and, I suspect, many of yours, is that we must therefore put our messages into many channels.

It seems that the CEOs of the market still rely on good-ol' burnable dead trees to do business, while so many of us are out here trying to make that mode obsolete.

I wonder what the connection to agile process discipline is... hrmmm... Don't answer that.

(P.S. The article may look familiar to those who've visited the CMMIFAQ.  It's just two of the FAQs combined into one.)

A fabulous conversation with Marcelo

This is long, but hopefully worth it.

I was recently contacted by a gentleman we'll call Marcelo about a dilemma he's facing at his workplace.  With his permission, here's what he says:

... my organization has projects which follow a formal Unified Process and they are CMMI compliant, but other projects use Scrum + XP, and are defintely not CMMI compliant.  I am in charge of the SEPG [software engineering process group] in the company, and I have difficult times when I try to instill some CMMI artifact in the agile projects.  They are all the time bragging about "Hey, check out the Agile Manifesto. It says Working Software over Comprehensive Documentation".  Then, I'm speechless.  I have no arguments to use except for "Yeah ok.  But CMMI requires it".  And that ends the discussion, and we cannot agree at all.  I know I should try to show the business value of every piece of documentation that is used, but hey, I've never read of Configuration Audits in any XP book!!!

I was wondering if you could give me some advice on this.

This is my response:

Do your agile developers value:
- their families over their cars?
- their free time over their jobs?
- their friends over their selfish needs?
- their lives over their money?

For most people, while there is value in the things on the right, they value the things on the left, more.

Agilists like to say that there is "less" value in the things on the right, but they act as if there is NO value in them.

The failure in agile philosophy is not that it is flawed.  It is simply poorly enacted.  Agilists who fail to comprehend the value in the things on the right of the manifesto tend to take a very short-term view of things that have value.  They tend to fail to lift their heads and look out beyond the confines of their projects and out to what adds value to the company.  A successful project adds value, yes.  Being able to run 20 projects concurrently of any size and composition and charge more than anyone else adds much more value.  What is it that can help the company grow revenues AND margin?

Ask them to scale their methods up to encompass a project 5 times their size.  Will it work?  What if the project is being worked on in 3 different time zones and continents?  Will it work?  What could they contribute towards creating an agile project method that performs as a mature process that can improve?  What if your company would lose all business if not rated as a Maturity Level 3?  What would they say if there were actual companies who were BOTH agile AND maturity level 5 ... or 3?  What could they contribute so that they can still be agile and mature of process improvement?

One thing you may be struggling with, unnecessarily, is the requirement for documentation.  There are no requirements for documentation in CMMI.  The need for documentation in CMMI is a remnant of an outdated way of implementing CMMI.   What CMMI expects is the ability to improve processes.

How can you improve a process if you have nothing to show for it while it's actually happening?  If you don't know what the steps are that you took to create a product and you don't know what step in the creation of the product failed?  Without some artifact of a process, it's quite difficult to improve it.  So, at most, CMMI expects that if a process is being performed that there be some type of tangible evidence that a process had "been there".

I argue that in true agile environments, and not just those giving lip-service to agile methods, they are generating such artifacts.  If for no other reason then to be able to communicate, to have a common lexicon, and keep track of the work.  When that's the case, you can then integrate a process improvement system, based on CMMI, into the routine activities.  And, in the agile philosophy, no more process than is absolutely necessary.

Take CM Audits as the example.  The purpose behind CM audits is to make sure that the CM system is working.  There's nothing more to it.  Everyone knows that when the CM system fails (either tools or people) to perform as expected, bad things happen to good code.  So, how does it not add value to check in on the CM system periodically to ensure that it's working?  That's all a CM Audit is supposed to be doing.

The key with CMMI is to understand the value of performing a process AND to understand enough about process design such that the process can be designed into everyday ordinary organic work.  Another key is to implement process efforts exactly as you would product efforts.  If you're using XP you'd need a user story for each process activity.  In Scrum it would be a task on the backlog.

Many criticisms of agile projects is the failure to look at the needs of the product that lie beyond the delivery date.  If there is no requirement for creating a "maintainable" product, then the failure is in the product requirements, not the product development methods.  Practices here and there in CMMI expect, in terms of process and artifacts, creating the ability for people at any point in the future of the product to return to a point during development and understand what was going on.  Why did they make that decision?  Why does this interface have this port?  How did they not plan for enough testing?

I heard of an agile-friendly CMMI consultant being confronted by an agile team who refused to take and store a digital photo of their white board design, claiming it didn't add value to the product, therefore it didn't add value to the project.  This simple photo would have been sufficient evidence of several CMMI practices.  But it wasn't until the same team was required to perform some act of maintenance on the product (I don't remember whether it was a bug fix, design change, or requirement change) that they realized how this simple photo would have added value by saving them (and their customer) days of analysis.

Referring to Alistair Cockburn's Agile Software Development, Marcelo points out,

... paper is the worst form of communication.  It is the coldest channel, and it conveys for more misunderstandings.  So, if you take this into account, and are part of an agile team, you would think "Hey, no more paper, we are all here, sitting together.  Let's maximize our face to face communication channel". And well, all the possible CMMI evidence expires into thin air.  No written plans, no audits, no minutes.  You would have to put a camera to record everything that took place in order to show evidence than the goals which are required by the model, are being implemented....

To which I also had an answer (no surprise):
(I edited it a little to include some insights from Marcelo's reply.)

I completely agree with Alistair.  ... ...

Creating a "paper" document *is* the coldest form of communication.  And by "paper" we both understand that a MS Word doc on the screen is hardly better than actual paper.  One significant reason is that paper is seldom written or organized well.  Besides, once written, paper cannot be easily/quickly modified to "speak" to more than one audience at a time.  Face-to-face conversations is far richer, far more adaptable, and can get more ideas across in less time with less need for re-translations.

The part I hear you struggling with is the one that equates "artifacts" with "documents".  And, I also hear that you understand that if a stand-up meeting in which all the practices are being performed doesn't generate artifacts of its own, that a video tape of the meeting could be the only evidence.  I also hear that part of your struggle comes from the perspective of artifacts for a SCAMPI vs. artifacts for the capability to perform process improvement.

My approach has me looking for artifacts that indicate the capability to perform process improvement.  If I can find some outputs of a process on which I can perform process improvement, then these are the very same things on which I can perform a SCAMPI.  I am much less likely to find what I'm looking for if I look for things from the perspective of the SCAMPI rather than from the perspective of process improvement.  Taking my approach adds value and people can sign-up to it.  Taking the SCAMPI-focused approach causes skepticism and cynicism about process improvement.  People *see* that the activity is oriented towards the appraisal rather than at process improvement.

Here's where I assert some challenges to the agile community:

Want to know what's WEAKER than paper?  Humans.

Human hearing and memory is far weaker than artifacts.  If no record of what's been agreed-to at a meeting exists, how can anyone hold anyone else accountable for doing what's expected of them?  I challenge the assertion that no records exist resulting from such meetings.  If nothing else, people take some action from a meeting and do some task.

Also... how do people account for their time?  How do they track issues?  If accounting for time or issue tracking is so loose that all time on a project and all issues, regardless of what that time is being spent doing and or the severity of the issue, is accounted for with the same detail (that is, without any detail), then how does a project know when re-work is taking place or when resources must be re-allocated?  If a project accounts for re-work the same as accounts for original work, then it can't honestly say that it knows its own error rates or project efficiency, can it?

Even if people leave a meeting and go code with no other activity in-between, what they did in the code should have some reflection of what comes out of a meeting.  I have a very hard time seeing how developers can claim to be developing a product THAT CAN BE MAINTAINED without creating some sort of trail of bread crumbs.  I really don't care how big the bread crumbs are or what kind of bread or even how closely spaced the bread crumbs are... they must exist.  I've never heard of a company that knows what it's doing and has no record of having done it.  On the other hand, I know of countless companies who don't *realize* that they have such a trail of evidence.  Otherwise the product cannot be maintained, or in some cases tested, or even usable by the client.  Our challenge is to help the developers recognize the bread crumbs for what they are and to help them take advantage of them.

If the goal is to create a product that will not be maintained, that will be thrown away after first use, then the important question to ask is, why bother trying to create a managed process (Capability Level 2) around creating it?  A performed process (Capability Level 1) would be sufficient.

If, at the beginning of a project, all of the project's activities are laid-out, such as the frequency of meetings, the content of meetings, the assignment of resources and responsibilities to tasks, then I would submit that in such an activity not only constitutes "planning" but it also can withstand the test of the SCAMPI's need for evidence, when backed-up by affirmations.

I go back to my original assertions: if looking beyond the immediacy of a pending delivery is important to an organization, then even agile organizations will have to figure out how to incorporate the barest minimum from the things on the right into the things on the left in order to accomplish objectives greater than just delivering their single project on time.

New stuff...and some substance

There are new items on the CMMIFAQ ... and ... it's got a WHOLE NEW look!

I've hosted the FAQ on its own domain and eliminated all but the barest references to my company.... and soon hope to eliminate even using my company's contact forms for folks to contact us with questions. After all, the site is meant as a public service, not a billboard.

Lemme know what you think of the look!

There are two new items which answer questions about (1) what it is that gets the level rating when an organization is appraised, is it the entire company? If not, what then? And, (2) how many project are required to be appraised to represent the scope of the organization that is being appraised.

Now for the substance of today's submission...

It's a rather simple truism about process and agility, but it comes directly from a discussion with one of my clients:

A company can grow a lot without any processes or a process improvement system in place.  And, a company whose processes are too heavy might not be able to grow as easily, if at all.  The problem is, if the processes are not disciplined or robust "enough", then while the revenues may grow, the margin will likely shrink.  (For the non-business people, that means you're generating more money in sales and billings, but your profit is shrinking.) In some cases, you even start to lose money.

In discussing agile methods, we arrived at the following:

Some agile philosophies promote the idea that projects should not do any effort that doesn't add immediate value to the product, and thereby to the customer.  This philosophy will frequently target processes and process improvement as their example of things that don't add value.  However, there are two challenges to this concept that appear when you simply take a long-term view of the result of processes.

A long-term view would see that processes and process improvement are an investment in the ability to deliver a better product, more of it, in less time.  This is a clear benefit to customers.  This view also has a business value which is realized when the company can grow in both revenues and margin.  The value of the company's work goes up, and the company can then charge more for what it does.

Developers (engineers, technical folk) frequently have a tendency to charge what something costs.  Business people will tell you that a company should charge what someone is willing to pay, and that is *value*.  Charging for services based on value is better than being a commodity.  Process improvement increases your value.

Think of it this way:  many people will agree that switching from big-plan-up-front to something more agile is a good thing for everyone involved.  Is that not process improvement?