Aglie and CMMI

IMPLEMENTING SCRUM (AGILE) AND CMMI® TOGETHER

This is happened because there are many requests during my seminar on Agile implementations in various non-CMM level IT(but ISO level) organizations & training institutes. So I am giving you a reference document which can be kept handy in all such software development life cycles (SDLC).

If you are a software engineer or IT professional, your group has very likely shown a strong interest in reducing costs, improving quality and productivity. Your group might also have looked at various pre-packaged frameworks, such as Agile (e.g., Scrum and Extreme Programming), CMMI1 and Six Sigma.

At first glance, each of these frameworks might look at odds with each other, making it difficult to use two or more. This typically occurs because much of the information shared regarding these frameworks is from success and failure stories, rather than understanding the specifics of each framework. Each framework can be implemented successfully depending on how much care is placed on its implementation.

In this blog I am trying to compare CMMI and Scrum since they are two commonly used frameworks, and ones we have seen groups struggle with when using them together.

First, let us define each.

Scrum

Scrum is a pre-defined development lifecycle based on Agile principles. Agile methodologies promote a project-management process that encourages frequent inspection and adaptation, and a leadership philosophy using teamwork, self-organization and accountability.

CMMI for Development

CMMI is a collection of practices that organizations (software, hardware and IT) can adopt to improve their performance. The CMMI comes with two main views (representations), Staged and Continuous. Staged shows all the Process Areas (groups of related practices) in the form of a road map, allowing organizations to focus on basic improvements before attempting advanced topics. The Continuous representation has the same content but allows for any topic (Process Area) to be selected in an a la carte style.

Level 1 is just the basic report creation & notifications. I would like to start the study with CMM level 2. The Level 2 Process Areas focus on change and project management. Level 3 focuses on engineering skills, advanced project management and organizational learning. Levels 4 and 5 focus on the use of statistics to improve the organization’s performance by statistically controlling selected processes and reducing variation. So the question is, how do these two frameworks relate, and how can an organization use both?

Scrum is an example implementation of some of the Maturity Level 2 practices. We will have list of the main practices of CMMI that map cleanly to Scrum process steps. This doesn’t mean that an organization could not eventually add additional CMMI practices to its projects; it just means that in Scrum, there is no clear equivalent called out. Although the practices of Scrum provide good implementation examples of many Level 2 CMMI practices, one catch is the level of artifacts needed to appraise at CMMI Level 2. If a Scrum team either discards or loses its project artifacts, then being appraised Level 2 will not be possible since there will be little evidence showing what happened. If however, a project team stores these data, an appraisal team can then use them for verification. Ideally, Scrum team members would naturally want to store their work so that they could refer to past iterations during lessons-learned sessions.

CMMI and Scrum mapping

In the paragraphs below we please take a note of several CMMI practices (using CMMI text taken from the model definition) and how Scrum can implement each practice. To appraise Level 2, it is assumed that the Scrum implementation is robust and shows evidence of the CMMI practice being performed.

Let’s start with the initial software SDLC phase REQUIREMENTS MANAGEMENT

The purpose of Requirements Management (REQM) is to manage the requirements of the project’s products and product components and to identify inconsistencies between those requirements and the project’s plans and work products.

REQM CMMI Practice : SP 1.1 Develop an understanding with the requirements providers on the meaning of the requirements.

REQM Scrum Practice: Review of Product Backlog (requirements) with Product owner and team.

REQM CMMI Practice :SP 1.2 Obtain commitment to the requirements from the project participants.

REQM Scrum Practice: Release planning and Sprint planning sessions that seek team member commitment.

REQM CMMI Practice : SP 1.3 Manage changes to the requirements as they evolve during the project.

REQM Scrum Practice: Add requirements changes to the Product Backlog.

And Manage changes in the next Sprint planning meeting.

REQM CMMI Practice : SP 1.5 Identify inconsistencies between the project plans and work products and the requirements.

REQM Scrum Practice: • Daily standup meeting to identify issues.

• Release planning and Sprint planning sessions to address inconsistencies.

• Sprint burndown chart that tracks effort remaining.

• Release burndown chart that tracks story points that have been completed. This shows how much of the product functionality is left to complete.

PROJECT PLANNING The purpose of Project Planning (PP) is to establish and maintain plans that define project activities.

PP CMMI Practice SP 1.1 Establish a top-level work breakdown structure (WBS) to estimate the scope of the project.

PP Scrum Practice • The standard tasks used in a Scrum process combined with specific project tasks (Scrum Backlog).

PP CMMI Practice SP 1.2 Establish and maintain estimates of the attributes of the work products and tasks.

PP Scrum Practice • Story points, used to estimate the difficulty (or relative size) of a Story (requirement).

PP CMMI Practice SP 1.3 Define the project life-cycle phases upon which to scope the planning effort.

PP Scrum Practice • The Scrum sprint process.

PP CMMI Practice SP 1.4 Estimate the project effort and cost for the work products and tasks based on estimation rationale.

PP Scrum Practice • Scrum Ideal Time estimate (similar to billable hours or Full-time Equivalents).

PP CMMI Practice SP 2.1 Establish and maintain the project’s budget and schedule.

PP Scrum Practice • Scrum estimates (in Ideal Time).

• Estimates of what work will be in each release.

• Sprint Backlog.

• Project Taskboard.

PP CMMI Practice SP 2.4 Plan for necessary resources to perform the project.

PP Scrum Practice • Scrum estimates in Ideal Time

• Release plan, Sprint Backlog and assignments.

PP CMMI Practice SP 2.6 Plan the involvement of identified stakeholders.

PP Scrum Practice • Scrum process roles (including team, Scrum Master, Product Owner).

• [Note: The stakeholders listed in Scrum might not be the complete list of stakeholders for the project, e.g., customers, other impacted teams. Also there can be various additions /changes during SDLC]

PP CMMI Practice SP 2.7 Establish and maintain the overall project plan content.

PP Scrum Practice • Scrum release plan. And • Sprint

PROJECT MONITORING AND CONTROL

The purpose of Project Monitoring and Control (PMC) is to provide an understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan.

PMC CMMI Practice SP 1.1 Monitor the actual values of the project planning parameters against the project plan.

PMC Scrum Practice • Sprint burndown chart that tracks effort remaining.

• Release burndown chart that tracks completed story points. This shows how much of the product functionality is left to complete.

• Project Task Board used to track stories (requirements) that are done, in progress, or ones that need verification.

PMC CMMI Practice SP 1.2 Monitor commitments against those identified in the project plan.

PMC Scrum Practice • Discussions on team commitments at the:

− Daily Scrum meeting.

− Sprint review meeting.

• Sprint burndown chart that tracks effort remaining.

• Release burndown chart that tracks story points that have been completed. This shows how much of the product functionality is left to complete.

PMC CMMI Practice SP 1.5 Monitor stakeholder involvement against the project plan.

PMC Scrum Practice • Discussions at the:

− Daily Scrum meeting.

− Sprint review meeting.

• [Note: The stakeholders listed in Scrum might not be the complete list of stakeholders for the project, e.g., customers, other impacted teams.]

PMC CMMI Practice SP 1.6 Periodically review the project's progress, performance, and issues.

PMC Scrum Practice• Daily Scrum meeting.

• Sprint review meeting.

• Retrospectives.

PMC CMMI Practice SP 1.7 Review the accomplishments and results of the project at selected project milestones.

PMC Scrum Practice• Sprint review meeting.

PMC CMMI Practice SP 2.1 Collect and analyze the issues and determine the corrective actions necessary to address the issues.

PMC Scrum Practice • Notes from the:

− Daily Scrum meeting.

− Sprint review meeting.

[Note: Some teams track their outstanding actions on the Product Backlog. It doesn’t matter where or how the items are tracked, as long as they are.]

PMC CMMI Practice SP 2.2 Take corrective action on identified issues.

PMC Scrum Practice • Actions from the:

− Daily Scrum meeting.

− Sprint review meeting.

PMC CMMI Practice SP 2.3 Manage corrective actions to closure.

PMC Scrum Practice • Tracking of actions from:

− Daily Scrum meeting.

− Sprint review meeting.

• [Note: Most important This assumes that teams will track (and not lose) actions.]

Now let’s compare role based like configuration Manager , QA/ QC etc.

Configuration Management (CM)

CM is not specifically called out in Scrum. However, in an Agile environment it is pretty easy to add a layer of CM to protect your work. Even for groups that like to use white boards, you can be creative and at least establish some basic protection

by labeling items (e.g. “V1.1,” or “Story dated 1/2/YY”) and taking a photo. The CM Process Area does require more than just versioning, but versioning is an easy start.

Product or Process Quality Assurance

Some basic activities are being done naturally when the Scrum Master checks that the Scrum process is being followed. Other activities are completed when a team performs code reviews, document reviews and testing. The Scrum Master also plays a role of removing process barriers and inefficiencies. However, Scrum does not specifically call out a level of objective process and product check, nor does it state that particular standards or processes should be defined and used.

Therefore I stated that Scrum does not automatically implement these processes. However, refinements can be made such that it does.

Supplier Agreement Management

There are no practices in Scrum that deal with the selection and management of suppliers.

Generic Practices

Approximately half of the Level 2 Generic Practices of Requirements Management, Project Planning and Project Monitoring and Control are implemented by Scrum.

Measurement and Analysis

The purpose of Measurement and Analysis is to develop and sustain a measurement capability that is used to support management information needs. There are no practices in Scrum that establish a measurement program similar to the expectations of measurement and analysis process. However, the measures in Scrum can be used to implement all such process.

CMM Level 3 & SCRUM analysis

There are two main areas where Scrum has gaps compared to Level 3. One is in the CMMI expectation that project data and lessons are shared among projects via a common process asset library (or repository). Second, the expectation that the engineering phases of requirements, design, implementation, verification, integration and validation are well defined and implement the Level 3 engineering practices. These CMMI concepts can be done in an Agile/Scrum environment, but they don’t come with the common Scrum definition.

Scrum does suggest implementing Communities of Practice, to reach across teams to share lessons learned, and Retrospectives within a team. These ideas could certainly be used to populate an asset library and thereby codify best practices and tailoring guidelines. The following Level 3 components therefore are not readily implemented by Scrum

without additional work:

• Organizational Process Focus

• Organizational Process Definition

• Organizational Training

• Integrated Project Management

• Risk Management

• Decision Analysis and Resolution

• Some engineering Specific Practices (e.g., requirements validation and verification data analysis)

• Generic Goal 3 (i.e., using an organization-wide and tailored process with measurements)

Scrum is a good implementation for some of the practices in Level 2. Therefore, a group can use Scrum and CMMI together. All the remaining practices in Levels 2 and 3 can be implemented while using Scrum.

Understanding of Scrum or Implementation

Scrum is a process that teams can adopt quickly to plan and manage their work. Each Scrum step has just enough detail to plan, design, build and test code, while tracking team progress. Its strength is that it is straightforward to use. The risk is that it can be used to focus on building components with less regard for the complete system. This risk can

be managed.

Scrum has three primary roles: Product Owner, Scrum Master, and team member.

The Product Owner communicates the vision of the product to the development team. This includes representing the customer’s interests through requirements and prioritization.

The Scrum Master acts as a liaison between the Product Owner and the team. The Scrum Master does not manage the team but instead works to help the team achieve its Sprint goals by removing obstacles. The Scrum Master verifies that the Scrum process is used.

The team members do the project work. The team typically consists of software engineers, architects, analysts and testers.

The intent of Scrum is to build working components in small iterations, each iteration lasting between two and four weeks. A typical Scrum lifecycle has the following steps:

• Write the requirements (and store in the Backlog)

• Plan the release (which could span more than one 2-4 week Sprint)

• Plan the Sprint

• Conduct the Sprint

- Analysis

- Design

- Coding

- Testing

• Conduct Sprint retrospective Daily stand-up meetings are held to track team progress and identify barriers.

Android fragmentation

Android fragmentation Study need of the hour : Android fragmentation has long been a hot topic and for good reason. Google was iterating its mobile platform quickly handset makers couldn’t keep up without investing more time, money, or both; and developers showed frustration with the many versions of Android and handset configurations. That led to various versions of Android in customers hands with different features, application support and no guarantees of future upgrades. But the situation is getting better.

Steps to fix the problem About 18 months ago, we started analysing this problem of fragmentation and noted some steps Google was taking to alleviate it. Breaking out core Google applications from the Android platform has helped, because the updated software for Mail, YouTube and Maps, for example, are all available in the Android Market. Handset owners don’t have to wait for Android updates to get the latest version of these apps.

Google has also slowed down the pace of Android updates for some months now that it can. By that, I mean it had to initially mature Android quickly in order to compete at least in terms of features with Apple’s iOS. I’d say that for most people, Google has caught up to iOS in terms of the most used features. Sure there are still differences, but I’d argue that the ones that remain are fairly negligible. And where there are gaps in either mobile platform compared to the other, these can often be addressed through third-party software.

How bad is the problem now? The slower pace of updates has led to a majority of handset owners now running variations of Android 2.2 or 2.3: Google reports that of all Android devices visiting the Android Market over the two weeks prior to Sept.2, 81.9 percent run these two main versions, or a sub-version like 2.3.3. Android 1.5 and 1.6 only account for 2.8 percent of all Android devices, while there are still 13.3 percent running Android 2.1

I’m making a distinction and lumping Android 2.2, 2.3 and 2.3.3 together. Why? As a long-time daily Android user, Android 2.2 (Froyo) brought huge improvements to the platform in May of 2010. Android 2.3, and its subsequent minor point updates, haven’t added as much, or at least not much that users are complaining about.

Each version or sub-version of Android adds new APIs for developers to use, but even here, the last few Android updates have provided relatively little compared to versions from last year or earlier. Android 2.3.4, not shown yet in the data, is rolling out now to the Nexus S, but only includes bug fixes and no new APIs.

Based on this look, it’s clear the carriers have work to do: They need to nudge their handset partners to invest the effort into creating updates and then, in turn, the carriers need to test and push those updates out. However, more phones are appearing with Android 2.3 or better out of the box, which will help.

Is it as bad as it was? While the fragmentation issue looks a little dire in the above graphic, I still think it’s getting better, but perhaps that’s because I don’t make much of a distinction between Android 2.2 and any subsequent version. The situation also took two to three years to create; it’s not going to magically disappear over time. But as I look back, I do see less of an issue due to the small steps Google has been taking to address it.

An additional effort has much to do with Android tablets as well as phones. Ice Cream Sandwich, the next major version of Android, will unify the platform between both device types, which should ease future problems as Android continues to mature.

Unfortunately, fragmentation will never be completely addressed. Android will always be fragmented by definition if any handset maker can use it in any way they see fit. Various screen sizes, hardware component choices, development budgets and target price points affect Android devices and the versions of Android that they run.

The only way to eliminate the problem is for Google to either cease licensing the platform and build its own devices, like Apple, or for the Android-maker to be very specific in terms of hardware requirements, like Microsoft. I don’t expect either of those things to happen. And that’s OK, because the fragmentation issue is less of a problem than it was 18 months ago.

This approach of bundling Android 2.2, 2.3 and 2.3.3 is certainly arguable, and the first question I’d pose to any such argument is: What key functions are you missing if you’re running Android 2.2 and not a higher version? There are a few, but not too many of high impact to most consumers, in my opinion. Carriers are the other factor

Google doesn’t dictate which phones launch with which version of Android, nor does it really have any say about existing handset upgrades. These decisions generally lie with network carriers, with the lone exceptions of the Google Nexus handsets; Google pushes updates directly to these smartphones as they see fit a key reason I bought and still use a Nexus One.

In May, Google announced the Android Update Alliance to bridge the gap between Android releases and carrier updates. Key partners include Verizon, HTC, Samsung, Sprint, Sony Ericsson, LG, Motorola, AT&T and Vodafone. The group promises handset updates for up to 18 months after a phone is introduced. I think it’s bit early to assess the effort, but Justin Shapcott did just that in an insightful post at Android and Me. This chart, broken down by carrier, shows the current state of Update Alliance Members.

Android is big right now, but not sticky. It is not sticky because the apps are just baby Java apps, they are very minimalist phone-type apps, they can easily be created on any other platform or even have their functionality reproduced by Web apps. In other words, it is easy to switch a user from an Android phone where they only run a Twitter, Facebook, and Skype app to a Windows Phone where they only run a Twitter, Facebook, and Skype app. It is much harder to switch an iOS user. Where is Keynote for any other mobile? Where is iMovie or GarageBand? I have dozens of sophisticated native C music and audio apps on my iPhone that I can’t live without because that is my work. I’m stuck on iOS forever. Nobody else is trying to get me as a customer. There is nobody stuck on Android like I’m stuck on iOS.

The thing that made Windows dangerous to the Mac was that non-Jobs Apple sat still for 10 years and gave Microsoft time to clone the Mac API. It became straightforward for Adobe to port Photoshop from Mac to Windows. Nobody has even started to attempt to do that same thing to iPhone. iOS is still the only system on ARM that can run native C/C++ apps from PC’s and consoles and large computing systems. iOS is also the world’s only malware-free computing platform. At some point, some other vendor is going to finally do another instance of both of those things and they are going to become Pepsi to Apple’s Coca-Cola. Google totally blew that opportunity when they did Java instead of native C/C++; did an unmanaged platform instead of malware-free; and declined to do a centralized software updating and installation system. If they had done that, they would have 500,000 apps, now, too.

The Android ecosystem is not marching to the same beat. It is not only not doing that, they are deliberately marching to different beats.

My take, I’d certainly like to see more standardization, but I wouldn’t like to see Google go as far as Microsoft with WP7, where they’re still using hardware from a year ago, and reminds me of RIM and Nokia, who always seem to release phones at current prices, but with last year’s tech. Actually, it’s not just last year’s tech, it’s one chip period, which in the long term would seriously affect competition, and it helps commoditize WP7 phones faster.

So it’s good to keep in mind that fragmentation which by default has a negative connotation, actually has many benefits, too, like seeing cutting edge hardware as soon as it’s ready, different phone sizes, designs, prices, which are very important factors for a regular user, too. You also get to see some new stuff from manufacturers that otherwise you’d have to wait for Google to implement.

But unity and standardization is important, too, so you can have a bigger reach, and developers better know what to expect from the platform. If we take a scale from more open to closed, and it’s like this Android -> X -> desktop Windows -> WP7, I’d like to see Android move in X’s position. That would probably be the ideal and most balanced position between very open and very closed.

Fragmentation isn’t going away any time soon, but I don’t think that the resulting compatibility challenges are seriously damaging to Android. Google has found practical ways to minimize the impact of fragmentation and to keep the broader Android ecosystem marching to the same beat.

But you are wrong even if you only look at this one reason: there are many more Android devices now than a few months ago. The problem is much bigger now that Android is replacing feature phones.

We have moved past the time when devices ran different versions of Android because of incompetence and lack of planning or management on the part of Google or the handset makers, and into a time when devices run different versions of Android DELIBERATELY, in order to differentiate their device and avoid the bad reputation of Android. We’re past the time when everybody wanted the Android logo and the Google logo and the Google apps and to be all one happy platform and we’re into the time when handset makers not only don’t want the Android logo and Google apps, they don’t even want to admit that the core of their device is a version of Android. The Chinese Android handset makers see themselves as either Apple or Google, they do not see themselves as part of a larger Android platform. One of them licenses their own Android variant to other handset makers.

The root of the problem is that Google does not know how to manage a platform. Putting software on device A that is called Android and software on device B that is also called Android does not mean that those 2 devices are part of a platform. They not only both need to be the same version today, they both need to be the same future version at this time next year. If 50% of iPhones were running iOS v3 right now, App Store would not be the success that it is.

So saying Android has 70% smartphone market share is exactly equivalent to saying Linux has 70% smartphone market share, or WebKit has 99% smartphone market share. Great to know. So what we are trying to conclude? It means absolutely nothing. It is more germane to note that ARM has 100% smartphone market share, because at least ARM is a company that actually sells into a market, not an open source project that is used by lots of software engineers to build almost entirely unrelated products.

Fragmentation is both at the hardware and software level and is used to cover both. This article seems cover OS version fragmentation and doesn’t cover hardware handset fragmentation (and the associated carrier OS fragmentation due to overlaid software and applications for branding etc). It is also handset diversity but it does fragment the username for handsets as Android users are spread over so many different handsets. It’s normal to have it through updating each year but having multiple vendors exacerbates it.

I am still compiling this day by day also got help from various comments by mail to understand specific pain areas in detail, please share your concerns or any details I missed in this. You can write to me at ravindrapande@gmail.com