Why we can’t just burndown everything

Prashad is the project manager for a new product. After reviewing the project scope, Prashad’s team gives it an initial estimate of about three to four months to complete, which is good enough for management. The project kicks off, and using Scrum along with a little bit of project management, the project gets underway. The first month goes quickly, there is great progress, and everyone loves what they see. But in the second month, things start to slow down — so, Prashad adds more resources to the project to compensate. But by the third month, there are real problems and it looks like the project will be late. Prashad adds even more resources. Now the team is almost double the original size. He adds a lot more quality assurance and testing support for the team, too, because a lot of problems are cropping up. The team cranks away, and they finish the project in the fifth month, and claim “success” because they almost hit the deadline (it was, after all, just an “estimate“).

But what about all those additional resources? Is it really success if the project cost twice as much as originally estimated? The problem is, that cost was never formally stated. It was never tracked as a metric, so the fact that the project went horribly over budget is quietly swept under the rug — at least this time. There are plenty of cases where the budget isn’t there, or the resources aren’t there, or the product just can’t ship late.

So, if so many projects are missing their mark, what’s causing the problem?

The fallacy of so called Agile methods

According to studies conducted by KPMG, as much as 70% of projects fail to meet their goals. In this case, “goals” mean quality, schedule, and function (or a combination of those). Clearly, being able to accurately estimate a project’s delivery date is important. Without knowing when a project is done, you can’t predict cost, plan business operations, or dovetail releases with marketing, training, and customer service.

Agile methods like Extreme Programming and Scrum make promises that, in my opinion, they can’t keep. For well over a decade we’ve seen an increasing trend in project failures, and a large number of those failures are the result of “unending projects.” Projects that go on and on, continuing to deliver improvement but slowly creeping over budget and never reaching an end state. Part of the problem is the lack of formal estimation and metrics.

Both Scrum and Extreme Programming dodge the entire issue of project life cycle estimation. They focus on the near term, providing estimates for the next one or two sprints. This works great if you don’t have budget or time constraints, but in the real world that’s rarely the case.

Burndown just doesn’t work

Most Agile methods don’t explicitly define how you estimate progress, but the most common method is burndown — the measurement of completed effort against the planned sprint goals. This is fine for a quick-and-dirty project but as a strategy it utterly fails to pinpoint problems with budget and timeline. For anything larger than a few months effort, it doesn’t do the job.

And the problem is, few of today’s engineers seem to be getting the formal education and training needed to use proper estimation methods.

There are better solutions than burndown

Earned Value Management, or EVM, is nearing it’s 40th year of practice. Throughout this 40 year history, EVM has repeatedly evolved to meet new demands as technology and innovation made new leaps forward. It’s a proven method for measuring progress and it’s been proven time and again.

Of the dozen or so software engineers I spoke with about this article, none of them had even heard of EVM.

Earned Value Management, as well as a variation known as Performance Based Earned Value® (PBEV), are my favorite choices for estimating a project. The PBEV approach provides an incredibly robust method for measuring progress and staying on top of your project. It’s only marginally more difficult than other techniques of measurement. And most project managers are already capturing the metrics needed to make it work.

PBEV is an improvement over Earned Value Management Systems’ (EVMS) national standard. It supplements EVM with guidelines for the integration of project cost, schedule, and technical performance — thus created a comprehensive and highly accurate method for measuring true progress in a project. The key here is integration of effort with schedule and performance.

Had Prashad been using PBEV, he would have had a very different experience. The early estimates would have been more accurate, since PBEV estimates the entire project. It would have measured not only resources and cost, but also the actual performance — the rate at which work is being done. Had the project gone off track, Prashad would have known much more quickly, and would have had a more precise picture of how to correct the project’s course.

There will definitely be situations in which PBEV is not warranted, and a skilled project manager will need to know when to use other methods, and why. EVMS, for instance, addresses only the quantity of work completed, ignoring cost and schedule metrics. The implication here is that a quick burndown or EVMS-based evaluation of a project might look A-OK, when in fact the only reason it’s on track is because resources are being thrown at it — and costs are skyrocketing.

Burndown versus critical path thinking

Burndown is a very simple method for estimating work effort over a short term. It explicitly avoids timeline, cost and performance metrics. That’s fine for projects that are not constrained by time, budget, or resources. The problem is, burndown is used as a defacto standard too often, on the promise that using an Agile method will deliver a project faster or cheaper than its alternatives. I don’t disagree on this front. Agile methods generally are faster and cheaper — but the question is, faster and cheaper than what?

Most business need to be concerned with time, money, and staffing. Projects that have those constraints need to think about the critical path — the sum of all activities to reach the end of the project. Having a solid understanding of the fundamentals of critical path management is important to managing any project schedule. Depending on the nature of your project, you may be able to rely on casual effort estimates — or, you may be required to carefully identify, analyze, and attack critical paths to shorten your project lifecycle and stay within stringent guidelines. Without understanding the principles, and knowing where to turn for more information, neither is possible.

I’ll revisit the topic of PBEV in a future article and provide more depth into how it can be applied to a project. If you’re eager for more information, check out Performance-Based Earned Value®, Paul J. Solomon, Ralph R. Young, IEEE Computer Society, Wiley Interscience, 2007.

Solving cultural and logistic International project problems

Sometime in 2001, a New England firm that later became a client decided to outsource all of its software development to India. It seemed like an excellent idea at the time, as Indian intellectual property wage rates were roughly one-tenth of their U. S. counterparts. But the project went poorly: U.S.-based employees struggled to manage programmers located halfway around the world, and much of the work coming back from India didn’t meet the standards of quality expected by the U. S. firm. While the industry has improved, this is still a common problem today. How can a team located in a different culture, a different business environment, and surrounded by completely different ideas regarding acceptable customer service, adequately meet the quality demands of a foreign customer?

There’s a solution?

Before exploring a solution that solves the complex cultural and logistic issues of International projects, let’s take a quick look at the elements of a typical project. We can start by using a guide such as the Project Management Institute’s PMBOK®, or Project Management Body of Knowledge. The PMBOK quite effectively lays out much of the scope a project manager needs to be prepared to handle.

According to the PMBOK, every project has five phases in common:

  1. Initiating.
  2. Planning.
  3. Executing.
  4. Monitoring and Controlling.
  5. Closing.

During each of these phases, the project manager’s objective is to balance the competing constraints of scope, quality, schedule, budget, resources, and risk.

These constraints are, in and of themselves, often daunting. Add in the human element and often inevitable business politics, and projects can become difficult exercises in communication, motivation, and human psychology. In fact, the PMBOK spends a good bit of time discussing key areas where these factors play a major role. Stakeholder involvement, communication plans, getting an unbiased statement of work or progress, managing risks, and managing subcontracts — just to get the list started — are critical to achieving success on any project.

All of these factors combine to create a web of constraints that push and pull at the fabric of a project, often so much that the fabric doesn’t survive intact. For example, stakeholders may not have the project’s best interests at heart or may simply be uninterested in their day-to-day responsibilities. Budget constraints may require the project manager to make difficult decisions that affect the team, or the objectives of the project. Subcontracts are, by the very nature of business, first and foremost motivated by their own fiscal health and profit, not necessarily your best interests.

This is the landscape a project manager steps into on a daily basis. The larger an endeavor, the more significant these challenges become — even when the entire project is still in a single building.

International project problems… Solved

Now, expand the dynamics of the project to a global effort, involving International team members, foreign partners, and vendors that you seldom meet in a face to face setting. In fact, many global projects are “communications deprived,” due to geographic challenges. A global organization can often have project members spread across as many as 15 time zones. While advances in technology have led to tremendous strides in delivering reliable communication, teleconferencing or video conferencing a few times a week, in the early or late hours of day, doesn’t compare to frequent, in-person communication. Teams operate in a vacuum much of their day, making decisions they would otherwise not make on their own.

Think back to the New England based firm: All of these factors contributed to quality problems, as the team in India tried to deliver what they believed the client wanted, but failed. Lack of communication, cultural misunderstands, and business context that we take for granted was missing — and the project failed.

This is the vacuum into which Rational Scrum was created. Project management methodologies today don’t address the complex issues imposed by multicultural teams, working in widely distributed, International contexts. That’s what Rational Scrum is all about: Finding solutions for International project problems. Fuel for this blog comes from a few different sources, including my book Successfully Managing International Projects. I hope you’ll find the contents interesting!

For more information on Successfully Managing International Projects, sign up for our mailing list. You’ll get occasional, relevant updates and announcements as the publishing date grows near.

Scrum versus Kanban

Pawel Brodzinski makes a very succinct and key observation regarding the differences of Scrum and Kanban (and also links to a handful of opposing views by Ken Schwaber, David Anderson and Mike Cohn). If you want to figure out how Scrum and Kanban differ, this is a great starting point — be sure to check the referenced articles to get both (or, all three, or four) sides of the story.

Common oversights in choosing methodology

Changing the way a business operates is a daunting task. It involves assessing and understanding the strengths and weaknesses of the current organization, identifying solutions to the weaknesses without compromising the strengths and, ultimately, changing the way people work. Above all, people tend to be resistant to change — and this is the most common issue that arises when adopting a new methodology.

This translates into preparation, more than anything else: Preparing by understanding your options, preparing the organization for change, and preparing to measure your success.

Be thorough during evaluation

The most common oversight in preparing to adopt a new methodology is simply not evaluating all of the available options. It’s an easy pitfall to succumb to: There are so many processes, so many methodologies, so many choices, how can someone possibly make the right choice? Surely all of these published techniques are mature and “real,” does it even matter which methodology we choose? Yes. It matters a great deal. Each methodology has its strengths and weaknesses and very few methodologies can be applied to every development project.

The wide variety of methodologies is a reflection of the complexity of the software development industry. We have many choices in executing any strategic operation, whether a military incursion, a football game or planning for building a house. Likewise, the software industry has evolved a wide variety of processes, each one suitable for different scenarios. While it is certainly true that many methodologies can be successfully applied to many different projects we can’t make the assumption that any one methodology will work equally well in every situation. Adopting a heavy process in a project involving a small team and a short-term schedule is almost always a poor idea, as it leads to extending the project timeline to support unnecessary project artifacts. But less obvious is the impact of pairing a lightweight process with a medium-sized project. How many people is “too many” for an Extreme Programming (“XP”) project? At what point does the lack of formal project controls start to make the project unpredictable? Will the business stakeholders feel the project is not adequately managed? These questions, and many more, emphasize how important it is to prepare thoroughly before choosing a methodology.

Given the plethora of potential methodologies, it’s easy to just pick one and get started. The temptation to simply choose a well-regarded methodology, buy a well-reviewed book on the subject, and forge ahead can be strong. But this “textbook approach” can prove deadly. Without studying the methodology beforehand it’s easy to choose the wrong methodology — and even if a mistake of this magnitude becomes clear over time, it’s usually too late to change course. And much like reading instructions too quickly, it’s easy to realize too late that the process is wrong: Incorrectly implemented, or not the right fit for the situation.

Another pitfall to the “textbook approach:” It leads to following a process blindly and over-adopting, particularly with more comprehensive methodologies that have more to offer. The fallout from this: Teams come to think that comprehensive methodology is a “bad thing,” heavily weighted and full of red tape, unnecessary work and overhead. Using the textbook as an instruction manual makes it impossible to have a complete view of processes and artifacts offered by the methodology and, therefore, the value and appropriateness of each.

Prepare the team and the organization

Just as evaluating and selecting new methodology can be a mine field, so can the actual adoption process. A common oversight when preparing to adopt a new methodology is not planning for the upheaval it will cause: Training and learning curves, changes in operational behavior and metrics, and impact the schedules. Changing the way a business works means everyone has to relearn what they do on a daily basis. This means considering what it will take to implement the methodology within an organization as a whole, and achieving a level of investment in the effort by all the stakeholders.

Team members need to be trained, business units need to be integrated into the process, schedules adjusted to accommodate the new methodology and in most situations a significant learning curve will translate into a slow, steady adoption — as opposed to a sudden, rapid adoption. The former approach provides an opportunity for participants to learn the usefulness of different aspects of the methodology and to gauge its success. The latter approach — attempting to make a complete, rapid transition — often leads to failure during adoption. Too many interdependent processes that are not well-understood by the team leads to poor execution. This can lead to missteps during a pilot project, a time at which such mistakes are highly visible. Not having a steady, progressive and measurable improvement against existing techniques means criticism will come easily.

Measure your success

Creating positive, measurable metrics that demonstrate the benefit of a new methodology is critical. Part of the process is making sure training costs and the cost of adoption is tied directly to business goals. By coupling the business to the methodology, all stakeholders have a vested interested in success. Good metrics demonstrate that progress is being made — both providing a positive measure of success, and avoiding the need for a “big bang” success right out the gates. And, if you aren’t already tracking metrics and measuring success, this is an ideal time to find a management methodology that will.

Why Agile isn’t enough (and why it doesn’t work)

Agile methods are powerful tools when used properly — but as with all tools, they can be misused. The critics of agile methods are many and vocal, often looking at agile as a host of poorly thought-out and incomplete “shortcuts” that fail to get the job done. And with  90% of projects failing to meet objectives, the criticism is valid.

So is Agile just hype or is there something to it?

There are strengths to the agile way of thinking, and many of them bring useful perspectives to software and systems development that are new and even revolutionary. Here are some of the things that work — and, potentially, that radically change our old-world practices.

Whereas most legacy methods stem from industrial process — that is, assembling a product using a set of defined, predictable steps — the agile method is empirical. It recognizes that development is more like invention and research, more akin to scientific study, than assembly. This empirical nature is at the heart of the agile mantra: Deliver, measure, adjust and repeat. The strength of this approach often bears itself out in fantastically hyperproductive teams that deliver working product far more quickly than legacy methods, such as waterfall, could ever achieve.

Agile does this by cutting through complexity. Every agile-based methodology focuses on simplification of otherwise complicated problems. For example, XP and Scrum both emphasize development of near-term, complete deliverables. This means carving out tangible and reasonably independent pieces of work, focusing on that work, and then — at least as much as possible — moving on to other work. This approach requires that large, complex problems are broken down into manageable pieces and thought of on a micro-deliverable level. Likewise, this approach minimizes ceremony and eschews as much procedure as possible. Some agile methods go to extremes in this regard, focusing entirely on delivering work product and not at all on procedure. This translates into minimizing complexity on a large scale.

Closely related to eliminating complexity is agile’s focus on progress measurement. Most agile methods measure progress chiefly, if not exclusively, in terms of delivered work product. Most methods also are quite stringent in defining progress only when finished work is delivered, which means you can’t work for nine months on a single big feature. Instead, micro-deliverables target key features, deliver those features into the customer’s hands, then moving on to new features. This can be a huge strength because the customer gets working product in-hand to review early, and often. It involves the customer early in product evolution, leading to a host of benefits including better product targeting, prioritized development and improved quality.

These characteristics of agile methods combine to fundamentally change the way software and systems development is practiced. Agile also empowers individuals to become stellar performers. In fact, all forms of agile rely on this to some degree — with more lightweight agile methods being completely dependent on individual empowerment. The idea is that an empowered team will leap over constraints to get the job done, no matter how “out of the box” the thinking needs to be. It’s a refreshing concept and one that can indeed be supremely successful, but it does require the team to embrace the idea wholeheartedly.

Another benefit, at least in some situations, is the creation of self-organizing teams. Partly because of the light ceremony, the fast pace, and the penchant for empowerment and accountability, teams become self-organizing. This works when the team has the right make-up, as individuals step up to take on tasks best suited to individual skills. Self-organized, empowered teams become very powerful and very productive, provided that the team members are up to the job.

There is absolutely no doubt that agile methods make it possible to get things done quickly. That’s what it’s all about, after all. The real question to me is how much of this tradeoff is really desirable? How often do we want to eschew process and maturity in favor of getting things done quickly?

More importantly: Can we effectively merge the best attributes of Agility with the most valuable benefits of established processes and standards?

Why Agile doesn’t work

When an agile project fails, it generally does so spectacularly and predictably. The common failings of agile-based projects are just that… common. We see the same problems over and over again, and this has become the basis for many critiques of agile methodology. After all, if we keep seeing the same problems crop up again and again, isn’t this proof enough that the process is flawed? This becomes clear in hindsight, so why do we continue to see 90 percent of projects missing the mark?

The fact is, agile by itself is just one tool in the toolbox that should be applied with other implements of the trade. In my experience, the problem comes in most often because small- and mid-sized organizations experience brilliant success with agile and then assume it can work everywhere. They throw out the toolbox (or perhaps never buy one in the first place). Yes, agile can succeed. Yes, it can deliver fantastic productivity and stellar results. But not always — in fact, I will go so far as to say not often.

This isn’t because of agile’s limitations. Instead, it’s because of overconfidence by those putting it to use, and the mistakes an immature organization makes as it grows and applies it inappropriately.

Immature companies and teams are cutting their teeth, again and again, on the limitations of agile.

All agile methods make it easy to oversimplify complexity. In fact, agile’s strength of eliminating complexity might be better stated as “ignoring complexity.” There are appropriate situations for this but, more often than not, ignoring complexity leads to problems. Most business cases don’t call for undefined delivery dates or loosely changing requirements and partial deliveries. These are risks that most business models are incompatible with. If the risks aren’t something that your business can sustain, adopting a purely agile process is taking a huge gamble.

Likewise, focusing on the near-term is an agile attribute that introduces a lot of unknowns into the business-end of an equation. Few people will contend that agile is appropriate for mission critical efforts such as, say, launch vehicle development, as sometimes requirements need to be set in stone before anyone starts development. But what about situations where some degree of fuzziness is acceptable or even beneficial? Agile advocates compatibility with change, sidestepping change control procedures that would otherwise place tight controls over requirements. Requirements change carries with it a heavy burden, particularly when it comes to the cross-organizational impact to marketing, budget, quality management and the customer. However, cutting change control, requirements management, and configuration management from the process can lead to long-term disaster that the short-term perspective of most agile methods will overlook.

This theme of reducing structure and control has cut out many waterfall-origin processes. The danger often manifests as small-scale agile projects are successful, leading to wider-scale adoption of agile. But, as the projects grow in complexity and criticality, major missing components in the process become evident. For example, no agile methods today integrate comprehensive quality assurance procedures (in fact, thanks to some early mistakes, such as MIL-STD-498[#], most people think quality assurance is software testing — it’s not). Structured software testing often becomes an afterthought, and risk management programs tend to be regarded as “fuzzy disciplines.” Yet, these are the processes that successfully put man on the moon, that develop health care and financial services systems, and ensure that nuclear plant regulatory systems don’t fail after delivery. Of course, there is a cost to each of these processes, and every business needs to weigh the cost-benefit of adopting more process against cutting those processes. This needs to be an on-going evaluation, made as projects, organizations, and teams evolve — it’s not a decision that stands alone.

From a purely hands-on, management level, agile methods pose “people problems” as well. The strong emphasis on self-organization and empowerment can easily backfire. The former relies heavily on people that are capable of self-management and self-direction. Not everyone can live up to that expectation. The latter, delivering empowerment to the team and individual, can lead to a hero mentality and silo’d teams that refuse to play well with others. As projects grow in size, complexity, and dependency on other teams and resources, these characteristics become the drawback of an immature organization.

Almost all agile methods oversimplify valuable processes. In some situations, the project survives the oversimplification. Sometimes the business is tolerant of the fallout. In every case, agile methods expose the project to risks that stakeholders should be — and often are not — aware of.

What to do about it

We need to be cognizant that one solution does not fit all problems. While an agile method such as XP or Scrum may have led to success in one project, this doesn’t make it a foregone conclusion that it will do so again. Each project is different, and organizations evolve over time. Adopting one process to solve all problems is a sure recipe for failure. On the other hand, having a well-versed team that can draw on several methodologies, as appropriate for the job, is a recipe for success.

If your organization is looking for the one-size hammer to hit every nail, make sure it’s as configurable a hammer as possible. Don’t choose something that is either too lightweight, such as XP, because many projects will overreach the capabilities of such a lightweight process. Likewise, don’t try to implement a full-on waterfall style methodology either because, while definitely thorough and capable of getting the job done, it’s just overkill for many smaller projects. If you must choose a single process, pick one that’s efficient, borrows from both agile and waterfall, and is highly configurable, such as Rational Scrum or the Rational Unified Process. Both of these have the maturity to deliver large-scale projects, but also support starting small and adopting minimum ceremony.

A better awareness of what specific agile practices can and cannot accomplish is key. For example, Scrum is not a development methodology, and it cannot effectively deliver software or hardware projects unless it wraps itself around one. Yet today many organizations are employing Scrum as if it were a development methodology. I’ve even seen an organization of several hundred developers “force fed” Extreme Programming from the top down. The outcome of that particular operation: Mid-level management hid the fact that they didn’t use XP from top-level management after everyone realized what a mistake it was. Perhaps we’ll have to wait for mature standards in education and certification to evolve, but personally I’m not sitting idly by.

One of my personal pet peeves in the technology industry is a relative lack of standards and qualifications. Would you go to a doctor that didn’t have a medical degree? Would you hire an architect that didn’t have an appropriate engineering degree? Yet we hire software professionals (much less often hardware professionals) without adequate education, current qualifications, or meaningful certifications. For that matter, the proliferation of meaningless qualifications (such as Scrum Master certification) continues to weaken the industry. In the long run, we need better standards regarding education, accreditation and certification.

Understand agile methods for what they are. Keep in mind that lightweight process carries risk. Use the right tools in the right situation.

Coming full circle

If we add all of these things to agile methods, won’t we just end up using waterfall process all over again?

I don’t think so. Waterfall-based process, the original behemoth processes born out of industrial process, are widely recognized as inefficient. There are tremendous advantages to pressing forward with a merger between waterfall practices and agile practices. I hope the end result is a new generation of software and hardware development methodology — a generation that we’re just starting to see as processes such as Rational Scrum come to the fore. It’s time for development methodologies to evolve, and there’s no holding that back.

Scrum is not an agile methodology

People have lost sight of the fact that Scrum is not a methodology. I see comments such as “Scrum is killing agile” and it drives home, with emphasis, that there’s a huge disconnect between understanding what an agile methodology is and what Scrum is (and I know I’m beating a dead horse, but it’s important — because Scrum is not a methodology!).

Let’s start at the beginning and reiterate this original statement from Schwaber and Beedle, the creators of Scrum:

Scrum is a management and control process that cuts through complexity to focus on building software that meets business needs. Scrum is superimposed on top of and wraps existing engineering practices, development methodologies, or standards.

Scrum is a process. One process, that must be taken and combined with other practices, methodologies and standards. A process does not, in and of itself, create a methodology and for this reason I say that “Scrum is not an agile methodology.” I might even go so far as to say “Scrum is not Agile,” but that’s misleading — because as a process, Scrum is compatible with and enhances agility, either taken as an “Agile methodology” or a general practice of being agile.

As Scrum has become more of a buzzword it runs into this dichotomy more often. I experience this frequently with my clients, where the dialogue goes something this this:

Me: “So, what methodologies do you follow?”

Client: “We use Scrum.”

At this point, I feel as if, say, I’d asked for a bowl of fruit and being given a bit of jam.

Me: “Yes, but that doesn’t answer my question since Scrum is a management process, not a methodology — do you use any development methodologies?”

This last is often poorly received. It’s at this point that I typically remind my client the reason I’m here is because they’re having trouble, and the reason is likely because of poor internal processes.

Methodology is a body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry. In the context of software and systems engineering, it specifically addresses how we manage the conceptualization, specification and delivery of the software. Scrum does not cover any of this. Scrum is just a management process that can be applied to pretty much any business situation.

A good methodology is going to provide a framework in which requirements capture and management is specified. Project parameters and management criteria, such as reporting structure, authority and responsibility, status management and progress management will be specified. Program assessment goals and objectives will be specified. Assessing organizational capability and planning growth or acquisition may be needed. How requirements are stated, what depth they must go to and what standards must be met, and how to manage change in requirements will be specified. Likewise, quality assurance processes will be set forth (for example, audits and controls will be put in place to ensure requirements meet agreed upon standards). Testing of the product will be standardized as well: What techniques will be used, what are the goals of the test program, and what will the output of the test program be? User acceptance standards should be specified and usability testing programs implemented. Transitional phase operations, often overlooked until “after we’re done,” need to be planned and prepared for — and then executed. Scheduling, resource planning and budget management are of course a key component of any well-run program. And through it all, meaningful measurement criteria must be established and communicated to stakeholders.

Scrum touches only the tip of the iceberg in regard to much of this. This is intentional: Since it’s designed to work compatibly with just about any methodology, Scrum explicitly avoids putting too many constraints in place. More than anything it’s intended to refine an existing methodology and process, improving its productivity through streamlining.

Of course, sometimes Scrum is all you need. A sufficiently senior team, comfortable with the problem domain, combined with a project of reasonable size and a business that’s willing to launch without a clear end-point can work. But more often than not, one of these four essential elements is missing. Perhaps the business isn’t comfortable with an undefined, vague end-point (they may want to know what the budget is, or have a hard launch date). Perhaps the team is new, hence the necessity for more structure and measurement. It’s a rare situation that we can dive into a project with no methodology, only the Scrum process, and come out the other side in a favorable position. Sometimes it will work, but it’s a gamble — and often a gamble that the business isn’t willing to bet on.

I’d like to stop hearing “we use Scrum” in response to the question “what’s your methodology?” It’s great to say, “Rational Unified Process with Scrum to streamline it” or perhaps “XP with a Scrum wrapper so we have better visibility,” but please don’t try to deliver software with “just Scrum.”

Making Scrum work: Common failings in adopting Scrum

Scrum has been the happy recipient of a great deal of hype in the past few years. In fact, it’s been hyped so much that it’s becoming the “next best thing,” a phenomenon that can sometimes end up being detrimental to the general market perception of industry focus: As more and more people jump on the bandwagon “Scrum” becomes the hot topic of the day. The problem is, many of the people using Scrum have only a vague understanding of its principles and place in the software development life cycle.

Scrum can be remarkably beneficial in many kinds of software projects. But, as with any process, methodology or management technique, when used inappropriately it can cause more problems that it solves.

In this article I’ll discuss some of the common misconceptions and “lessons learned” as related to Scrum.

You don’t need training to use Scrum

This is the most important one in my mind: Training is just as necessary with Scrum as it is with any other process. I’ve run into many teams that eschew formal training in favor of simply “reading the book” or sending one lead engineer to a quick Scrum certification program.

Let’s look at it another way: For upwards of 30 years, the software development industry has followed a largely industrial process (sometimes called “waterfall” or “spiral,” depending on your particular experience). Across that time, many professionals have struggled with the complexity of software development, striving to create a process that is simple, reliable and repeatable. More often than not, to varying degrees, the industry has met with failure: Nobody has turned software development into a wholly reliable, repeatable procedure that always hits its goals dead-on.

Scrum is a process that has evolved out of this 30 year history. While the process itself focuses on simplicity and emphasizes a set of easy to follow practices, this does not make it inherently intuitive or trivial. In some regards Scrum is so contrary to established process that many team members just “won’t get it” unless they experience it in a learning-enabled setting. Training is critical, and I highly advocate sending your entire team to a Scrum workshop — or, better yet, bring the workshop to your team. Good programs exist that will turn your training session into a guided working session, which means your productivity will not be hurt by sending people off-site for training. Just the contrary — your productivity will leap ahead in just a week or two as training, learning absorption, experience and actual hands-on work all combine to create a Ken Schwaber’s original goal for Scrum: A hyperproductive team.

Scrum is all we need

Often sung to a Beatles inspired tune, I’m afraid it’s not true: Scrum is not all you need, and any idyllic fantasies otherwise will be met with dashed and broken hopes on the rocks of failure. Scrum is not a complete methodology, it’s a management control process — and that implies that you still need methodology. Don’t take my word for it, take Ken Schwaber’s, the creator of Scrum: “Scrum is superimposed on top of and wraps existing engineering practices, development methodologies and standards.” (Schwaber & Beedle, 2002; Agile Development with Scrum, p. 2).

Scrum is an excellent control process that helps us cut through the red tape of more traditional, bulkier control processes. It helps us to focus in on what’s important. It enables accountability to an extreme degree and, through accountability, achieves greater productivity. Its empirically driven measurement technique is well suited to the often experimental development environment of new products, such as inventing new software.

Nowhere in the Scrum process itself do we discuss development methodology. This means we must bring our own methodology to the table and wrap Scrum around it, enhancing processes that have not been hyperproductive and increasing their productivity. In other words: Software quality assurance, formal testing, configuration management, risk analysis, budget planning and project scope planning, verification, requirements management and specific methodologies such as the Rational Unified Process, Extreme Programming or Spiral programming must also be part of the equation.

The backlog replaces the Project Design Document

Here I’m essentially belaboring the point that Scrum is not all you need. Different development methodologies employ different kinds of design strategies and documentation strategies, but one thing is common across almost every single methodology: There is always a Project Design Document (PDD) in one form or another. The project backlog is not a complete design document. A well-implemented project backlog is going to provide enormous technical detail and will probably fulfill all the requirements for a technical specification — but this is only part of the PDD. Team collaboration is not a substitute for someone putting the product design specification in writing.

The Project Design Document addresses a host of project objectives and requirements that simply won’t show up in the project backlog, at least not in an easily interpreted, cohesive fashion. Some of these include: Overall project scope; market objectives; user interface models; business models; user acceptance criteria; original customer requirement statements or vision statements; a project baseline; key risks and mitigation strategies; user interface style guides; software architecture and software integration procedures; and the list goes on. Many of these artifacts will, in time, turn into very specific project backlog items, but many will not. It’s important to document not only the specific, day-to-day deliverables of the project, but also the overall goals, architecture, and design guidelines.

One of my favorite product suites for managing both the product backlog and project documentation is Atlassian’s JIRA and Confluence. Combined, the tools provide fantastic support for managing tasks and deliverables (the project backlog) and a collaborative documentation environment. The ability to seamlessly create links between the JIRA tickets and more in-depth, collaborative Confluence documentation is an excellent tool. It allows the team to expand on technical detail and cross reference extended documentation, all within the context of the product backlog.

The 15 minute daily scrum is unnecessary

I’ve run into a lot of resistance to the daily scrum, especially very early in the process of introducing Scrum to a new team. Nevertheless, within a matter of a month or two, the value of the daily scrum has been realized and wholly adopted by all of the teams I’ve led.

One of the worst situations you can get into is a “fuzzy scrum,” one that doesn’t start on time or that exceeds the boundaries of the meeting on a regular basis. If the Scrum Master shows up five minutes late, then politely waits ten minutes for everyone to gather, a focused 15 minute briefing turns into a 30 or 40 minute distraction that everyone resents. Stay focused on the daily scrum rules of conduct — specifically, start on-time every day, in the same meeting place. The Scrum Master must arrive early and be ready to kick off precisely on time. If someone is late, don’t hold up the meeting. Use a timer to casually ensure that everyone gets a turn, and nobody goes significantly over their time limit.

A well-structured 15 minute daily scrum will benefit the team enormously. It keeps the entire team apprised of progress and current goals. It helps to focus the team, avoiding situations where one person gets derailed, instead giving them support from the team. Remote workers and partner-vendors will stay in-touch with current goals.

I can’t count the number of times something has popped up in a daily scrum that resulted in days, potentially even weeks of gained productivity. I’ve seen team leaders that sit next to their developers react with surprise when they hear what an individual is actually working on. In situations like this, enormous effort has been saved when the team leader corrects the objective right then and there.

I’m not allowed to work outside of the sprint goals

Another very frequent misconception is that Scrum introduces artificial roadblocks; for example, forcing the team to work on current sprint goals and nothing else. This is only partially true: It is correct that Scrum focuses the team on the current sprint. The objective is to complete the sprint and then move ahead to the next set of objectives. This means that an individual team member must finish their sprint goals and, ideally, try to help out other team members with other goals, if possible.

However, once the team member is done with their sprint goals they are free to “look ahead.” There is nothing that says a team member can’t start working on the next sprint ahead of schedule or — if the next sprint doesn’t have enough definition yet — even draw directly from the product backlog.

Scrum is about productivity. It will never require the team to stop work because of an arbitrary set of procedures or policies. Quite the opposite: Well implemented, Scrum enables the team to become far more productive than previously possible.

We don’t have to adopt all of Scrum

This issue has come up with every single client and, I fully expect, will continue to do so. Technically, it’s true — but not initially.

As with any process or methodology, it’s critical to understand how the process works properly before customizing it. Scrum should be followed entirely and rigorously for at least the first month or two of a project. Ken Schwaber’s recommendation is to do so until “several sprints” have been successfully delivered and the goals of achieving a hyperproductive team are met. As Clara Ko writes in Jeff Sutherland Talks Shock Therapy For Scrum, “Perhaps there are good reasons for excluding some parts of Scrum, but without truly understanding the reason behind a Scrum practice or the implications of skipping it, agile teams struggle to become hyperproductive, or mistakenly, struggle with Scrum itself.”

In other words, before changing Scrum, become an expert in it. Once the Scrum process has become second-nature it becomes much easier to begin customizing it or cutting pieces of it out. It will also become clear why something stopped working smoothly. Past experience will give the team the awareness to know the process broke because it was changed, and the motivation to move back to a working process.

With proper training and guidance, teams uniformly experience incredible productivity gains with the Scrum process. They key is adopting Scrum correctly, and that means doing it with the right level of training and commitment, especially early on. Process change is never easy, and while Scrum may appear to be a simple process it is not an intuitive one.