Our 7th eBook Is Now Available on Amazon: “Just the FAQs”!

Dear Readers,

We’re excited to announce the publication of our 7th agileCMMI eBook: “Just the FAQs”!

In “Just The FAQs,” my good friend Pat O’Toole and I join forces to share a series of short stories from different perspectives about process improvement, CMMI, and Agile development. We address common misconceptions, myths, and fundamental misunderstandings that persist with the software and engineering professions. And we have a good time doing it!

Click here for your copy of "Just the FAQs".

“Just the FAQs” is a compendium of stories written in 2014-15 that have been distributed individually as part of a series, right here on Ask the CMMI Appraiser. The stories are now available in eBook format as a collection. To purchase for 99 cents on Amazon, click here.

What you’ll find in the book:

• Why should Agile teams care about the CMMI Practices?
• What can we learn about Process Architecture from Justin Bieber?
• How expensive are SCAMPI A appraisals?
• How to get value from Requirements Development with Agile teams?

Get the facts!  "Just the FAQs"!

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

© Copyright 2015: Process Assessment, Consulting & Training and Broadsword Solutions

“Just the FAQs” is written/edited by Pat O’Toole of PACT and Jeff Dalton of Broadsword. 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!

JUST THE FAQs: How do the Generic Practices help us make Agile better?

[Dear Readers, "Just the FAQs” is our monthly series of CMMI-related posts. Over the recent months, our good friend Pat O’Toole, CMMI expert and seasoned consultant, has been collaborating with us on these posts. Our goal here is to provide answers to the most frequently asked questions about the CMMI, SCAMPI, engineering strategy and software process improvement. This month, I discuss how the Generic Practices guide your Agile implementation ~ the CMMI Appraiser]

Reader: I’ve read some articles about how the CMMI can help make Agile better, but I don’t really see how the generic practices fit in, or how we should comply with them. Should I just ignore them?

Jeff: Not only do the generic practices “fit,” they should have been named the Most Important Practices in Agile! **Note to self: send that suggestion in to the CMMI NextGen team!

While the CMMI can help any organization improve and identify their “state of maturity,” the Generic Practices represent solid value to Agile teams – they are what make it real. 

It has been said that Agile teams don’t like process. It’s too heavy, top-down and “command and control” for their style of software development. But “ceremonies,” like sprint planning, daily standups, retrospectives, and sprint demos are simply group behaviors, and behaviors are nothing more than processes – so OF COURSE they like process! Furthermore, if Agile ceremonies are processes, and the Generic Practices are intended to enable them, it follows that these are the precise tools we need to instill a higher level of capability to Agile methods. So bring them on!

Here are 12 ideas that you can take back to your office right now to improve the state of your Agile implementation:

Idea #1: Work with your management team to establish a clear set of common values that include: transparency, collaboration, failing–fast, iterative and incremental, and a strong bias towards spending more effort writing software than writing documentation.

This, of course, is an Agile implementation of Generic Practice 2.1 “Establish an Organizational Policy” that can leverage practices in Organizational Process Focus and Organizational Process Definition to make it real with supporting processes and tools. So, instead of saying “Policies? We’ve got binders full of ‘em!” focus on the values instead.

Idea #2: Establish a precise model for the different levels of planning that your team is going to perform. Release Planning, Sprint Planning, and planning for the tasks associated with each User Story are a few examples. Those plans include the who, what, where, and how of each level. Develop a clear requirements architecture for customer needs, epics, and user stories, including a “definition of ready” for each one, as well as the estimation methods that are going to be used for each. Establish an agreement with your team on how each aspect of the software engineering process is going to work: how is code going to be written? How are code reviews going to be conducted? How is testing going to work within each Sprint?

I call these “the “CMMI Questions.” Instead of slavishly complying with the practices, turn them into questions to be answered by the team.

In this case, the questions are about Generic Practice SP2.2 “Plan the Process,” supported by Project Planning, Project Monitoring and Control, Integrated Project Management, Risk Management, Technical Solution, and almost every other Process Area in the CMMI!

Idea #3: Procure all of the resources to support the items identified in Idea #2. These might include: co-located workspace, planning poker decks, pair programming desks, software tools such as Sharepoint, Jira or Team Foundation Server, and the funding for the various tools, resources, facilities and other components required to execute the ceremonies and events.

This idea is an Agile manifestation of Generic Practice 2.3 Provide Resources, along with its related Process Areas Supplier Agreement Management, Project Planning, Integrated Project Management, Technical Solution, and others.

Idea #4: Some are under the impression that because Agile teams are “self organizing,” that means that it is less disciplined, but nothing could be further from the truth. A crisp understanding of each person’s role, responsibility, and authority is essential to any successful Agile team, even more than in a traditional software development environment. Product Owners must be free to make product decisions, Scrum Masters need to be able to freely coach teams during each ceremony, and team members need to step-up as they self-subscribe to each story or task. Personal responsibility is everything for an Agile team, and without a clear definition of roles teams cannot be successful.

You guessed it! The CMMI called this one, too, with Generic Practice 2.4 Assign Responsibility, along with the related practices in Project Planning and Integrated Project Management.

Idea #5: Suck it up and train people. Train them to be Product Owners and Scrum Masters. Most importantly, train teams to be self-disciplined, empowered Agile citizens that trust the process and live the Agile values from Idea #1 everyday. 

This is Generic Practice GP2.5 Train People, with the related Process Area Organizational Training. If you do nothing else, do this. Do. It. Now.

Idea #6: Agile teams like to use “information radiators.” No problem! If you make a decision to use sticky notes and a scrum board, use a camera to capture that information and store it in a repository so that other parts of your organization can benefit from that information. If not, use a tool like Jira or TFS to record information while you create (and share) burn-down and burn-up charts, epics, stories, and tasks. The same goes for the information that is generated from Idea #2. Record your process definitions in a common repository so that you, and other teams, can benefit from the assets you’ve developed.

For more information see Generic Practice 2.6 Control Work Products, and the related Process Areas Configuration Management, Project Planning, and Organizational Process Definition.

Idea #7: Most of what’s been written about Agile teams focuses on the “nuclear” scrum team, but every project has external stakeholders who need to have input and participation with the project. For instance, you might have a group of people who focus on continuous build/continuous integration, or attendees at a Sprint demo that need to be in attendance to provide useful and meaningful input.

Generic Practice GP2.7 Identify and Involve Relevant Stakeholders, along with the related Process Areas Project Planning, Integrated Project Management, Validation, and Verification can provide some of the guidance you’ll need.

Idea #8: How was your Agile team performing? Are they meeting Sprint commitments? Are customers satisfied with the prioritization of user stories? Are they inserting stories mid-sprint? Do the user stories meet the definition of done? Inquiring minds want to know! 

This is my favorite practice in the CMMI model: Generic Practice GP2.8 Monitor and Control the process, along with its related Process Area Measurement and Analysis. Without this, how do we even know that we’re doing the right things? Special note: If Maturity Level 4 or 5 are in your future, pay close attention to this one!

Idea #9: Since Agile requires personal discipline it makes sense to me that we occasionally evaluate the behaviors of Agile teams to ensure that healthy self-discipline exists. Given the value that Agile teams place on a “high-trust” environment, they are usually loath to accept the idea of project audits, but there are many ways to objectively evaluate team performance. With a focus on mentoring, coaching, and improving the discipline of Agile teams, look to the values from Idea #1 to ensure you are getting at what’s important.

The CMMI nails this with Generic Practice GP2.9 Objectively Evaluate Adherence, and the related Process Area Process and Product Quality Assurance.

Idea #10: While Agile has grown exponentially across project teams, it hasn’t been quite as successful at persuading management to join revolution. Sharing successes (and failures) of Agile teams more proactively with upper management will bring more agility to the entire organization. The key to Agile success is the implementation of the Agile values described in Idea #1 throughout the company – and if management isn’t involved it isn’t going to happen. Ever.

The authors of the CMMI had the foresight to include Generic Practice GP2.10 Review Status with Higher Level Management, a practice that can be leveraged for this purpose, and is relevant and critical for the success of Agile teams.

Idea #11: Once size never fits all, and this goes for Agile teams as well. I’ve always said that the authors of the CMMI intended for it to be Agile, and this is demonstrated in Generic Practice GP3.1 Establish a Defined Process and the related practices in Integrated Project Management that scream BE AGILE and do what’s right for your project! So create guidelines that will allow Agile teams to deviate, when it makes sense. Creating those guidelines is tough so look to Organizational Process Definition for guidance. It’s well worth the effort.

Idea #12: Agile teams are well versed in the use of the Retrospective, but since Agile ceremonies focus primarily on the nuclear team those lessons don’t usually get shared with the larger population. The organization that can expand the concept of Retrospectives beyond the Agile team, so that lessons can be systemically collected, indexed, and used by all, is the organization that wins!

The CMMI’s Generic Practice GP3.2 Collect Process Related Experiences provides guidance for systemically sharing lessons, along with its related Process Areas Integrated Project Management and Organizational Process Definition.


So there you have it. Twelve ideas (and twelve Generic Practices) that can improve Agile performance right away. The rest is up to you!

Anyone interested in a more in-depth discussion on the topic is invited to sign up for this month’s new Webinar, “Agile Transformation.”

WEBINAR INFO

What: “Everything You Need to Know. Agile Transformation!” Webinar

When: Thursday, March 26, 2015 at noon EDT.

Sign up: Click here

© 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!

A-DAR-able Moments

[Dear Readers, our good friend Pat O’Toole, CMMI expert and seasoned consultant, is collaborating with us on a new monthly series of CMMI-related posts, "Just the FAQs." Our goal with these posts is to provide answers to the most frequently asked questions about the CMMI, SCAMPI, engineering strategy and software process improvement. This month Jeff discusses Decision, Analysis and Resolution (DAR).  Take it away! ~ the CMMI Appraiser]

This DAR thing just seems silly to me.  Aren’t we supposed to be experts?  Why do I need a bunch of overhead when I’m smart enough to make the call on my own?

Make the call on your own?  That’s so a-DAR-able!  And it reminds me of a little story…

Back in the early 90’s I was leading a software project to develop a retail point-of-sale system for a major department store (yeah, we were pretty “RAD” back in the day….), and the job of selecting a code library that provided basic retail functionality fell to my team.

We quickly assembled a list of available suppliers some members of the team had heard of, and asked them to provide us more information about their code libraries.  Even though we didn’t conduct a “formal” selection process, we thought we were asking the right questions about platform, funtionality, cost, and viability.

After lining all of them up side-by-side, we had three solid, but similar, choices that ran in a text-based Linux environment, and one that ran on the then new-fangled Windows platform with a touch screen. Wait. Touch screen? Graphics? Ooooh.  Our inner-nerds were salivating!

While we went about the process of discussing our options, the buzz around the office about “touch screen” was palpable.  Words like “sexy”, “innovative”, and “groundbreaking” could be heard at all levels of the company.  Text-based systems were “old-school”, “yesterday’s news”, and “boring.” The CEO even weighed-in and said the new graphical interface would be the “soul” of the new system.

The CIO, who reviewed the data and found the touch screen system to be lacking in functionality while higher in cost, added a column to our matrix which he labled “pizzazz.”

Oy vey.

I think you know the rest of the story.  I don’t need to tell you about how the momentum to choose that touch screen system was unstoppable, or that the code library of basic retail functions didn’t even WORK, or that the entire project was a disaster that resulted in substantial cost and schedule overrruns.  No, I don’t need to tell you THAT story….

But I do need to tell you about the “3D’s.”

The 3D’s is a tool I use to remind myself about that project – and to help make sure that it never happens again.  It stands for Deliberate, Durable, and Defendable.  If you’ve taken one of my CMMI classes, you’ve heard me talk about it during the section on Decision Analysis and Resolution (sometimes I call it “Dalton’s 3Ds,” but that would make it FOUR D’s, and that’s way too much overhead!).

Here they are:

Deliberate: Applying a deliberate step-by-step approach that leverages proven criteria, which involves a limited set of the right stakeholders, and follows a useful, fact-based series of steps would have stopped the momentum of the touch-screen cold in its tracks.  This approach is sometimes called “a process.”

Durable: We need our decisions to stand the test of time, and to last beyond the next great thing, or perhaps just the next new manager.  Making a decision durable not only requires that a deliberate process be followed, but also that consideration is given to scaleability, change (including reorganization, acquisitions, or unforseen changes in business climate) and evolving preferences in technology or culture.  “Durable” doesn’t necessarily mean “solid,” “robust”, or “large.” More often than not, it means “flexible” and “adaptable.”  

Defendable.  Every decision we make has political consequences, as it reflects postitively or negatively on key stakeholders.  A successful choice can catapult a manager’s career into the boardroom, or relegate him just as easily to the mailroom.  Who we involve, how we communicate, and how we present the data to these stakeholders has an impact on whether it will be accepted, supported and implemented for the long term.  And it will also help control (or at least identify) those who would hide in the weeds waiting to pounce the minute they smell an opportunity to do so.

Start with the identification of a small number of key moments in time where important decisions need to be made – the kind of decisions that must be both durable and defendable, and then follow a deliberate path from selection, to analysis, and then on to resolution.

These could be some of the most important decisions of your career – you might even call them “a-dar-able moments.”

© Copyright 2014: Process Assessment, Consulting & Training and Broadsword Solutions

“Just the FAQs” is written/edited by Jeff Dalton  and Pat O’Toole.  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!

What’s Your Biggest Software Development Challenge?

Hey, CMMI Appraiser. What is the biggest challenge you see today in software development? – Steve M.

Your question is timely, Steve.

We talked about Software Development challenges at a recent Embedded Software panel discussion. As expected, ideas ranged from lack of time to lack of communications about requirements. Other issues included technology, skills, training and funding. While they are all important, I think there is an even bigger challenge: Values.

Whether it's Boeing, NASA, Lockheed Martin, Ford and GM, the problem always comes down to values.

Corporate Values? Okay, stop rolling your eyes!

Corporate Values typically talk about Service, Honesty, Excellence and Respect. The problem with Corporate Values like these is that they are never really implemented. 

In order for values to be useful, they have to be about actionable behaviors. They have to be operational. They have to say: “Here is how we want our people to behave.” 

In software, you can trace customer’s needs to business requirements, technical requirements, and to code and test cases.

We also need BEHAVIORAL traceability. If we make values operational, we can trace them from training, to skills, to tools, to code, to requirements, and to everything we deliver.

Operational Values are things we all agree to. Is it harder? Absolutely. It’s way harder. Simpler? Way simpler. But, it’s worth the effort. 

By the way, I am speaking on "Values-based Engineering" at the GL-SPIN meeting in Rochester, MI on March 13. I’ll be expanding on some of the ideas we just covered. Join us if you can!

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

The Art of CMMI: Waging War

[Our good friend Shawn Rapjack, CMMI expert and seasoned consultant, is back with a another installation on CMMI based on Sun Tzu's "The Art of War: Waging War” We're excited that Shawn has agreed to share segments of his article with you here on "Ask the CMMI Appraiser"]

Jeff's army waging war on Process Debt

Waging War

Continuing our Sun Tzu and CMMI discussion, let’s move onto the Art of War’s second chapter, ‘Waging War’.  This chapter dovetails with the first, ‘Laying Plans’, in that it has a strong focus on estimation and budgets.  Morale and timeliness are also goals.

Now would be an opportune time to discuss ‘the enemy’.  Sun Tzu faced daunting adversaries on the battlefield. Our ‘enemy’ however is different but just as pernicious – process debt and poor engineering solutions!  In our discussions of Sun Tzu and CMMI, these foes should be identified and dealt with, just as Sun Tzu would have – with thought and forthright conviction. For process professionals like us, ‘fighting’ is the deployment and success of organizational processes. 

This excerpt nicely sums up thorough estimation:

In the operations of war, where there are in the field a thousand swift chariots, as many heavy chariots, and a hundred thousand mail-clad soldiers, with provisions enough to carry them a thousand li, the expenditure at home and at the front, including entertainment of guests, small items such as glue and paint, and sums spent on chariots and armor, will reach the total of a thousand ounces of silver per day. Such is the cost of raising an army of 100,000 men.

And thoughtful scheduling:

Though we have heard of stupid haste in war, cleverness has never been seen associated with long delays.

Managers must ensure that project and process schedules are being followed, monitored, and updated.  If this is not done, available resources may not be sufficient. 

Resources must be planned for and incorporated into plans.  Small details must be considered – how long will it take to peer review requirements documents?  How long will it take to incorporate these changes?  Wiggle-room should be made in the schedule if the customer has a history of not being responsive with requirements validation.  These details (like Sun Tzu’s glue and paint) need to be considered!

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

Can we be CMMI Level 3 without losing our agility?

Dear CMMI Appraiser, I’ve been enjoying your posts about Agile and CMMI.  I am the founder of an Agile organization that has grown to 40 people.  We aren’t about process at all, but I’d like to see us adopt more of a CMMI Level 3 mindset.  Our CMMI Consultant tells us we're pitiful and need help.  Can companies like ours become CMMI compliant without losing the flexibility and freedom that makes us who we are?  ~Louis

Louis,

Hmmm.  Not a very nice thing for your CMMI Consultant to say about you...isn't he the one supposed to be giving you help?  


Yes, companies like yours really can achieve great benefit from using both CMMI and Agile.  The combination allows you to exploit synergies that have the potential to dramatically improve business performance.

However, when you say you aren’t about process, I would challenge that.  If you are really using Agile techniques, you are, without a doubt ALL about process!  As I tell the attendees in my CMMI Training class,  that’s nothing to be ashamed of! It's ok, we all know :)  You should be proud that you’ve been able to stay flexible while incorporating useful processes like daily stand-ups, planning poker, and more.  A good CMMI Lead Appraiser should be able to recognize those things as useful to your organization and make some suggestions for making them even better.

The good news about CMMI is that it aligns very well with all of the major Agile methods.  And it can be used to make those things even better! For example, take a look at how the CMMI practices correspond with some of the more common agile techniques: 

This should help your organization start to move in a direction where you can use the CMMI to help improve and still be Agile and light-weight.  The truth is, not only can you be light and Agile, but you can still have choices that will meet the needs of each project.  Choices are what give you the freedom to be who you are, and to do it the right way for each given situation.  If you were to come to me for some CMMI Consulting I would offer you this same advice.

Many people mistakenly believe that, in order to adopt the CMMI, they need to adopt a culture of rigid compliance that kills your freedom.  Nothing could be further from the truth.  It's all about choices - something the SEI calls "tailoring."

At this point, Louis, adopting the CMMI in your Agile organization may be the adventure you are ready for.

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

Learn more about CMMI Appraisals at www.broadswordsolutions.com