Thursday, March 21, 2019

Are projects more predictable with the CMMI?

Welcome back to Ask the CMMI Appraiser for today’s installment of CMMI User Stories!

In response to the demand for information in the industry (What does the market think about the CMMI today?) we are sharing our study of what CMMI users really think about the CMMI.

The study consists of surveying over 70 CMMI users and asking them about their experiences with the CMMI, good and bad. Here’s our first question:

Are projects more predictable with the CMMI?

As more organizations around the world pursue the value that frameworks like the CMMI and Scrum are intended to provide – higher quality products, faster delivery, and predictable, repeatable results – it is not always clear that the benefits are being realized. Measuring a quality such as predictability can be an inexact science.

In our survey, eighty-two percent of respondents indicate that projects are more predictable with the CMMI (up from eighty percent in 2012).

Be sure to check back regularly as we share results of the CMMI User Story Report right here on Ask the CMMI Appraiser.

We’ve also made the information available in an eBook. If you would like to receive the complete set of user stories in the final Report, click here to access your free* copy.

*$9.99 on Amazon

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI training classes and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Visit for more information about running a successful CMMI program.

Wednesday, March 13, 2019

My Book "Great Big Agile" spotted at South-by-Southwest 2019!

Attendees at SXSW2019 got to check out my new book, Great Big Agile this week, courtesy of my great publisher Springer Apress!

Tuesday, March 12, 2019

What does the market think about the CMMI today?

What does the market think about CMMI?

Yes, that’s still the million dollar question, isn’t it?  Since the last time we did this survey seven years ago, we’ve seen a spin-off to the CMMI Institute, new leadership, new staff members, a fresh marketing approach, and the introduction of the Model upgrade, CMMI V2.0.

Much has changed. But have perceptions changed? To find out, we commissioned the second User Story study. Seventy-seven companies were randomly selected to participate rom the CMMI Institute’s Published Appraisal Results (PARs) All had achieved at least CMMI Maturity Level 2 between 2015 and 2017.

The reason we chose this timeframe was to give the CMMI users some period of time since adoption, allowing for more objectivity.

The survey went out to CEOs, VPs and Quality Assurance Managers of North American companies, large and small. Companies were in the aerospace, defense, finance, transportation, energy and manufacturing industries, and they were all using CMMI-DEV.

We listened to the stories they told about using the CMMI. We captured the data, and analyzed the results.

Like its predecessor, the second edition of the CMMI User Stories Report builds its case on anecdotal data from actual end users. We gathered stories about what’s working and what’s not working with the CMMI, directly from the users themselves.

We will begin posting the results later this week. You are invited to check back regularly as we share results of the CMMI User Story study right here on Ask the CMMI Appraiser.

We’ve also made the information available in an eBook. If you would like to receive the complete set of user stories all at once, simply click to download the free* version of the eBook.

*$9.99 on Amazon.

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Visit for more information about running a successful CMMI program.

Thursday, February 21, 2019

How can I become a CMMI Badass?

Hey, CMMI Appraiser, how can I become a CMMI Badass? ~ Joey T.

Hey, Joey - the latest class of CMMI Badasses is officially trained, certified, and riding to a town near you!

What is a CMMI® Badass?
  • A CMMI Badass knows the CMMI is a way to super-charge performance, not a test to be compliant with.
  • A CMMI Badass understands that CMMI give you more control over the way you do your work.
  • A CMMI Badass knows that changing your company can't be done with a tool that promises “CMMI compliance in six months or less."
  • A CMMI Badass doesn't care about certificates or "plaque buildup."  It's about the rush of high performance.
  • A CMMI Badass knows that "creating evidence to pass" is a huge waste of time
  • A CMMI Badass knows why the company is adopting CMMI
  • A CMMI Badass captures data about whether or the team is benefiting from the CMMI.

Want to become a CMMI Badass? For the latest training in CMMI v1.3 or CMMI V2.0, you can join the CMMI Gang by signing up for one of our high-speed training classes. Check out the CMMI Badass site here:

See you in class!

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, Certified Agile Assessor, author, keynote speaker, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI training classes and has received an aggregate satisfaction score of 4.97 out of 5 from his students. His new book, Great Big Agile: an OS for Agile Leaders (© 2018), is now available on Amazon.

Visit for more information about engineering strategy, performance innovation, software process improvement and running a successful CMMI program.

Tuesday, February 12, 2019

What are Representations in the CMMI?

Dear Appraiser,

What are Representations in the CMMI?

A “Representation” in CMMI is a way of looking at the data in the CMMI model and using it to evaluate performance.

Currently, there are two such “representations.” Staged and Continuous.

The “Staged Representation” organizes the twenty-plus process areas in the model by “Maturity Level.” In other words, there is a pre-defined set of process areas that go together for each maturity level, starting with 2 and going through 5 (no, there isn’t a Level 1 in the Staged Representation).

If a company wishes to improve using the guidance from Maturity Level Two, there are seven Process Areas to choose from in CMMI-DEV, and 8 in CMMI-SVC, and an associated set of 10 “Generic Practices,” which you can think of as the “secret sauce” required for successful implementation. After that, the number of Process Areas and Generic Practices increases (the number is dependent on which version of CMMI you are using).

Using the Staged Representation allows an organization to achieve a “Maturity Level.”

The “Continuous Representation” doesn’t have Maturity Levels, and in this version the Process Areas are organized within categories (Project Management, for instance) instead of Maturity Levels. You can pick and choose the ones you want, and if you want to “get a level” you can do it in one (or more) process areas by coupling it with the Generic Practices.

Using the Continuous Representation allows an organization to achieve a “Capability Level” in one or more areas.

So the difference between the two is simply in 1) how they are listed in the book and 2) how you can “get a level.” Simple!

Enjoy - and check my site at

What Makes the Scrum framework "Agile?"

[Dear Readers, here is another cross-post from the fun I've been having over at Quora this year!}

What Makes the Scrum Framework "Agile?"

I’m probably going to get flamed here, but the real answer is “nothing.”

Don’t get me wrong - Scrum is an awesome approach for getting work done, and it does spring from the “agile community.” But methods like Scrum, XP, Kanban, etc are not, in and of themselves, “agile.” Although, they are related to it and can support, it.

In order to appreciate this position, consider that Agile isn’t a method or framework at all. It’s a state of being.

Before you click over to another page because of the “warm-and-fuzziness” of that statement, consider that Agile was a reaction to the mechanization, over-processing, and de-personalization of corporate IT, which was going about the business of building software “factories,” and reducing software developers down to the lowest-cost lines of code that could be purchased on the global marketing (jeez, it sounds so evil when I put it that way!).

The result of this was, predictably, terrible software that was not only expensive, but didn’t do what the user wanted. One CIO friend, who knew it was bad but didn’t really quite get the reason for it, lamented “If I’m going to get crap, I want it cheap!” Obviously, not one of our best examples of technology leadership!

“Agile” is a social movement that leans heavily towards the following values: Trust (above all the others), transparency, collaboration, learning, and a positive, safe, and supportive work environment. Sounds great, right?

Well, it can be. But it doesn’t happen in a vacuum, and as it turns out people don’t naturally behave that way. That’s where Scrum comes in.

Scrum is a framework which demonstrates “Values Traceability.”  In other words, all of the ceremonies, techniques, and roles within Scrum are there BECAUSE of the values.

  • How do you promote “Transparency?” Have a daily standup, a scrum board, and sprint retros. 
  • How do you promote “Trust?” Involve you customer in sprint planning and sprint demos so they are part of the process and learn to trust your ability to deliver.
  • How do you collaborate?  Include your customer in backlog grooming, spring planning, and story writing

In other words, Scrum is a framework designed to get work done within the architecture of Agile values. Same for the other lesser used but equally powerful frameworks like XP and Kanban.

But - and this is a big but - there’s a massive hole in the model. The very people that CAUSED the agile movement to start (senior leaders) aren’t necessarily on-board, and there has not, until now, been a framework for them. And without THEM, none of it scales.

That’s where the Agile Performance Holarchy (APH), comes in. You can find out more about that in my book Great Big Agile: An OS for Agile Leaders here:

GBA is all about values, objectives, actions, and ceremonies for LEADERS to help them build, sustain, and evaluate agile performance using agile values.  Think of it like Scrum, but for leadership.


Tuesday, February 5, 2019

When is NOT a good time to use Agile Methodologies?

Question: When is it a BAD time to use Agile Methodologies?

“Agile Methodology” is a pretty broad term, so I’ll make an assumption and assume you meant something like Scrum, XP, or Kanban. “Agile,” is generally thought of as a set of values and an approach to working together, but it has spawned a number of frameworks that are based on this vision, and many people use those terms interchangeably.
It’s a great question really. A lot of people decide to use agile just because it’s hot, popular, or they’ve heard that it’s better, but it’s really something you should consider before making a choice like that. This is because it affects more than just your team.
Warning size where Agile would NOT be successful are:
  • Your management (or customer, or both):
    • Your management (or customer, or both) are extremely controlling,
    • They don’t have a hire degree of trust
    • And they like to tell you how to do your work
All agile frameworks, and “being agile” itself, requires a high-trust environment. I don’t mean one where your management leaves you along or ignores you - they need o be involved - but one where they let you figure out how the work gets done.
Other warning signs are:
  • Team members don’t like sharing information regularly about their current work
  • The requirements are well-known and well-documented in advance, and changing anything takes an act of god (I’m talking to you government).
  • It’s impossible to co-locate, or at least have a place to gather regularly to share information, ideas, and brainstorming
But - there are many GOOD reasons to adopt agile. You might check out “Great Big Agile” on Amazon. It takes a look at organizational agile and covers a lot of these topics.
Good luck!

Saturday, January 19, 2019

Do federal agencies distinguish between CMMI services or development for solicitations?

I’ve been a CMMI Lead Appraiser for over twelve years, have done hundreds of appraisals, and work closely with government agencies and contractors. 

I have never seen an RFP or solicitation that differentiated between CMMI -DEV and CMMI-SVC. Most that I have seen use outdated information, refer to older, sunset versions of CMMI, and don’t even seem to know the SEI spun the CMMI out to another company in 2013.
It all seems like boilerplate. That said, most of the solicitations that require CMMI are for technology-oriented (primary SW) companies, not services companies.
Good luck!

Sunday, December 30, 2018

Why do CMMI Appraisal costs vary so widely?

"Your price is 120% higher than the last guy that was in here!" the potential client cried, "what's up with that?  Shouldn't a SCAMPI A be the same from each Lead Appraiser?  I mean, IT'S A STANDARD for heaven's sake!"

Not being my first rodeo, or nearly the first time I'd heard someone say this, I just sat back, smiled, and asked her " What are you trying to accomplish, really?  I'm not talking about the 'level," I mean what are you really trying to do here?"

That caught her a little off guard.  "What do you mean, 'accomplish?'  None of the other guys asked me that.  They just gave me a price."

Ah ha.....

There are a lot of reasons for differences in pricing.  Quality of service, obviously, is one.  Experience.  Credibility. Timing, size, and most importantly, business goals.  That last one is a little harder to predict.

"But I thought my business goal was to get ML3?" my potential (and future) client stammered.  "My boss told me I needed to get it by the end of the year or else I wouldn't get my bonus."  The poor lady seemed pretty frustrated with me, and appeared as if she was about to throw me out and hire the cheap guy from Appraisals-R-Us.

"Why do you think your boss wants you to get this? I asked.

"So we can bid on government work!" She answered.

"And the government wants you to be CMMI ML3 because.....?" I quickly added.

"uhhhh.  I'm not sure, It's just an RFP requirement" she replied.

"Look,  I'm sure the government's reason for asking you to do this has nothing to do with yet another plaque on your wall in the lobby ('Plaque Buildup'), but has EVERYTHING to do with ensuring that your company can handle what's about to happen should you win one of those sweet IDIQs.  They want to make sure your process systems can handle the stress, and deliver results."

"OK," she said. "But how does creating a bunch or process and documents help me do that?"

BINGO!  They don't!

They only help you pass an appraisal (maybe), but it's not nearly enough.  For true performance improvement, you need an expert in BOTH CMMI and Performance on your side.    The appraisal itself is perfunctory - a single event, a moment in time, a gate to get through.  The harder, more valuable stuff comes long before the appraisal.  But the time the appraisal comes you should have already won.

It's kind of like that movie "Rocky."  You could have  skipped right to the fight with no manager (which Rocky considered), participate in the fight, and get beaten badly (worse than he was!).  Or you could be more like the famed "Italian Stallion," who took his training to heart, made the hard choices, ran all his steps, and savored victory while bounding up the steps of the Philadelphia Library and doing his victory dance.

He had already won by that point!  We knew the rest.

Image result for RockyAnd that's what you need to do with CMMI.  Work with someone who will take you to victory long before the appraisal event occurs.  The appraisal should be a non-event for you, not something you prepare for.  It should be more "bring it on" than "I hope we pass!"  "Passing" should never be part of your aspiration or goal - greatness should be.  Of course you're going to pass - you're now an awesome company!

There are some Lead Appraisers who don't get this - too many, actually.  They're satisfied to leave it to you, just conduct an appraisal, give you a certificate, and walk away without providing any valuable advice or insights.  But a great Lead Appraiser is an advisor and counselor, as well as a mentor, coach, and teacher who knows that the path to greatness lies on the far side of innovation, hard work, and discipline - and has the ideas you need to make it happen.

Don't waste your time with someone who doesn't get that.   That's WHY they're so cheap.

By the way, here's what to look for in a great Lead Appraiser:

- Has proven Experience
- Understands your methods, tools, and domain
- Understands your business
- Is comfortable interacting with Senior Management, as well as all levels of the company
- Freely offers ideas and techniques for improving working conditions and processes
- Is a teacher, coach, and mentor - not just a "consultant" who tells you what they think you should do
- Takes time to brainstorm ideas and solutions to your biggest problems
- Offers other valuable insight and ideas for business problems you are having

Best of luck to all of you, and here's to a great 2019!

Sunday, December 23, 2018

Dear Readers: My new book, Great Big Agile: An OS for Agile Leaders is out, and you can get it on Amazon!  Here, just for you, is a totally free sample!  If you like this, please go to and get your own, personal copy.  If you bring it to a conference where I am speaking or attending, I'll be happy to sign it for you!

Preface: Great Big Agile

I wasn’t always a technologist.  In fact, I was the furthest thing from it.

My childhood was a little different than most of my friends.  By eight years old, I was touring in our family’s music group, joining my parents and three siblings as the bassist for the Dalton Family Singers, a traditional American Folk Music group that performed up and down the North American eastern seaboard from 1968 to well into the 1980s.  It was so “normal” for me that I used to ask my friends where their family was touring this summer!  The “Singers” was my father’s brainchild, who reasoned that a family music group was the perfect incubator for his musical children, and also an opportunity to practice and demonstrate to us the entrepreneurship required to run a successful entertainment franchise in a crowded market.  Before the internet and Twitter there was my Dad with his Typewriter, press releases and corded phone.

Following those years I attended formal music school, first at the internationally recognized Interlochen Arts Academy, and then the Peabody Conservatory of Music in Baltimore (now part of Johns Hopkins University).  I cut my studies short at Peabody to spend the next decade honing my craft as a concert double bassist with orchestras in Spain, Mexico, and the United States.

What did I learn during those years?  Craftsmanship.  Discipline.  Collaboration.  Transparency.  Perfection.  Persistaece.  Ceremony.  Value.  And also how to self-subscribe and commit to excellence while working together with over one-hundred other artist under the direction of a conductor to create some of the most sublime music known to mankind.  It’s a pretty good model for agility.

The other important thing I learned was the art of the retrospective.  Notthe standard retrospective we usually see in the typical agile teams, one of “what went well, what didn’t, and what could we do better” with some people participating, and some grumbling a few perfunctory comments, but a comprehensive and sometimes brutal process that kept many music students up at night – known as “Juries.” A CEO friend of mine, who also happens to be a musician and a visual artist himself, told me a story about his juries while attending art school in Pittsburgh.  I recollect it went something like this:

“Juries in Art school are brutal! They start right away during your freshman year don’t stop until you’re done.  Both your teachers and fellow students critique your work in public, and most of them don’t hold back!  Those were tough times, but their real value is that you get used to the criticism, and your aversion to being evaluated melts away before long, letting you really focus on what’s important – getting better!  You also make sure that your next jury is as perfect as it can be!”

In the art world, where most of us aren’t Mozart or Salvatore Dali, we know that the capability to be creative and innovative only comes after the hard work has been done.  Not until the scales have been perfected, the arpeggios have been practiced until the fingers bleed, the concertos have been memorized, the music theory classes have been completed, and the performances have exceed the pre-requisite ten-thousand hours, can we break the rules, experiment, innovate at a world class level.  Only after we stop thinking about the process can we create something new, innovative, and exciting.  Agile isn’t any different.  In many ways embracing agile requires the same commitment as a career in music or art – where rigor and discipline are paramount, not just coding.

If this sounds like a systemic program to build a solid foundation for quality and early defect detection, while embracing a culture of excellence for continued high performance, it’s because that’s exactly what it is  In fact, trained musicians, artists, and dancers entering the technology workforce have a significant advantage over new engineers and software developers who don’t have this experience,– and it’s the reason we often here that “musicians make good coders.”  It’s not because “music is math,” by the way, it’s the culture.

The first development team I ever led was building solutions for the international retail market, and we were creating world’s first touch-screen point-of-sale system. My second official act, after helping the team to establish much needed discipline around coding standards,  was to implement “juries:” public, collaborative, and transparent code reviews with the code projected larger than life on a ten-foot screen with the entire team in attendance.  Team members were asked to present, and defend, their design and coding decisions.  At first the team resisted with all their might – and who wouldn’t?  It was nerve wracking, uncomfortable, and stressful.  But by the second month of doing weekly reviews, the code quality went up dramatically and the team went from combative and defensive individuals to an innovative, transparent, and collaborative team.   This was 1994 – long before “agile” and values were in the headlines.

My journey from musician, to software engineer, to CEO has been one of many twists and turns, but the most important concept I’ve learned to harness along the way was “innovation lies on the far side of rigor.”   While we all believe ourselves to be innovative and creative, few of us are able to commit to the discipline to make ourselves world class performers.  But the proven lessons from music can help us get there.

This idea of foundational craftsmanship and relentless improvement found in the music industry can and should extend to the parallel universe of software development, where adoption of agile values and frameworks are akin to music theory and were designed specifically to foster innovation, experimentation, and continuous learning. So far this level of performance has mostly eluded very large organizations in the government and private sector who want to “go agile,” but adoption of agile values along with an operating system for agile leadership can help.

But all is not well in the Land of Agile either. Many large adopters are struggling to achieve the results they expected, team members are often uncomfortable with the ambiguity inherent in agile projects, line managers don’t know how to lead in a high-trust self-organizing teams, and business customers complain that they have to spend too much time working on the project without getting the return on investment they were promised.  In some cases, CIO’s are finding it so complicated that they are now forbidding the use of Agile altogether!  But, in every leading magazine, from Harvard Business Review to the Cutter IT Business Journal to CIO, and in every major survey, including Version One’s “State of Agile Survey,” we learn that the responsibly of these, and other issues related to limited success with large-scale agile adoption, rests squarely on the shoulders of leadership.  My own observations from over two-hundred agile assessments confirm this.  While leaders are telling their teams to “be agile,” they are not themselves adopting, practicing, and projecting agile values.  This creates an organizational type mismatch where leaders are practicing their hard-earned command-and-control techniques, and teams are trying to self-organize in what is inevitably a low-trust environment.  If you were a leader who spent their entire career learning to navigate in a low-trust environment, would you give it up that easily? This leads to chaos. 

                     I am lucky enough in my work to collaborate with some of the greatest agile  organizations in the world in my role as Chief Evangelist for, a research and development organization who’s focus is on performance models and assessment methods for large agile organizations.  Through that work I have observed that:

Agile ceremonies often devolve into “water-scrum-fall” with scrum masters tasking team     
members, sprint durations changing based on workload, team members moving in and out
of teams, and story points being normalized between teams as hours.

  •  Leaders continue to resist high-trust, self-organizing values 
  • Product Owners are often “IT surrogates,” negating the value of the business owning the risk and ROI of the product.
  • Retrospectives are rarely conducted beyond the individual agile team community 
  • Team members and leaders are not sufficiently trained in the rigor and discipline of agile ceremonies
  •  Leader don’t know what “agile looks like,” and are unable to verify that teams are embracing agile values, ceremonies and techniques in a way that makes sense for the business. 
  • Traditional, often punitive metics are still being used, adding little value to the organization. 
  •  Teams and leaders often “experiment” their way into chaos by eliminating or severely distorting the intention of the ceremony or technique they are using

I was inspired to write this book while thinking of my experience as a professional musician, and how it informed and affected my own performance and thirty-year technology journey that started as software developer, and then rapidly moved to project manager, architect, Chief Technology Officer, Director of Product Development, VP of Global Consulting, CIO, and finally CEO of two of my own technology companies. 

I wanted to provide agile leaders with those lessons in an illustrated guide that defines objectives, outcomes, and actions needed to successfully lead large-scale agile organizations. The resulting model, the Agile Performance Holarchy, is an implementation guide to bring solid Craftsmanship, Discipline, Collaboration, Transparency, Perfection, Persistence, Ceremony, and Value to your organization.

So join me in reviewing the scales, arpeggios, and concertos, and building a foundation of discipline and rigor in order to establish a sustainable and high performing agile organization.

This book is about my own journey to excellence – I hope it helps you too!

You've been reading a sample from Great Big Agile by Jeff Dalton. If you like what you read, you can purchase Great Big Agile: An OS for Agile Leaders on Amazon, Barnes and Noble, or directly from the publisher at

Thank you for reading!


Wednesday, December 12, 2018

Happy New CMMI Year!

Dear Readers,

The New Year will bring many new CMMI opportunities for engineering and software leaders and professionals, and this CMMI Appraiser is excited to help you take advantage of it all! Whether you need training in the new CMMI 2.0, CMMI v1.3, or Agile/CMMI integration, feel free to check out our slate of popular CMMI and Agile classes in 2019.

See more info below! 

Class Title: Introduction to CMMI-DEV v1.3

Location: Washington, DC area
Date: February 19-21, 2019

Class Title: CMMI V2.0 Instructor Led One-day Upgrade Class

Location: Washington, DC area
Date: February 22, 2019

Class Title: CMMI-DEV V2.0

Location: Washington, DC area
Date: April 1-3, 2019

Class Title: Agile/CMMI Integration Workshop

Location: Washington, DC area
Date: April 4-5, 2019

See you in class!

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, Certified Agile Assessor, author, keynote speaker, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI training classes and has received an aggregate satisfaction score of 4.97 out of 5 from his students. His new book, Great Big Agile: an OS for Agile Leaders (© 2018), is now available on Amazon.

Visit for more information about engineering strategy, performance innovation, software process improvement and running a successful CMMI program.