As the new host of the SEPG Conference Series, the CMMI Institute is pleased to announce that SEPG North America 2013 will be held at the David L. Lawrence Convention Center in Pittsburgh, Pennsylvania, on October 1-2, 2013. As the host of the SEPG North America conference, the CMMI Institute is thrilled to welcome a worldwide community of professionals to its home city for two days of high-quality learning and networking. The conference will deliver high-value, practical information to end users and practitioners and will offer excellent opportunities to connect with others in the performance improvement community.
The CMMI Institute and the SEPG program committee are working quickly to be able to announce information on speakers, registration, and more.
Hey, CMMI Appraiser, in my last company, we tested all of our new processes before deploying them. My new boss doesn’t think piloting is necessary, and I don’t have any hard data or evidence to fall back on. What can I say to change her mind? ~ Kim L.
Hey, Kim– great to hear that you are being an advocate for pilot testing in your new company! Helping people transform company culture with CMMI is an area of expertise of Laura Adkins, a Senior CMMI Consultant with Broadsword. Laura does amazing work with companies who are trying to institutionalize new processes within the Agile and CMMI frameworks. Take it away, Laura! ~ The CMMI Appraiser
Kim, hard evidence can be gathered to prove the value of piloting in your organization. But rather than trying to convince your boss with a lot of facts and data, I’d recommend telling her a story.
I call it, “The tale of two companies …”
Once upon a time, there were two companies: The Foolish Company and the Wise Company. The Foolish Company believed they needed to achieve CMMI Maturity Level 3 right away. So their quality group got to work designing the Foolish Company’s new CMMI-based processes. They didn’t have time to consult process users. Instead, they went forward designing large volumes of process assets, and immediately deployed them to all of their process users.
The Foolish Company chose to build their process on a foundation of sand because it was much quicker.
Now the Wise Company had a different approach. The Wise Company was a good company that wanted to be great. After learning about CMMI, they selected it as their process framework because they believed in the model’s best practices. The Wise Company commissioned small groups of employees to define processes that would improve their performance. These small groups designed processes iteratively so they would be “Just Enough, Not Too Much”. Before deploying their new processes, the Wise Company tried them out on projects of varying sizes and types.
The Wise Company chose to build their process on a foundation of rock because it was much stronger.
The Foolish Company, which chose to build its process on a foundation of sand, because it was much quicker, didn’t take the time to pilot test their processes before releasing them. The team tried to use the new processes, but found defects and areas that they missed. After just a few weeks, the Foolish Company realized that their processes were not designed for small software maintenance projects. Since the Foolish Company is primarily in the business of performing software maintenance, they had to go back and re-design their processes to meet the needs of small projects. Months later, they were still in the rework mode …
The Wise Company, which chose to build their process on a foundation of rock because it was much stronger, spent time pilot testing their new processes on projects of varying sizes and types. The Wise Company listened to their pilot participants and made the changes they suggested. The Wise Company caught some areas that needed to be changed, implemented the change, and are going forward with the deployment, releasing the new processes with confidence that they will work.
Ask your boss: Which company are we going to be?
The real value of pilot testing is it helps accelerate the institutionalization of new processes. By planning and conducting a process pilot, your company can use the feedback from pilot process-related experiences to update your assets … and be a Wise Company.
Encourage your boss to look back through our blog posts on pilot testing, Kim. We hope we’ve shared enough tools, tips and guidance on validating process that the value of testing will be clear. If you need any more help convincing her, you know where to find us!
Like this blog? Forward to your nearest engineering or software exec!
Recently, I presented two Webinars on topics of growing interest to software and systems engineering executives and professionals who are seeking out new strategies, tools and techniques that can help them establish the type of environment that can make them a great company.
If you missed these Webinars, or would like to view them again, here’s your opportunity! The replay recordings are available for viewing on your own time and at your own pace. (And they are still free!)
To watch and listen to the recordings, presented by Broadsword and attended live by software and engineering professionals from companies large and small, around the world, click the following links:
By watching the replay of the “CMMI: Everything You Need to Know” Webinar, you'll gain an understanding of the popular Capability Maturity Model Integration (CMMI), and learn about answering what I call
as an engineering strategy for addressing common business problems such
as late projects, over budget projects, unhappy customers, etc.
By watching the replay of the “Agile Resiliency” Webinar, you'll be introduced to the concept of using the CMMI as one of the tools that can make agile stronger by building a resilient agile architecture. In this Webinar, I lay out my vision for how the entire family of Agile methods can be made resilient and strong through the application of the CMMI.
Designed specifically for executives, engineers and business professionals, both Webinars help you learn to think about the CMMI as a set of guidelines you can use to create an environment in which the organization can manage its uniqueness in a structured way.
But that’s just scratching the surface of the strategies, tools and techniques you’ll take away from these fast-paced, lively presentations.
And when you're through with the Webinar replays, if you would like more insight into using the CMMI as one of the tools that can help you establish the type of environment that can make you a great company, check out our upcoming LIVE learning opportunities:
Hey, CMMI Appraiser, should we force our project teams to accept either agile or Waterfall methods, and not allow any deviation? ~ DC SPIN Attendee
Today’s episode of CMMI-TV was filmed ON LOCATION at a recent DC Software Process Improvement Network (DC SPIN) gathering in Fairfax, Virginia, where I presented on “Agile Resiliency.” An attendee asked if it was important to make everyone on their project teams follow the same process. Below is a video clip with my answer, followed by a synopsis of my response. Enjoy!
Consultants love talking about the CMMI as being all about everybody doing the same thing every time. According to them, the CMMI is repeatable and predictable, and that means that everybody has to have the same behavior. One size fits all.
But one size -- whether Waterfall, agile, CMMI or any other method, tool or technique -- does not fit all. It's unrealistic and counterproductive to expect everyone to demonstrate the same repeatable behavior. What needs to be repeatable are the OUTCOMES.
What kind of outcomes should be repeatable? How about high quality software, efficient production and happy customers? These outcomes are possible even when many projects are unique and require their own "way of doing things" (otherwise known as the PROCESS).
To allow for companies' uniqueness, this CMMI Appraiser recommends that organizations have a SET of software process improvement models and methodologies from which projects can choose. That might include using both Scrum and Waterfall, for example. From that set, projects assemble the processes they want to use.
Keep in mind, a “set” means more than one. And “more than one” means you need some flexibility and agility to decide how you are going to do something.
For example, a team leader might say, “We’re going to adopt Scrum, but we’re going to use Wide Band Delphi for estimating.”
Those are from two different "communities." Is that OK?
Why not? You are trying to meet the needs of the project, right? So go for it. Have a SET of standard processes from which each project can derive their unique process, and then assemble process patterns to use depending on the needs, goals and objectives of the project.
For more insight into using the CMMI as one of the tools that can help you establish the type of environment that can make you a great company, check out our upcoming learning opportunities:
The CMMI Institute is pleased to announce that SEPG North America 2013 will be held at the David L. Lawrence Convention Center in Pittsburgh, Pennsylvania, on October 1-2, 2013. We are thrilled to welcome the community to our home city for two days of high-quality learning and networking. With a more compact schedule designed to maximize each moment, the conference will deliver high-value, practical information to end users and practitioners and offer excellent opportunities to connect with others in the performance improvement community.
SEPG North America 2013 aims to provide "structured informality," encouraging spontaneous discussions amidst a strategically planned schedule of discussion-rich lightning talks, keynotes, and brief presentations. New this year, the program will primarily feature invited speakers who will deliver powerful, compelling presentations. We anticipate that the program committee will round out the line-up with a smaller number of speakers selected from an open call for participation.
As we speak, the CMMI Institute is forming the program committee that will build the technical program. We are working quickly to be able to announce information on speakers, registration, and more at www.sepgconference.org in the coming weeks.
Developed with community feedback in mind, SEPG North America 2013 will bring together users, Partners, and the CMMI Institute to demonstrate to users CMMI's measurable, powerful impact on business performance and to help us cultivate the next generation of adopters.
Hey, CMMI Appraiser, our projects use multiple process models, including CMMI, ISO9000 and ITIL to name a few. How do we audit these projects? ~ QA professional at DC SPIN meeting
At a recent DC Software Process Improvement Network (DC SPIN) event, where this CMMI Appraiser was speaking on "Agile Resiliency: How CMMI Will Make Agile Thrive and Survive," I took a question from a QA professional on how to "audit" projects that use so many process models like CMMI, ISO, ITIL, etc. Below is a CMMI-TV video clip with my answer, followed by a synopsis of my response. Enjoy!
There is a philosophical difference between companies that identify their projects by process model, and companies that have identified and defined their company’s "Way," the Way their work gets done, they Way their values are demonstrated, and the Way they are successful with their customers. Having a well defined Way helps you evaluate and improve all areas of the business, and reach your goals faster.
DEFINING PROJECTS BY PROCESS MODEL
Many companies apply different software process improvement models for different projects. That is often perfectly acceptable and useful. But what is not useful is segmenting and defining the projects by process model. For example, the Head of Corporate Quality of an award-winning federal contractor recently told me, “We have our Agile projects over here, our ISO9000 projects over here, and our CMMI projects over here.” He did not realize he was missing an opportunity to help make his highly successful company even better.
A BETTER WAY
My advice to companies that are segmenting their projects by process model is to stop, take a step back, and consider that there may be a better approach. Rather than thinking of projects by process model, they should think of projects by the Company Way, as in “We’re a great company and here’s how we work.” They should apply this definition to everything the company does. No longer do they say, “Our agile projects are over here.” Now they say, “We run all of our projects in accordance with our Company Way.”
HOW TO “AUDIT” OR EVALUATE PROJECTS
For this philosophical shift to take hold, QA people should be trained in the aspects of the Company Way, and you should be able to evaluate your projects based on those aspects.
That doesn’t mean you all do everything the same way. Some projects will be Waterfall. Some will be Agile. Some will be R&D and won’t be using any process model. It just depends on what the goal is.
But regardless of process model, the approach you use to evaluate them should come from the same place. That is: “We are a great company, and here’s how we do projects.”
So stop thinking about models and standards and all of those things. Models and standards are good inputs into defining how you do your work. But don’t let them define how you run your projects.
For more insight into defining your Way and using tools like the CMMI to help you establish the type of environment that can make you a great company, check out our upcoming learning opportunities:
Fortunately, more organizations are benefiting from embracing the CMMI as a tool for solving business problems. Unfortunately, there continues to be a lot of misunderstanding about CMMI that needs to be untangled before the lasting value of the framework can be fully grasped. And so, to help you better understand what the CMMI is, here's my top 13 list of what the CMMI is not.
CMMI is not about making everyone do the same thing every time
CMMI is not a methodology
CMMI is not a process
CMMI is not a philosophy or a way of life, although it can influence those things
CMMI is not a set of requirements
CMMI is not a tool that can make you “CMMI compliant” in six months or less
CMMI is not something you “do”
CMMI is not something you “implement”
CMMI is not a document-heavy command-and-control rulebook
CMMI is not an oppressive death march that zaps your team’s energy and turns them into zombies
CMMI is not a race
What the CMMI is: The CMMI is an organizational improvement model that can help companies be more powerful and productive. It is an excellent tool to improve software and engineering product development, and is extremely useful in lighter, agile environments, as well as in larger, structured organizations. In fact, the more we work with the CMMI, and the more we work with organizations that are adopting it, the more we understand that CMMI is a model that's about how great companies perform, regardless of their size or industry.
So what do you get when you untangle the knot? A model for helping you do what you do, better. A framework for putting your company on the path to greatness – that’s what the CMMI is all about.
Quick reminder that Wednesday 4/3/13 is a great day to learn about Agile Resiliency. For the next several hours, you can still register for our FREE presentations of "Agile Resiliency: How CMMI Will Make Agile Thrive and Survive."
Click HERE to register for the Live Webinar (April 3rd @1pm ET)
Click HERE to register for the Live Presentation at DC SPIN (April 3rd @7pm ET, Fairfax, VA)
If your organization is considering doing more with CMMI and/or Agile in 2013, you’ll appreciate the following timely and useful information about getting the two to work together: