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:

www.cmmibadass.com

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 www.broadswordsolutions.com for more information about engineering strategy, performance innovation, software process improvement and running a successful CMMI program.

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 www.broadswordsolutions.com

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: https://amzn.to/2By1VWd

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.

Enjoy!

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!