Project Management & Agile Development

cPrime Training Center has recently released a PMP Prep smart phone application that users are saying beats the competition out there. Professionals studying for the PMP Exam can now have their very own PMP exam prep tutor who fits right in their pocket. Students can now study while waiting in-line, riding a bus, or even review key concept right before they take their PMP Exam!

PMP Prep Pal helps you memorize key concepts on the exam with its flash card functionality based on topics from the PMI’s PMP Exam, including initiating, planning, executing, monitoring/controlling, and the PMBOK. PMP Prep Pal also gives sample exam questions along with detailed explanations and references to the answers given. After students think they have practiced and studied enough they are ready to test their knowledge. Students have access to 6 mock exams on the app that they can take right on their phone! After the mock exam students can see where they need to improve and track their progress through each of the mock exams.

To find out more and download the app please follow the following link – www.pmp-prep-pal.com. Or to go straight to the Android or Apple Store, follow the links below.

Android Market – PMP Prep Pal Lite

Android Market – PMP Prep Pal Full

Apple Store – PMP Prep Pal Lite

Apple Store – PMP Prep Pal Full

Users are excited about the new release and reviewing the app as “best PMP App out there”. A user also exclaimed, “The detailed explanations of the sample questions are awesome and so helpful!”

cPrime Training Center has a full curriculum of Project Management training courses, including the PMP Exam Prep Course. They have created this app to accompany their training course with a fun and convenient way to practice for the exam after taking the course. Anyone studying for the PMP exam can now download the app and access the flash cards, sample questions, mock exams and progress reports!

By Zubin Irani

As a profession, project management is amorphous by nature. Project Managers have collectively earned a reputation as the catch-all, do-all, task-masters of the IT world — the glue that keeps critical projects together. One of the most successful attributes in the PM realm is having a can-do attitude. Being able to take on any and every challenge is a great quality, and expanding the scope of your capabilities can definitely be an asset in this field, but there is such a thing as taking it too far. In fact, as a PM, limiting the scope of what you do can be the best thing for your projects, your career, and the advancement of the industry.

It’s hard to imagine professionals with a wider range of responsibilities than project managers in today’s fast-paced, highly competitive IT sphere. The stakes are high with multi-million dollar budgets, rigid timetables, and large teams to direct — it’s no wonder a “hands on” approach is easy to rationalize.

However, in most scenarios, the high order tasks — those that require education, experience and expertise — only occupy roughly 60-70% of a PM’s time. The rest is eaten up by administrative functions: updating project plans, writing up meeting minutes, compliance documentation, updating forecasts, and completing procurement requests.

Either by force of habit or by precedent, most project managers spend a third of their time on duties for which they are vastly over-qualified. The utilization of highly skilled labor for basic functions is a systemic malfunction — one that may be affecting the final outcome of projects and the state our industry as a whole.

Leveraging acquired experience

Outside of project management, reducing job scope — the cumulative sum of duties, tasks and responsibilities involved in a position — for high level employees has recently been embraced as means of maximally leveraging acquired expertise. For example, many senior sales professionals are now assisted by “lead generation” specialists. These lower level employees handle the initial legwork of identifying promising leads, allowing the more experienced staff to focus exclusively on closing deals.

In sales environments, this added focus means increased productivity in the form of more sales and higher revenues. The benefits of allowing project managers to zero in on higher order functions might be less immediately obvious, but better projects would be a likely result.

The bottom line is that under the current model, project managers are spread too thin. Imagine if instead of constantly jumping back and forth between high and low order tasks, the job scope was reduced. Senior project managers would focus exclusively on the things that demand their level of expertise — high order tasks, 90-95% of the time — and are sure to provide more management bang for the buck.

In order to realign the distribution of responsibility, an auxiliary administrator/coordinator role will have to be introduced into the project management dynamic. Relinquishing total control of a project might be a challenge for some PM’s, but transferring the low order workload to entry-level employees can actually have the added benefit of improving job satisfaction for mission critical staff.

Good “job fit”

In a dramatic example of what is known in management circles as a “poor job fit,” the United Parcel Service (UPS) used to require its delivery drivers to address both high and low order functions. The company was experiencing a crippling rate of turnover among this segment of the workforce, which represents a major operational investment in the form of training and resources. When management looked into the source of the problem, it was apparent that the drivers enjoyed driving their routes, but regarded loading their trucks at the beginning of the day as monotonous drudgery.

To remedy the situation, the company reduced the drivers’ job scope and created the supplemental job of “loader”. The position required very little training and could be covered by low-level hires, which sheltered the company from the high cost of driver turnover. With the improvement in job fit and satisfaction among drivers, the public face of the company soared, and customer satisfaction soared along with it[1].

Similarly, we need to question a PM’s job fit. Are we compromising the quality of our own work by asking too much of ourselves? If there’s one part of the job that’s incongruous with the inherent managerial/big picture realities of project management, it’s the administrative functions. Delegating these low order tasks may be just the thing to help project managers get more out of what they do.

A path to the future

Of course, scaling back project manager job scope isn’t just about catering to the project or making our lives easier. Creating an entry-level position within the field will also allow for the vital introduction of new talent. Just as “lead generation” and “loader” departments serve as self-selecting recruiting pools for future sales professionals and UPS delivery drivers, the best project administrators/coordinators will eventually become the outstanding project managers of tomorrow. 

The advancement of any industry depends largely on the passing down of accumulated knowledge going forward. We need to establish a professional hierarchy within project management to serve as a framework for the transferal of theory, practice and professionalism. Learning through experience, aided by mentorship, the next generation will become the new standard bearers, driving innovation in our field in the years to come.

That fact that we can pause to consider the scale of our roles as project managers at the current juncture is a testament to how far our field has come in a very short time. As our practice and discipline becomes more defined every day, the shift must be made from determining what it is we do to how we might do it best. The evolution will be constant, but as long as we continue to work in the best interest of the projects and our clients, our profession will continue to flourish.  

About cPrime

cPrime is a project management consulting, staffing and training services company on the front lines of technology and methodology. Our consulting engagements help clients transform the way they deliver projects giving them the critical ability to meet the pace and quality required in today’s market. Our comprehensive life cycle services provide end-to-end processes that increase your project success rate while establishing project governance across the enterprise. From audits and assessments to advanced methodology implementations, our leadership teams mentor organizations through Agile Development and methodology shifts. Our customized training solutions are structured to provide the understanding, preparation, and real world experience to help organizations and individuals achieve industry recognized certifications, earn professional development units (PDUs) and advance their career. 

[1] Pamela S. Lewis, Stephen H. Goodman, Patricia M. Fandt, Joseph F. Michlitsch, Management Challenges for Tomorrow’s Leaders (Ohio: Thomson-Southwestern, 2007), 192.

by Shayan Alam, PMP

Waterfall and Agile/Scrum development methodologies are widely used by all organizations and are individually considered a proven approach for development. However, challenges arise as these two methodologies merge and clash. Here are a few key tips to help integrate both methodologies into your development organization. Let’s first discuss each methodology and its unique characteristics and assumptions.

The waterfall software development life cycle methodology believes in getting everyone together and involved early in the design process. The design process is longer and iterative as the team steps through the high level requirements, conceptual approach, solutions design, preliminary design and critical design. This assumes little will be left for discovery through the development and testing phases. Generally, waterfall has worked effectively for certain types of products – large, enterprise-wide development efforts where the user is being led through a standardized process.

However, Agile/Scrum is meant for a more volatile world and provides an iterative approach. For example, in the mobile applications space, the landscape is constantly shifting as new phones, new operating systems, and new technology to deliver data compete to get the user to interact in as many ways as possible. Short iterative development allows for an “open” mind for discovery since less time is invested upfront. In this case, discovery involves anything from functional flaws to ineffective user flows to the concept being deemed a bad idea altogether.

The fundamental difference between the two is Agile/Scrum assumes there will be flaws and therefore jumps into the coding to expose these. Therefore the success of the development team is driven on its ability to adapt and react quickly. Waterfall, instead, takes early precautions to mitigate any flaws.

This obviously causes a clash between development teams practicing each of the development methodologies. But certain steps can be taken to show the development team the advantages of the other’s methodology and ideally bring a team together.

5 Tips to integrating agile development groups with waterfall development groups

Trying to introduce agile as iterative waterfall will not work

Some organizations think they can be more “agile” by doing waterfall in smaller iterations. The problem is the timeline is tough to compress when fully vetted artifacts are expected after each round of reviews. There is too much overhead with all of the document creation which detracts from the amount of time left for coding. Agile is about streamlining processes not compressing them.

 Development / QA can be iterative while being bookended by design and integration

One transition strategy is to employ agile in the development and QA cycles. Smaller scoped development cycles followed by QA. This way the customer sees the evolution of the application and can comment along the way. The design is properly vetted at the beginning and ample time is allotted for integration at the end.

 Watch out for scope creep

A project manager’s challenge in working in a fast-paced “can-do” development team is managing scope creep. Since changes can be implemented quickly, anything and everything seems possible. So the distinction must be made and managed between what is considered a fix versus what is considered a change so that sprints are tight and marching towards the agreed-upon end product.

 Play nice with QA

QA is always burdened as a release approaches, their schedule’s usually backed up against a wall. In waterfall, QA expects tight use cases to derive their test cases. So in the agile world, they get code thrown over the wall. That is why in agile teams, sometimes developers rotate into the QA role and become part of the solution from the beginning.

 Be mindful of the end user

Since at the end of each sprint a fully functional application is delivered, it is very tempting to release it. This can be very annoying to users if this requires a frequent patch or upgrade. It makes the user wonder whether a polished product is ever in the horizon. If the upgrades are seamless, it may be a hassle to keep up with the new changes. Therefore a published release schedule or roadmap keeps the user in the loop. Major releases semi-annually and/or functional releases quarterly are recommended.

 If you would like more information on this topic, send an email to info@cprime.com. We welcome your questions, comments and feedback.

Other Frequently Viewed Articles

Agile Software Development with Scrum FAQ: Learn about Agile Software Development, Scrum, Stories, Roles and More…

Agile, Waterfall and Uncertainty in Project Management: Agile Development vs. Waterfall

Introduction to Scrum: Benefits and Practices to Agile Software Development with Scrum.

Scrum as Project Management: Comparing and Contrasting Agile Development Scrum from Traditional Project Management Methodologies.

Agile Development & Scrum Meets the PMP: Agile Development and How it Compares and Contrasts to the PMI’s Methodology.

Daily Scrums in a Distributed World: Formal Collaboration to Reduce Overhead.

Integration of Waterfall and Agile Development: Tips for integrating Waterfall and Agile Development Methodologies.

by Kevin Thompson, Ph.D, PMP, CSP

How Uncertainty Works

All estimates are subject to uncertainty, and project schedules are no exception. A schedule consists of a set of tasks, which are executed at times dictated by dependencies and resources. The simplest schedule, consists of a set of tasks that are executed one after the other, and we’ll look more at this case below.

The schedule for a project contains uncertainty because the estimated effort or duration of each task has some uncertainty associated with it. We would really like to know exactly how long a task will take. If we can’t know that, we would at least like to know how much uncertainty is associated with the task. Unfortunately, we will never know the first, and usually will never know the second, either. (The exception to the latter rule is for tasks that are repeated, identically, enough times for us to collect meaningful statistics about them.)

In this article, we will look at uncertainty: Why it exists, how it behaves, how it accumulates, how to reduce it, and how to cope with it.

Why Uncertainty Exists

Suppose we are estimating the effort required to remodel a house. We will start by breaking down the project “Remodel House” into a few smaller steps, namely

• Remodel Kitchen
• Remodel Bedroom
• Remodel Living Room

We want to estimate the effort required for each of these steps, such as “Remodel Bedroom.” Unfortunately, our estimate will not be exact. Estimates differ from reality because of uncertainties, which arise in many ways

Incomplete Understanding of Scope

We may not have accounted for all the requirements. Do we need to replace the baseboards? If we didn’t think about the baseboards, our concept of scope is missing an important element, and our estimate will not include the work to replace them.

Incomplete Understanding of Work per Scope

Perhaps we did include baseboard replacement in scope, but we assumed the effort involved was limited to nailing the new ones in position. Unfortunately, we didn’t account for the work required to measure and cut the baseboards to the right size, so even though the scope was right, the effort estimate will be too low.

Imperfect Understanding of Known Work

Even if we did remember all of the work that needs to be done for the baseboards, and estimate accordingly, our estimates may be off because some of the boards split when nailed. We will either have to replace those baseboards, or drill them to avoid splitting when we nail them. Either way, the work will increase beyond our estimate.

Inability to Forecast the Unexpected

What happens if the paint we need is out of stock, or someone delivers the wrong baseboards? These external events are unpredictable, and disrupt our schedule.

How Uncertainty Behaves

Most people have an intuitive feeling that tasks are more likely to require more effort than planned, rather than less. This feeling is correct, for two reasons.

First, we are likely to omit scope or tasks that contribute to the work, and so underestimate the effort. This is obvious, and we reviewed some examples above.

Second, there is more room, in a mathematical sense, for work to grow beyond expectation than to shrink below expectation. This may be less obvious, but think about the work required for Remodel Bedroom. Assume we estimate this work at three days. The actual time may be more than three days over this estimate, but cannot be more than three days under the estimate!

In mathematical terms, we cannot estimate a task as requiring “X plus or minus Y days,” because the estimate becomes meaningless if Y is greater than X.

What we can do is replace the concept of an increment of uncertainty with that of an uncertainty factor, F. This means that we think that X is the most likely duration, but the range of values is between X divided by F, and X times F.

For example, suppose we estimate “Paint Bedroom” at 3 days, with an uncertainty factor of 2.

• The most likely case is 3 days.
• The best case is 1.5 days, which is 1.5 days under the estimate.
• The worst case is 6 days, which is 3 days over the estimate.

The real behavior of uncertainty is more complex than this simple model. (More sophisticated models rely on lognormal probability distributions and Monte Carlo methods.) However, our concept of an uncertainty factor is a convenient way to describe the most significant behavior of uncertainty, and we will continue with it.

How Uncertainty Accumulates

If errors were uniformly distributed above and below the expected values, they would tend to cancel out, on average, for a large set of tasks. As we’ll see, this is not the case.

Suppose we have a project containing 10 tasks, to be done one at a time, and each one is expected to take 10 working days. The naïve estimate for the project schedule is 100 working days for all tasks. The real schedule will deviate from the expectation, due to uncertainty.

Now we will assume that each task has an associated uncertainty factor of two. In the worst case, every task would take twice as long as expected, and the project would take 200 working days to complete.

The worst case isn’t very likely, so let’s consider a more typical case, where half of the tasks are under the estimate by the uncertainty factor, while half are over

The half that were under estimate take 5 days each (under by 5), while the half that are over estimate take 20 days (over by 15). The total time for all tasks is then 125 days.

Our typical case isn’t as bad as the worst case, but it exceeds the naïve schedule by 25% (25 days). This behavior is common, and it occurs because tasks can be over their estimates by more than they can be under. More realistic calculations, which rely on lognormal probability distributions instead of our simple uncertainty factor, are even more pessimistic. The long tail of the lognormal distribution has no upper bound, and tells us that some projects will never complete.

How to Reduce Uncertainty

While we cannot eliminate uncertainty when estimating work, we can take some steps to reduce it. One way to reduce uncertainty is to reduce the size of the thing to be estimated. The fewer the elements are that must be considered when producing an estimate, the more reliable the estimate is likely to be.

For example, the process of remodeling a bedroom contains a number of steps. If we estimate “Remodel Bedroom” directly, we may not think of all of the issues involved, and our estimate may be uncertain by a factor of three. Painting the bedroom, however, is a much smaller task, and has fewer elements that we may leave out of our estimate, so our estimate might be uncertain by a factor of two.

The obvious strategy for reducing uncertainty is to break large specifications or work items into smaller pieces. Thus we might break down “Remodel Bedroom” into four smaller tasks:

• Remove old carpet
• Paint room
• Cut new carpet to fit
• Install new carpet

Now we can produce an estimate for each of the smaller tasks. When we add these together, we will have an estimate for the bedroom remodeling, which is likely to be better than what we would have produced if we had not broken the work into smaller pieces.

The strategy of decreasing the “granularity” (size or level of detail) of items to be estimated improves accuracy, but has limitations. It can produce more items than we have the time to analyze, and thus delay the project completion. Also, there is no point in reducing the size below a level where the relative uncertainty does not improve. The important thing is to pick a granularity that (1) enables a tolerable level of uncertainty, and (2) produces a set of things to estimate that is small enough to be practical.

How to Cope with Uncertainty

Once we have reduced uncertainty to a practical minimum, the only other thing we can do is to take the remaining uncertainty into account in our process. We’ll look at strategies suited for projects that are subject to different kinds of constraints below. (For simplicity, we’ll assume that resources are fixed, since the ability to add resources does not vary in a meaningful way between the different scenarios. Similarly, we also assume that scope is well-enough controlled to prevent scope creep.)

Fixed Schedule, Fixed Scope

The first thing to understand about this set of constraints is that success is not always possible. If scope is truly fixed, and schedule is subject to uncertainty, then we have already seen that extreme cases will break any schedule.

These projects are planned with uncertainty in mind, by adding enough buffer time into the schedule to handle a reasonable level of uncertainty (for example, allocate 30% of the schedule for this purpose). This approach works well in situations where uncertainty is small, such as for repeating processes (e.g., laying carpet, or painting houses).

Fixed Schedule, Adjustable Scope

Many agile project-management frameworks handle uncertainty by committing to the only thing that can truly be controlled, which is the schedule, and adjusting the scope as required to meet the schedule. This strategy is particularly useful in high-uncertainty environments, where estimation is known to be inaccurate, and where scope is not well-understood and may change frequently.

The Scrum framework handles this situation effectively. It requires careful planning, but in a way that handles high uncertainty gracefully. Scrum projects work in short cycles to deliver modest increments of scope quickly, and to allow for frequent changes in scope and priority. Within each cycle, scope is adjusted as necessary in order to guarantee that the schedule is met.

No Schedule, Unknown Scope

Uncertainty is greatest when the scope is not known prior to the start of execution. This is the case for reactive organizations, such as Customer Support groups, which receive urgent requests that must be handled quickly, but which cannot be scheduled or planned in any meaningful way.

Another agile process, Kanban, is useful for this scenario. Kanban processes re-prioritize requests daily, and throttle (control) the flow of work by limiting simultaneous work-in-progress to a specified number (e.g., up to three concurrent requests can be handled by the staff).

Conclusion

Uncertainty cannot be eliminated by any estimation methods. It arises partly because of imperfect knowledge of what to do and how long it should take, and partly because of unpredictable events. The nature of task estimates is such that uncertainty biases deviations up, on average, relative to expected values. Again, on average, these upward biases accumulate even when as many tasks are under estimate as over, lengthening the schedule beyond the sum of expected task durations.

Reducing scope helps to reduce uncertainty, but only to a point. When uncertainty has been reduced as much as practical, the next step is to design the process to cope with uncertainty. We have reviewed three strategies for handling uncertainty:

• For fixed-schedule and fixed-scope projects, add buffer time in the schedule. This works for low-uncertainty projects, especially those that repeat the same type of work many times.
• For fixed-schedule projects, use an agile process such as Scrum, and adjust scope in a planned way to meet the schedule. This is an effective way to conduct a project when estimates are poor, and scope is poorly-defined and changes frequently, while still allowing for planning and a useful degree of predictability.
• For unscheduled projects with unknown scope, uncertainty is very high, and planning is not possible. In this case, a strategy such as Kanban, which focuses on constraining work-in-progress, is effective.

Other Frequently Viewed Articles

Agile Software Development with Scrum FAQ: Learn about Agile Software Development, Scrum, Stories, Roles and More…

Agile, Waterfall and Uncertainty in Project Management: Agile Development vs. Waterfall

Introduction to Scrum: Benefits and Practices to Agile Software Development with Scrum.

Scrum as Project Management: Comparing and Contrasting Agile Development Scrum from Traditional Project Management Methodologies.

Agile Development & Scrum Meets the PMP: Agile Development and How it Compares and Contrasts to the PMI’s Methodology.

Daily Scrums in a Distributed World: Formal Collaboration to Reduce Overhead.

Integration of Waterfall and Agile Development: Tips for integrating Waterfall and Agile Development Methodologies.

by Crystal Lee, PMP, CSM

Do you know what a Scrum is? Wondering if you should try Scrum on your next project?

If so, you’re not alone. It seems like everyone in the software development community is buzzing about Scrum. In this article, we will present basic principles and remove some of the mystery around Scrum, compare Scrum with current Project Management practices, and go over some tips if you are thinking of using Scrum for the first time.

Despite the recent buzz, Scrum is not a new discipline. Like Rational Unified Process (RUP), Scrum came out of the object-oriented programming movement in the 1980’s. Today, Scrum is one of the more well-known Agile software development frameworks in use today.

In the Scrum literature, we will find many familiar companies that are cited as examples of successful Scrum implementers including Google, Yahoo!, Accenture, Nokia, Sabre, Lockheed Martin, Salesforce.com, and the BBC. Some companies have taken the extreme step of making Scrum the prevalent mode of planning and delivery throughout the organization, from marketing to facilities management.

What Is Scrum?

The term comes from rugby, where a “scrum” is used to restart the game after an event that causes play to stop. Each opposing team forms into a human wall three players deep, pushing against the other team to kick the ball out to their side. It’s the ultimate in teamwork and strength. Taking the analogy to software development, Scrum is based on multiple small teams working in an intensive and interdependent manner to deliver a piece of software.

The Scrum process flow is structured in cycles of work called Sprints. A Sprint is usually two to four weeks long, and is similar to an iteration in Rational Unified Process (RUP). At the start of each Sprint, teams pick features from a prioritized list of customer requirements, called user stories, so that the features that are developed first are the most important according to the customer. At the end of each sprint, a working “potentially shippable” product is delivered.

The full Scrum team has 7 members (+/- 2), including the Product Owner, the ScrumMaster, and the Scrum core development team. As the projects increase in size, the number of Scrum teams also increases. The fundamental components of Scrum are Roles, Ceremonies, and Artifacts. For the purposes of this article, we’ll forego further details about these Scrum concepts.

Scrum and Classic Project Management

Is Scrum compatible with classic project management as defined by the PMBOK® (Project Management Body of Knowledge by the Project Management Institute)?

The answer is yes, because Scrum is a process framework and is not really comparable to the PMBOK®, which seeks to standardize project management best practices. Scrum is not only compatible with the PMBOK®, it can be complementary.

Being a ScrumMaster is also not unlike being a project manager, and the two roles can even be shared by one person. Like any good project manager, a ScrumMaster facilitates, coaches, mentors, removes obstacles, communicates, and protects the team.

It may even be that as a project manager, you are unknowingly practicing Scrum techniques. Symptoms of Scrum-like behavior include:

1. Surrounding yourself with a highly-specialized and high-producing team who share commitment and trust;
2. Assessing progress on a frequent basis (optimally daily);
3. Reviewing requirements frequently, and reprioritizing if necessary (optimally monthly);
4. Identifying doable short-term goals with your team and showing accomplishment frequently (every 2-4 weeks);
5. Allowing experienced team members to assign tasks to themselves because they know what is needed to get the job done;
6. Bubbling up the right amount of information to stakeholders through visible and effective communication.

However, each organization adopts Scrum differently, and so the implementations of Scrum can vary greatly. Some “Scrummified” organizations have PMOs, some do not. As you learn about Scrum and experiment with it, you will begin to see how the entire organization might have to go through a mindset change to use Scrum fully and correctly. PMOs might have to examine their charter and make modifications to work with less rigid Scrum processes. In some organizations, it could be analogous to the change that had to happen when the move to project-based work was first made.

How to Start Scrumming

By now you are probably getting the idea that Scrum is definitely not a slam-dunk. Most companies tend to test Scrum with a trial project and leave the rest of the company using existing methods until the results are proven.

Here are some suggested steps to follow if you are thinking of implementing Scrum for the first time.

1. Find an executive sponsor in your organization who will support you and your Scrum endeavors (this point cannot be overemphasized).
2. Analyze how and if Scrum fits into your current environment.
3. Find a test project that does not have a major business impact but is still important to the organization.
4. Find a team of like-minded people who want to make Scrum work.
5. Provide training for the ScrumMaster, Product Owner, and Team Members. All of the team members could attend one course together so that they understand everyone’s role.
6. Hire an experienced ScrumMaster who will drive the project and mentor the team, especially the new ScrumMaster.

Getting Certified in Scrum

If you are interested in gaining more expertise in Scrum, the first step is to take a Certified ScrumMaster (CSM) or Certified Scrum Product Owner (CSPO) course. Unlike other certifications, the CSM or CSPO does not qualify you as an expert. It does mean that you have been trained in what a CSM or CSPO is supposed to do. The next step in Scrum certification is Certified Scrum Practitioner (CSP), which requires applicants to be an active CSM or CSPO and show one year of hands-on Scrum experience. All Scrum Certifications are for two years.

You will find more information about Scrum on these websites:

• http://www.scrumalliance.org/ - Scrum Alliance. Scrum Certification body.
• http://www.agilealliance.org/ - Agile Alliance. Has information on Scrum.
• http://www.apln.org/ - Agile Project Leadership Network. Has information on Scrum.

The Future of Scrum

It is not yet possible to predict where the Scrum movement is going to end up. Is Scrum going to become just another entry in the already crowded field of Agile frameworks, like Lean Development and Extreme Programming (XP)? Or is it going to gain more momentum as larger organizations move towards a more “Scrummified” model? Of course, Scrum is not the only way to run projects, but it is certainly a burgeoning movement that has gained more publicity than most other Software Development methodologies.

Certainly Scrum has not worked for everybody. There have been classic failures of Scrum, but there have also been failures with waterfall, RUP, XP, and any of the other development methodologies around today. Probably the best advice is to be flexible when considering which framework to use. Just like you don’t wear the same clothes to work as you would to a football game or to a wedding, every technology project will be different and different frameworks and processes can be applied depending on the need for speed, reliability, profitability, or usability.

In fact, research is showing that the success of a methodology may lie more in the execution than the underlying principles. The more maturity and experience team members have, the less rigid the direction may need to be. So just like in rugby, if you are going to Scrum, make sure you Scrum with your eyes open and a good team around you.

Have a comment about the article you just read? Interested in getting more information on how to implement Scrum on your project? Send an email to crystal.lee@cprime.com. We welcome your questions, comments and feedback.

Other Frequently Viewed Articles

Agile Software Development with Scrum FAQ: Learn about Agile Software Development, Scrum, Stories, Roles and More…

Agile, Waterfall and Uncertainty in Project Management: Agile Development vs. Waterfall

Introduction to Scrum: Benefits and Practices to Agile Software Development with Scrum.

Scrum as Project Management: Comparing and Contrasting Agile Development Scrum from Traditional Project Management Methodologies.

Agile Development & Scrum Meets the PMP: Agile Development and How it Compares and Contrasts to the PMI’s Methodology.

Daily Scrums in a Distributed World: Formal Collaboration to Reduce Overhead.

Integration of Waterfall and Agile Development: Tips for integrating Waterfall and Agile Development Methodologies.

by Kevin Thompson, Ph.D, PMP, CSP

Scrum is a lightweight agile process framework used primarily for managing software development. Scrum is

• lightweight because it has few prescribed elements
  • Three roles: Team, Scrum Master (often a Project Manager), Product Owner (often a Product Manager)
  • Three meetings: Sprint Planning, Daily Scrum, Retrospective
  • Three artifacts: Product Backlog, Sprint Backlog, Burndown chart
• agile because it maximizes responsiveness to changing customer needs
• a process framework because it is not a process, but a collection of practices and concepts around which a process can be built

For those who are not already “doing Scrum,” the key question is not, “How does it work?” but, “What are the benefits?” This question does not have a unique answer, because it depends on who is asking. Benefits to developers, project managers, and salespeople are different.

This article identifies key benefits of Scrum, and the Scrum practices that produce them.

The Benefits of Scrum

Different stakeholders want different things from a software development process.

• Developers want to write code, not documents.
• Quality Assurance engineers want to create test plans that ensure product quality, and have high-quality code to test.
• Project Managers want a process that is easy to plan, execute, and track.
• Product Managers want features implemented quickly, with no bugs.
• Services and Support personnel want to know exactly what is in all product releases, and have a reliable means to satisfy customer requests for bug fixes and enhancements.
• Sales personnel want to know what is “in the pipeline” for future releases.
• Customers want all of their feature requests and bug-fixes done quickly.
• Executives, Program Managers, and PMO personnel want to know exactly what is happening, and what is planned to happen.
• Everyone wants happy customers.

The list seems long, but the key points are few:

• Team satisfaction and productivity are maximized when effort spent on non-deliverable items (e.g., internal documentation) is kept to a minimum.
• Maximizing quality at each stage minimizes re-work at following stages, and maximizes product quality seen by customers.
• Responsiveness is best achieved byfulfilling customer requests quickly.
• Project status and plans should be visible to everyone who has an interest in them.

Thus the best real-world development process devotes as little effort as possible to artifacts the customer doesn’t value, provides relatively bug-free code at the start of testing, delivers all relevant information to everyone who needs it, and fulfills customer requests quickly.

It is no coincidence that Scrum was designed to satisfy these points.

How Scrum Provides its Benefits

The following sections describe how Scrum practices produce the desired benefits.

Team Satisfaction and Productivity

The “team” consists of the development and Quality Assurance engineers who do the hands-on work of creating a high-quality product. Team members generally find their greatest satisfaction when they can do work that is rewarding.

• For developers, this means designing and writing computer software.
• For QA engineers, this means defining the exact criteria for success through the test cases they develop.
• For all team members, this means producing something they are proud of.

Productivity goes hand-in-hand with eliminating unnecessary work. Scrum addresses team satisfaction and productivity by emphasizing work that is valuable (as a deliverable) and rewarding (to the team), and de-emphasizing what is not (non-deliverable artifacts).

In practice, “non-deliverable artifacts” usually consist of internal documentation about product requirements and design, which customers do not see or value. Scrum projects do require some written documentation, but minimize it by relying as much as possible on real-time communication between people. Thus a Product Manager will write brief requirement descriptions (called “Stories”), and elaborate on the details as needed in discussions with team members.

The requirement for effective real-time communication means that one of the following must be true for all team members, Product Managers, and Project Managers (in order of decreasing desirability):

1. All are in the same building
2. All are in the same city
3. All are in time zones that overlap at least four hours per day
4. All are willing to spend hours per day outside normal working times (e.g., transoceanic teams).

The last three cases can only be made to work if real-time teleconference and Web-conference capabilities are available on demand.

Maximizing Quality

Teams implement Stories to the requirements, in a very literal sense: An implementation is not complete (a story is not “done”) unless it satisfies the requirements, as defined in the test cases. While test-driven development is not required for Scrum, test cases do define whether the requirements have been met, and no story is complete unless it passes all of its test cases. If bugs arise, developers fix them until the tests succeed.

This practice ensures that each Story implementation is bug-free, with respect to the requirements, at the time of its completion. It does not prevent regression bugs, so additional testing is necessary after all development is frozen. However, the quality of the product going into regression testing is higher than is the case for products going into the final test period for waterfall projects, and high quality ripples through all stages of the process.

Maximizing Responsiveness to Customers

Responsiveness means providing turnaround to customer requests in a manner that is consistent with customer priorities. Since instant turnaround is not possible, the next best thing is to respond quickly to high priorities, and less quickly to low priorities.

The only way to deliver any new feature or bug-fix quickly is to work in short development cycles, which is why the basic unit of Scrum development, the “Sprint,” is typically 2-4 weeks in length. Longer cycles, composed of two or more Sprints, are also common and often referred to as “Releases” (which is not a Scrum term).

Productivity and job satisfaction both require that people are productively employed, not sitting idle, which means that parallel work for team members is the norm. The two strategies for parallelizing work on a set of Stories are

• Parallel work on serial Stories. The whole team collaborates on one Story, until completion, then begins work on the next.
• Parallel work on parallel Stories. Each team member works on a different Story, until completion, then starts on another one.

Since Sprint lengths are “time boxed” (have rigidly-enforced durations), and unexpected problems can occur, it is often not possible to complete all work planned for a Sprint. For this reason, it is critically important that Story development be serialized as much as possible. This allows us to deliver, say, eight of ten planned Stories when only 80% of the expected work can be completed. In contrast, the parallel-Story strategy might produce no completed Stories at all in this case, and deliver zero value to customers.

The need to serialize Story development implies another important Scrum concept: Ranking. The set of Stories planned for a Sprint is called the Sprint Backlog, within which Stories are ranked (sequenced) for implementation. The Product Manager (say) is responsible for ranking the Stories, so that the most important ones are done first. (The Sprint Backlog is a subset of the larger Product Backlog, which contains all un-implemented requirements.)

The combination of short development cycles and ranking of requirements maximizes responsiveness to customer needs.

Providing Transparency

“Transparency” means that all steps, inputs, and outputs of the development process are visible-but to whom?

In the narrow sense, as typically described in books on Scrum, transparency applies to the internal membership of the team, the Scrum Master, and the Product Owner, as they need to know the status of the project every day. In this case, and for co-located teams, transparency may be provided by posting index cards or sticky notes with the current Story and task status, along with the current burndown chart, in a public location. The Scrum framework essentially guarantees this level of transparency.

(A “burndown chart” is a bar or line chart showing, each day, the amount of this Sprint’s planned work that remains to be done. The ideal progress is indicated by a diagonal line, trending down to zero on the last day, against which the actual state is compared.)

Transparency in the wider sense means that every stakeholder who has a need for project status information has immediate access it. “Status information” includes not only the status of the current Sprint, but the content of past Sprints or Releases, and the Product Backlog. The Scrum framework does not provide a standard practice to meet this need, but it provides excellent an excellent foundation for meeting it.

Transparency for stakeholders and distributed teams can be achieved via agile project-management applications (e.g., Rally or ScrumWorks), to which all team members and stakeholders are given access. These applications store all requirements and task definitions, track work status, and provide sophisticated reports. They enable distributed teams to collaborate, and allow stakeholders to query for the information they need, without adding a burden on the team or Scrum Master.

Conclusion

Scrum is designed to optimize team satisfaction and productivity, product quality, responsiveness to customers, and transparency for stakeholders. The key practices that enable these benefits include de-emphasizing work on non-deliverable items, implementing and finishing each Story in a Sprint Backlog in rank order, working in short Sprints of 2-4 weeks, and making past, present, and future project information available to all stakeholders.

Other Frequently Viewed Articles

Agile Software Development with Scrum FAQ: Learn about Agile Software Development, Scrum, Stories, Roles and More…

Agile, Waterfall and Uncertainty in Project Management: Agile Development vs. Waterfall

Introduction to Scrum: Benefits and Practices to Agile Software Development with Scrum.

Scrum as Project Management: Comparing and Contrasting Agile Development Scrum from Traditional Project Management Methodologies.

Agile Development & Scrum Meets the PMP: Agile Development and How it Compares and Contrasts to the PMI’s Methodology.

Daily Scrums in a Distributed World: Formal Collaboration to Reduce Overhead.

Integration of Waterfall and Agile Development: Tips for integrating Waterfall and Agile Development Methodologies.

by Kevin Thompson, PhD

Experienced project managers, trained in the formal practice of project management, can be forgiven for feeling that they have entered the Twilight Zone on first encountering Scrum. While Scrum is a “process framework,” optimized for managing software projects, almost nothing about it seems familiar to someone with a PMP certification. And yet, if Scrum is about project management, its concepts should make sense to “classic” project managers. How can we resolve this paradox?

Scrum Revealed

The apparent discrepancy between Scrum concepts and standard project management concepts is due partly to unfamiliar terminology, and partly to unfamiliar tradeoffs. Let’s look first at the terminology.

Terminology

The terminology of Scrum reflects the practice of working in short, fixed-length cycles called Sprints, a set of which produces a Release of the product. With this understanding, we can translate Scrum terms into language more familiar to project managers:

The correspondence is straightforward. The burndown chart, for example, is just the graph of remaining planned work versus time, which should trend down to zero on the last day of the Sprint. The Sprint Backlog is the set of requirements (“Stories,” in Scrum) planned for implementation in a Sprint.

PM Term = Scrum Term

Schedule  =  Sprint (or Release)
Scope  =  Sprint Backlog
Work Breakdown Structure  =  Task Breakdown
Productivity  =  Velocity
Estimate to Complete  =  Burndown Chart

Tradeoffs

The key to understanding Scrum is to understand what success means for a software project, since the definition of success drives the process.

Project managers are familiar with the “iron triangle” of scope, schedule, and cost. For any project, changes to any of these affect the others. For example, if the scope (or effort needed to achieve it) was underestimated, cost and schedule may have to increase to achieve the scope.

The traditional definition of success requires implementing the planned scope, on schedule, and on budget. When this isn’t possible, the next best thing is to trade off, perhaps extending schedule, adding resources (cost), or reducing scope. In most cases, however, achieving the specified scope, or something close to it, is the most significant part of the definition of success for the project.

Software is different. Unlike houses, software products evolve incrementally, and modest increments of functionality can provide significant new value to customers. Moreover, customer needs can change rapidly, as some of today’s expectations turn out to be less important in six months than other needs that materialize three months out.

The definition of success for most software projects is not to deliver a fixed scope in six months, but to provide desired features quickly in response to urgent (and changing) customer needs. Responsiveness trumps scope as the most significant element of success.

The need to optimize responsiveness drives us to an agile concept of project management, characterized in Scrum by

• Short cycles (Sprints)
  • Allow frequent course corrections in response to changing customer needs
  • Enable quick delivery of urgent customer needs
• Fixed schedules (uniform length for Sprints)
  • Guarantee reliable scheduling of release-quality code
• Completion of features in priority order within each Sprint
  • Guarantees top-priority features will be completed even if actual effort for planned features exceeds estimates significantly

Scrum trades off between scope and schedule by freezing schedule and adjusting scope as necessary. The reason we do not fix scope is because effort estimates for new-feature development have consistently proven unreliable in the software industry, and rather than fight the losing battle for more accuracy, we optimize for what we can predict (schedule, which helps in planning delivery dates), rather than what we cannot (the delivered scope).

Conclusion

The apparent departure of Scrum projects from standard project-management concepts turns out to be an illusion. In fact, Scrum processes are tightly-choreographed and involve careful planning, as any successful project does. The illusion of otherness arises from the unfamiliar terminology, and an unfamiliar tradeoff of scope versus schedule. In the end, an effective Scrum project is indeed following sound project-management practices.

About the Author

Kevin Thompson, Ph.D., is a Certified Scrum Practitioner and Project Management Professional, and publisher of the Deep Scrum weblog (http://deepscrum.wordpress.com). His Scrum in Practice workshop through cPrime (www.cprime.com/training) trains teams, Program Managers, and PMO personnel on the nuts-and-bolts of how to implement Scrum for software development.

Other Frequently Viewed Articles

Agile Software Development with Scrum FAQ: Learn about Agile Software Development, Scrum, Stories, Roles and More…

Agile, Waterfall and Uncertainty in Project Management: Agile Development vs. Waterfall

Introduction to Scrum: Benefits and Practices to Agile Software Development with Scrum.

Agile Development & Scrum Meets the PMP: Agile Development and How it Compares and Contrasts to the PMI’s Methodology.

Daily Scrums in a Distributed World: Formal Collaboration to Reduce Overhead.

Integration of Waterfall and Agile Development: Tips for integrating Waterfall and Agile Development Methodologies.

by Crystal Lee, PMP

Metrics may not be the sexiest subject in project management, but the success of the project management office (PMO) you work in, indeed, perhaps your job as a project manager, may be dependent on whether you have a metrics program in place. In tough economic times, there are even more amazing opportunities for a PMO to prove its real worth to the organization. The information in this article can help you to create your metrics program or assess if your existing program is doing enough to justify your existence.

Metrics in Project Management: More than Just Number

A metric, by definition, is any type of measurement used to gauge some quantifiable component of performance. A metric can be directly collected through observation, such as number of days late, or number of software defects found; or the metric can be derived from directly observable quantities, such as defects per thousand lines of code, or a cost performance index (CPI). When used in a monitoring system to assess project or program health, a metric is called an indicator, or a key performance indicator (KPI).

Metrics Management Defined

Intense interest in metrics within the project management community has spawned an entire subfield of study called metrics management. Project metrics can be categorized into three main categories:

1. Pure project management measurements (Example: Estimation accuracy)
2. Indicators of project success (Example: Stakeholder satisfaction)
3. Indicators of business success (Example: ROI).

At the macro level, metrics management means identifying and tracking strategic objectives. This is often done by the PMO, if one exists. One PM practitioner, Anthony Politano, has even advocated that corporations should have a Chief Performance Officer (CPO), who is responsible for metrics collection and analysis, and for communicating those metrics to management for strategic decision making.

When reporting metrics to management, it is important to keep the time factor in mind. True success or true failure may not be apparent until long after a project is formally closed. For example, a new software application may turn out to be a colossal failure six months after it is put into production, when it finally reaches its planned usage targets.  

Examples of macro-level metrics include: number of successful projects, percentage of failed projects, and number of hours spent per project or program.

At the micro level, metrics management means identifying and tracking tactical objectives. It is only by looking at the task level metrics that status of higher-level work packages can be ascertained, which can then be reported to project stakeholders and customers. Different types of projects will require different types of metrics—a software development project will call for different measurements than, say, a merger and acquisition transition project.

The following criteria are the most common tactical measures people want to be updated about:

Tactical MeasureQuestion AnsweredSample Indicator Time  How are we doing against the schedule? Schedule Performance Index (SPI) = Earned Value ÷ Planned Value Cost How are we doing against the budget? Cost Performance Index (CPI) = Earned Value ÷ Actual Cost Resources Are we within anticipated limits of staff-hours spent? Amount of hours overspent per software iteration Scope Have the scope changes been more than expected? Number of Change Requests Quality Are the quality problems being fixed? Number of defects fixed per user acceptance test Action Items Are we keeping up with our action item list? Number of action items behind schedule for resolution

Putting a Metrics Program into Place

A common saying you may hear about metrics is: “If it cannot be measured, it cannot be managed.” Clearly the lack of metrics can make it harder for a project manager to do the best job possible. 

At the same time, metrics are useful only if they are just that – useful. Tracking metrics just to have something to put on your status report is not effective use of your time, or your team’s time.

If you want to put an effective metrics program in place, set aside time to plan the following items in the following order:

What information are you going to collect?
(Hint: Keep it simple).

How are you going to collect the information?  
(Hint: Keep it easy. Use information already being collected for other purposes.)

What methods will you use to process and analyze the information?
(Hint: The more actionable the analysis the better.)

How and when will you report on the results?

A special word on reporting: The way you present your metrics depends on who is asking. The executive usually just wants to know the general health of the project and get a “warm and fuzzy,” while the PMO auditor wants to know that you are “two days behind, due to the approved scope change, but that you are crashing the schedule in order to make it up.”

The best way to showcase your information is usually the simplest. Some project management software packages include an automated dashboard feature, which may or may not fit your needs. Visual displays, such as a simple graph to illustrate trends, or the classic “traffic light,” are effective ways to show the status of key metrics indicators. A simple traffic light chart can be built in Excel, using colors to show status. Typically:

• Green means “So far so good.”
• Yellow means “Warning – keep an eye on me.”
• Red means “Urgent attention needed.”

Your traffic light report should show detailed indicators and one rollup indicator for status at a glance.

If using a traffic light format, be sure to set rules for when to change colors on the lights; work with the project sponsor or PMO to get this done if not already standardized. You may have had the fun experience of trying to decide when exactly you should turn that little dot yellow, or not be allowed to turn it red because your manager does not want you do so.

For example, for a schedule-based indicator, the rule can be “Turn the indicator yellow when the number of overdue tasks is greater than two.” Indicators can also be split into monthly target ranges so that trends in progress can be gradually visualized. It is better to turn the traffic light yellow when the overall schedule is five days late during Month 1, than to turn it yellow when you are 15 days late during Month 3, when it is too late to react.

Take Metrics Management to the Next Level

As you continue to accumulate metrics about the projects in your company’s portfolio, you are building a valuable database of internal benchmarking data. Compare your metrics to other projects in your portfolio to see where process improvements can be made, or where you might introduce compliance requirements. You can also compare your metrics to benchmarked project data from other companies in the same industry.

One resource for the latest news in metrics management is the Project Management Institute’s Metrics Special Interest Group (MetSIG). MetSIG’s premier event is its Global Online Congress, held annually in April. The Congress is a month-long series of online “webinars” on metrics-related topics. As a sign of the importance of metrics to the project management community, MetSIG estimated that almost 50,000 participants would attend the MetSIG 2008 Online Global Congress, and another 50,000 would view the archived video presentations (see www.metsig.org for more information).

Project management as a discipline continues to grow and shows no sign of slowing. As PMI Chief Executive Officer Greg Balestrero quoted in his Keynote Speech at the 2007 MetSIG Congress, over 87 percent of organizations already report project status to Boards of Directors, and 17 percent of PMOs report to CEOs (KPMG, Global IT Project Management Survey, 2005).

The challenge is to make sure that the project status includes metrics that demonstrate the value of project management. As you have seen, there are many tools and techniques available to communicate and manage metrics at a project (tactical) or PMO (strategic) level. Take this opportunity to think about how people around you perceive the value of your project management services, and see if you can think of ways to promote and protect your position as a champion of project management in your organization.