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!
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
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!
No comments:
Post a Comment