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.

Related posts:

1. Making Scrum work: Common failings in adopting Scrum
2. Scrum is not an agile methodology
3. Why Agile isn’t enough (and why it doesn’t work)

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.

Related posts:

1. Making Scrum work: Common failings in adopting Scrum
2. Scrum is not an agile methodology
3. Common oversights in choosing methodology

Probably the most difficult situation is the latter — a boss that’s too hands-on, or perhaps an external resource that is too busy, yet absolutely must approve every decision. The story usually goes something like this: He’s a great guy, pretty easy to get along with when it comes right down to it — but he’s also insufferably “hands-on.” He’s just got to review every critical decision, contributing, fine-tuning and tweaking until it’s just right. This micro-managing mentality is causing all kinds of bottlenecks: Decisions are held until the last moment, changes are made late in the game, and your entire department suffers — staying late to “catch up” after your boss delivers his final word on any given issue. But here’s the real kicker: He’s good at what he does, and even though it creates internal chaos the finished product is that much better for his input.

Consider the image to the right: A critical “quality spike” representing the single project resource that is overloaded. This resource does raise project quality, but the spike also represents a huge bottleneck to the project.

Your department has tried everything: Getting him involved earlier in the game (it doesn’t work, his schedule is booked and it always presses to the last moment); Involving other review sources so your boss’ input is minimized (that helped a bit, but the other sources don’t like it when your boss overrides their contribution); You tried publishing the “departmental cost” figures that show all this inefficiency (but the powers-that-be seem to feel this is “just the cost of doing business”).

This is not a simple problem. It gets right to the root of the dynamics created in working teams. How can the situation be improved, realizing positive gains in a habitually entrenched process that some recognize as painful, but overall is regarded as good enough?

There are really two issues that need to be dealt with here. One is obvious, one perhaps a little bit less so. Most strategies up until now have focused chiefly on the primary goal:

“How can we minimize the negative impact of a critical resource (our ‘hands-on boss,’ for example) that doesn’t work efficiently with your team?”

The problem with this approach is that it attacks an entrenched problem head-on, and often does so using a single head-on approach to solve the problem. When an attempt fails, that approach is discarded and another tried. The principle flaw here is that each attempt to solve the problem is, in and of itself, not effective enough to get the job done. A secondary flaw is that each separate attempt tends to get lost in the chaff of day-to-day operations. We all know there’s a problem, but nobody is really tasked with studying it, compiling the entire scope of the problem and its impact, and somehow bringing about a solution.

For example, when your department produced some figures on costs to the organization, those figures clearly showed that, through inefficiency, rework, and last-minute changes, your team suffered. You even went so far as to tie it to actuals, a dollar figure that represented all that overtime and rework — but, it was accepted as “the cost of doing business.” Since it didn’t work, it was discarded — but the fact is, it’s only part of the overall puzzle.

So the head-on solution won’t work. Let’s consider a more subtle approach to the problem:

“How can we make the critical resource less critical?”

This would achieve the same result, but it’s really an entirely different problem — one that can be attacked somewhat obliquely. Rather than focusing on how to change the way your boss works (aka “the critical resource”), try focusing on changing what your boss needs to work on.

The first step toward a solution is realizing that solving this problem is a project, just like any other. It needs a project lead and sponsor. It needs to be handled as an iterative project, and the team needs to recognize that incremental improvement toward an ideal is acceptable. You aren’t going to discover a single silver bullet that solves the whole problem — that’s just not the nature of human team dynamics.

Make it a project initiative

Once your “quality improvement project” is up and running it will snowball. Here are a few steps that will get the ball rolling:

1. Initiate the project. Don’t think of this as a “workplace problem” that needs to be fixed in the short term. Instead, create a project initiative around it and get some mindshare going. Someone is going to need to lead the project, even if it’s unofficial — that person will keep the forward momentum.
2. Focus on making many small improvements across the board. For example, in the case I described above, consider how involving other review sources did in fact help, but not always. That’s an incremental improvement, and it raised the quality of the project a little bit.

Now, consider the impact of this approach over time. If numerous improvements can be implemented, and each one raises project quality just a little bit, it has an inevitable outcome: Your boss is going to have less to worry about, and less to be involved in. This is shown visually in the second image — as the overall quality matrix delivers improvement across the project, the “critical spike” that represents your boss’ workload begins to shrink. This is a quality matrix at work.

The goal is simply this: Dilute the need for your boss to be involved in every decision, by raising the bar in as many places as possible. You will gain a “double whammy” by not only reducing the amount of work he needs to contribute to, but also by increasing his own efficiency since he’ll have less to worry about. The bottleneck will begin to dissipate.

Assemble your team

Get involvement from everyone that’s affected by the problem — your team, your peers, other departments that might be affected. Of course, part of the finesse in this kind of project is to make it clear exactly what problem you are solving without making the project sound subversive or offending the wrong people. Your boss may be a terrible bottleneck, but also remember how valuable he or she is — this isn’t about cutting him out of the picture, going around him, or changing policies you don’t like. It’s much better to focus on things like qualitative improvement, streamlining projects to avoid inefficiency, or developing lean principles. Make it positive, in other words.

Identify key risks

Your probably already know what the main pain points are. Your team experiences them all the time: Loss of productivity, overtime, last minute changes, introducing new errors, reworking something that could already be finished. These are the lesser symptoms of an endemic problem: What are the potential risks if the problem goes unaddressed? Certainly continued loss of efficiency, higher expenses to the company and lower employee satisfaction come to mind. Perhaps there’s even a trend of some team members transferring out of the department to find a better working environment. More dramatic effects can include missed product deadlines, problems with released products or lowered perception of the department’s attention to quality. All of these can have a real financial impact on the company.

Identify those risks that are most significant. Those should become the focal point for initial improvement. This is a “risk driven” model, where high risk is identified — in other words, the most painful or potentially painful result of the problem gets the most attention as early as possible. Generally it’s best to tackle a few things at a time. While the list of risks could be very long, if you try to solve every problem at once it’s going to be overwhelming.

Mitigate

Once you’ve identified the top few risks, pull together your project team and identify candidate solutions. You’re designing something new here, so it’s going to seem like brainstorming — which is exactly what it is:

1. Can more attention from outside experts improve the overall product, lowering your boss’ need to be involved?
2. Would the quality assurance organization be a helpful partner in achieving this?
3. Could changes in the project timeline better accommodate your boss’ hectic schedule? Perhaps driving for earlier involvement (or longer project schedules) would help.
4. Can the team multitask, effectively putting several critical paths into play so that if one gets stalled waiting for your boss, the others move forward?
5. Would better tracking systems and information management help solve the problem? Perhaps your boss would benefit from a system that brings more organization and immediate answers directly to him.
6. Perhaps greater visibility into the project timeline and reasonable deadlines would both improve responsiveness and provide some firm schedule guidance.
7. Information radiators (such as task boards, timelines and assignment lists) might help keep people up to speed on overall project status (and what has moved from “medium” to “high” priority).
8. A widely accessible system that assigns tasks and prioritizes those tasks would increase visibility of current goals as well as get everyone united about what needs attention first.

Every organization is going to discover different solutions that help its specific situation. It will likely take time to hit on the first few steps that move in a positive direction — but those are the ones you want to hang on to.

Include a quality improvement element

Organizations that have the benefit of a formal quality assurance and improvement group should try to leverage the group’s knowledge. Quality assurance is about auditing and measuring progress toward improvement. Most quality assurance groups tend to be very good at measuring improvement over time, and putting that knowledge to use will help in gathering metrics and identifying what’s working, and what isn’t.

Track your progress

Measure, act, measure again, and adjust. This is the heart of most agile development methodologies — and most scientific methods.

The most important thing to do is realize when improvement has taken place. That means tracking information — metrics — about your organization’s efficiency. This can seem pretty amorphous when dealing with a problem such as this. Remember that it comes down to improved efficiency of individuals. Some teams will have simple metrics that are easy enough to track, such as number of projects completed on a monthly or quarterly basis, or number of cases filed. When all else fails, the number of hours committed to rework is a great metric, because it tracks directly to risk identification and mitigation up front. That is, if you properly identify a risk and mitigate it early in the project, the amount of time spent in rework related to that risk goes down.

This is one reason it’s important to have everyone affected by the problem involved: It’s going to require everyone to look for these signs of improvement. It might even require tracking hours spent in rework. Fortunately, with the goal in sight (less time spent reworking and fewer overtime hours) it shouldn’t be too hard to commit people to some moderate tracking.

Gather metrics on what works and what doesn’t work. Emphasize incremental improvement as a desired outcome: Track the results of each effort, and keep the best practices. The important thing here is to demonstrate improvement over time, so that everyone sees each action as contributing to the solution, not as a failure in delivering the end result.

One of the most important goals in creating a project mentality is the positive group effect. Seeing each practice as part of a solution keeps it alive — as opposed to trying something and perceiving failure. As the team, department or company works together to deliver a solution it becomes a self-reinforcing effect. Even your boss might notice, and actively start to take part.

Related posts:

1. Quality assurance as a way of life
2. Exposing the enterprise to risk: Who decides what not to test?
3. Why heroes are bad

I don’t remember where I heard the story about a truck driver named John Barstow. Nearly every day of his life he would drive down Main Street making his delivery to a local store. His goal was actually on 4th Street, which was a one way street and he needed to go about half a block in the wrong direction, so he would pass 4th and turn right on 5th Street, go around the block, and pull up in front of his destination.

One of these many deliveries days, something unexpected happened on the way to his drop off. As he approached 3rd Street, his delivery truck blew a tire. He had to pull over and, upon climbing out of his truck and inspecting the damaged tire, realized he needed to call a tow truck. Being close to his destination he decided to proceed the remaining block and call for help from the store where he made his deliveries. He continued on, passing the one-way 4th Street and turning right on 5th, as usual. He was halfway down the 5th Street, getting ready to turn right and circle back on to 4th, before he realized he could have taken 4th Street this time.

He was on foot.

The quantitative decision — the habit of going around the block to avoid a one way street — won out over a qualitative choice, that of taking a shorter route. We get used to set patterns and “business as usual.”

The technology industry is among a small set of disciplines that takes the consequence of making quantitative decisions to an extreme. Software and hardware are both progressing at a remarkable pace that is, if anything, accelerating. We see this every day as new technologies develop and old technologies evolve. The open source community is driving this effect to an even more frantic extreme, as hundreds of contributors pour their effort into a single product. It is, and always will be, impossible to totally keep up with the pace of change and the challenges of an evolving world.

It’s not enough to define our process or methodology and let it settle in. Yes, we absolutely need to have a clearly defined and adopted set of processes and procedures to ensure a good product. And, those processes and procedures need to become a part of our daily lives so that we don’t take shortcuts and miss important steps. But at the same time, it’s important to never let it become too rote. Watch out for doing something just because that’s the way it’s supposed to be done. Challenge yourself to find out how things can be improved on a daily basis.

Related posts:

1. Making Scrum work: Common failings in adopting Scrum
2. Fix your boss (or, reduce risk to quality using a matrix approach)
3. Why Agile isn’t enough (and why it doesn’t work)

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.”

Related posts:

1. Making Scrum work: Common failings in adopting Scrum
2. Why Agile isn’t enough (and why it doesn’t work)
3. Common oversights in choosing methodology

1. Quality Assurance is responsible for auditing and ensuring all aspects of work meet agreed upon quality standards.
2. Therefore, if QA is also responsible for Structured Software Testing, who is going to audit the testing team for compliance and quality of deliverables?

Quality assurance is the “cop” that makes sure we all do our job right. It has the authority to say “hold it, something’s not right.” Testing is the organization that performs regression analysis on a product to see if it works right. The skills required for these two disciplines are dramatically different — as much as business management and programming.

The value in a QA organization is that it is independent. It focuses entirely on ensuring quality across the organization. Would you want development, project management, requirements management, configuration management, verification & validation, customer service or any other project discipline to report to QA? Why should testing be any different? The bottom line is simply that if testing reports to quality assurance its independence is compromised — the organization becomes vested in representing testing in the best possible light and, just possibly, taking shortcuts or letting a few things slide.

I realize that a large segment of the industry seems to use a different terminology, lumping testing under quality assurance. It’s unfortunate, because doing so handicaps both organizations. It’s important to realize the difference between the activities of ensuring quality in a project (largely focused on standards of process), and fault testing (activities that perform hands on fault detection and diagnosis).

The activities of quality assurance focus on things like quality assurance plans, project audits, requirement audits, checklists, enforcing standards and process, checking the results and deliveries of different teams, and discovering discrepancies between requirements, project artifacts, and functional goals. Quality assurance, as a general rule, spends more time looking at what the project teams are doing, performing audits on the work generated by each team, and figuring out what hasn’t been done according to agreed upon standards.

Testing, on the other hands, focuses on test planning and management, test case development, test execution, regression analysis, performance testing and defect diagnosis. These are “hands on the software” activities and much more akin to programming than auditing. Indeed, with today’s testing tools and complicated programming environments it can be a very “in the code” experience.

Keep your organization healthy and your teams focused on their competencies. Don’t disregard the value in centralizing authority for specific roles with specific teams — it lets them do their job well, without distractions and without muddying the water with conflicting interests.

Related posts:

1. Exposing the enterprise to risk: Who decides what not to test?
2. Fix your boss (or, reduce risk to quality using a matrix approach)
3. Scrum is not an agile methodology

Steve Muench, PhD, asserts that “Training is one of the chief methods of maintaining and improving intellection capital. Because of this, an organization’s training can affect its value.” (Tech Transfer Newsletter, 2004). In fact, the market-to-book value of companies significantly correlates with training as a percentage of payroll according to Bassi and Van Buren (1999). Furthermore, numerous studies have found that the organizational benefits of training are extensive. According to one, by Loewenstein and Spletzer (1998), “the effect of an hour of training on productivity growth is about five times as large as the effect on wage growth.” Research by Bartel (2000) also finds that employers, not employees, ”reap almost all the returns to company training,” going on to conclude that return on investment generally ranges from 100 to 200 percent ROI.

So, the evidence is out there — yet, why are companies cutting back when they should be investing?

One possible reason is a lack of good communication regarding the value of training itself. This is particularly true in small and mid-sized companies. The large ones seem to have it figured out: They do the analysis and understand how important “sharpening the saw” is. When asked if Amgen had made any cuts to training given the economy, CEO Kevin Sharer said, “We haven’t cut back on that at all. Developing people is the future of the company.” (Fortune, 2009).

But smaller organizations don’t have the maturity to understand the importance of training.

Training is investing in the future. Unfortunately, it’s not enough to simply ask the powers-that-be whether they want to make that investment or whether they’d rather remain stagnant while the competition passes them by. In a numbers-driven world, it comes down to dollars and cents more often than not. This means getting out the trusty spreadsheet and doing some math to show its value.

It’s not hard. The key is keeping your eye on the “line of sight” from training to profitability. More than anything, this means making sure that training is directly applicable to the bottom line. Training must become a resource, just like any other cost-oriented tool or expense. There’s no problem buying new software if it leads to profitability. There’s no problem hiring new staff when it means more revenue down the road. So, make the case for training: Demonstrate the return on investment (ROI) that a training purchase will generate, in terms of revenue to the business.

ROI analysis can easily be applied to training expenditures. It’s the same process as any other expense: Does the investment make sense and is it necessary to meet the organizational goals? Sometimes it’s an easy analysis to make. For example, if your company is currently losing money because of a poor process or incorrect practice, compare the current loss to the cost of correcting the problem (that is, the training that will fix the situation). Is the cost of training less than the ongoing loss (keep in mind that the loss is cumulative, continuing to accrue every year until it’s fixed)?

More complicated ROI analysis needs to focus on the financial value of your organization’s goals, and break that value down along the “line of sight” to the training investment. For example, let’s say your product launch is valued at $1 million, but half of that valuation is on the assumption you deliver a specific, key feature. That means your direct key performance indicator (KPI) for that feature is $500,000. Let’s further say that your team can only deliver two-thirds of the desired functionality without training. This means that the training program’s relevance to the KPI is about $166,000. Will the training itself cost less than $166,000? If so, you’ve got a business case to do the training. (You can round out the case with your ROI figure: If the training costs $20,000 then your ROI would be about 830%, which is a pretty darned incredible return on investment!)

If you’d like a more scientific, in-depth study of ROI methods, take a look at my article Should Training be an Integral Part of a Project Budget to Increase Project Profitability?, featured on the leading PM site My Project Management Expert.com. There’s a lot more research and some discussion of current ROI methods, as well as a couple of good examples.

Related posts:

1. Should Training be an Integral Part of a Project Budget to Increase Project Profitability?
2. It’s never a good time for training
3. Common oversights in choosing methodology

One such tool is comindwork.com, a fabulously rich project management software as a service (SaaS) site. While not right for everyone or for every situation it’s definitely worth taking a look at.

Comindwork combines over 250 project management related capabilities under one roof, yet does it with a web interface that is, by and large, a breeze to use. Some of the strengths of the service include traditional project management tools, knowledge management, collaboration tools, information sharing and versioning, and both agile and traditional waterfall management tools (e.g.: think Gantt).

The entry point is easy, and that’s another strength for comindwork: A small team can get started for somewhere around $20 a month (for teams of 10 or fewer, it’s $1 per day that you actually use the service — if nobody logs in, it’s no charge). This offers up a wealth of really advanced tools at a fraction of the cost of most large scale management infrastructure. For companies that don’t have a system in place, it’s easy to give comindwork a spin.

Here are a few of the things I like about comindwork.

It all starts with the personal dashboard. I’m a huge believer in personal (meaning, customized and personally relevant) dashboards, especially if they follow the basic principle of “Getting Things Done” methodologies. Distraction is bad, focus is good:

With the project dashboard, you can:

1. Get a bird-view on all activities where you are involved, see who changed what and when
2. See your nearest milestones
3. Check team members’ status and mood
4. Easily access detailed project-specific dashboards

It offers both traditional (meaning, typically, “large scale”) project management and agile management philosophies living under one roof. At first glance I was taken aback by any system that can claim to offer this mix of tools, but comindwork manages to pull it off. On the traditional side, there are Gantt charts and round-trip import and export of Microsoft Project files, not to mention a whole host of reporting capabilities. On the agile end of the spectrum, to-do lists, tasks and very easy time tracking support simple progress monitoring. Unfortunately, burndown charts have yet to make an appearance, although there’s enough information available that they may not be entirely necessary.

Knowledge management and collaboration are central to the product. Blogs, to-do lists, milestones and business wiki support which codify and share tacit knowledge are tightly integrated into the project. In fact, one of comindwork’s strengths is that so many services are so tightly integrated. For example, linked business wiki entries, tasks and time commitments can be shared and kept up-to-date, with progress being reflected in round-trip Gantt tracking in Project. Notifications of all activity take place automatically, sending out instant email messages or daily digests that summarize project activity.

One of the problems I’ve run into with customers that have no pre-existing system is simply keeping track of all the project artifacts and versions of each. With email flying everywhere, documents being authored, and half the team not knowing how to use source management repositories, how can you hope to keep track of every artifact the team produces? I like to implement a policy of “email doesn’t exist,” but this means you need a tool that’s going to support the policy.

In other words, if someone wants to get something done, it should be in a system, not flying around in email. The idea of half a dozen versions of a document living on everyone’s desktop is just unacceptable to me. Comindwork provides file versioning and drag-and-drop upload. This makes it possible to implement the “email doesn’t exist” policy, and comindwork does a great job of delivering an easy to use tool:

Having a convenient and ubiquitous place to store project artifacts makes it easy for the team to share, manage, and collaborate. Comindwork put enough effort into the interface that it’s not painful:

1. Create a convenient tree-structure of your documents
2. Make common actions on a set of files (mass-delete, mass-move)
3. Provide comments to any file version
4. Versions are stored automatically whenever you upload a file with the same name. Check all revisions and easily revert if required
5. Use drag & drop area for native multiple files upload

You can even email files directly to a folder in your comindwork project.

For more demanding projects, you can design custom workflows to support the security, policies and customer demands of the project. This is an essential tool in my mind. Any project management solution needs to be able to grow with the project. Custom workflow makes it possible:

You can create graphical representation of your business process, modify the process with appropriate business rules and make sure your project is enforcing necessary policy:

1. Define, control and track states and transitions in your business process
2. Encourage process automation and standardization
3. Break your business process into easy to follow step-by-step workflow diagram
4. Reconfigure your business process as needed
5. Clearly define your business process and avoid miscommunication and inconsistency

If you’ve been casting about looking for how to get project tracking off the ground, take the quick tour and see what you think. It’s not a panacea that will fit all project’s needs, but it is a very solid tool that’s been seeing a lot of success lately.

If you decide it’s not for you, take a look at Atlassian’s JIRA too. JIRA is by far my favorite project management tool, especially if you’re agile-oriented. It requires a bit more of an up-front investment to get off the ground (both in terms of deployment and financial cost), but in my opinion, it’s one of very few first-rate tools available today. I’ve been trying to finish a detailed article on JIRA for some time now, so check back in a bit.

Related posts:

1. Fix your boss (or, reduce risk to quality using a matrix approach)
2. Why Agile isn’t enough (and why it doesn’t work)
3. Whole teams

Indeed, a good question: What would we do without the hero?

Let’s flash forward a little ways. The hero has grown tired of the project and leaves. Fears abound that the project is doomed; there’s no way the team will survive without him. Concerns run deep, until the hero tells us he’ll stay on-board as a part-time consultant. Of course, he’s pretty busy these days — but, well, he’ll give us a “preferred” rate and show up at least a few days each week. He’ll keep the project afloat, no worries… in between getting his new company off the ground, of course. The one we’re funding with expensive consulting dollars. Either that, or the hero feels the project isn’t challenging enough, and leaves to greener pastures and more exciting projects, still promising to provide part-time support to keep the project afloat.

Either situation is dismal. Both demonstrate a project and a team that’s being held hostage to the whims of the “hero.”

The truth of the matter is simply this: Heroes are bad for the team, bad for the project and bad for the company.

Heroes are motivated by making themselves indispensable to the project by becoming irreplaceable. Most often this takes the form of information hoarding. The hero understands quite well that the established culture supports his role only while he and he alone can solve the project’s problems. One of the most effective ways to make sure this happens is to keep critical information away from the team. He’s the only expert in a few critical areas, and refuses to share his knowledge because it would be inefficient or too difficult to convey to someone else.

This leads to situations where the hero is subtly motivated to make sure there are instances in which only he can save the project. By ensuring the hero is the only one with the answers, the only one who can solve the problem at hand, he becomes indispensable — and, also, a tremendous project risk. Not only is everyone on the team constantly put in second-place to the hero, they also suffer as a whole when the hero is at his best. In times when the hero “shines,” the team is struggling to overcome roadblocks they haven’t been prepared to deal with. The project falls into jeopardy because the team cannot focus on a solution as a whole. Instead, the team churns in vain trying to contribute to the solution that only the indispensable hero can tackle.

Consequently, team morale is often a casualty of the hero culture. The continued failure of the team to exceed project goals, instead running into roadblock after roadblock, is tiring. Compound this with the fact that only one person, the hero, is enough of an over-achiever to solve the problems of a seemingly over-ambitious project and the team begins to become demoralized. Nobody likes to come face to face with failure repeatedly. Doing so in an environment that doesn’t provide the tools to better oneself is futile, and the hero team leader is certainly not motivated to fix the situation. In point of fact, most heroes tend to be pretty lousy team mentors, as being a hero implies putting oneself above everyone else. This means that while the hero has holed up inventing the next great solution, the team is left to its own devices. This vacuum of leadership provides a poor environment for anyone interested in advancing their skills and career, let alone seeking out a workplace that provides opportunity to learn.

Environments that support the hero become detrimental to the team. With the team leader focused on fulfilling the role of hero, collaboration suffers. Without a truly open, collaborative, information-sharing environment projects function at low efficiency (or, in some cases, fail to function completely as information is silo’d and isolated). In contrast, a healthy team elevates everyone, sharing information and skills, making the hero obsolete and making the entire team indispensable. A collaborative team rapidly turns into a formidable force when its collective attention turns to any problem — such teams turn out productive results faster and more efficiently. Each individual’s growth becomes a focal point, and the positive experience and knowledge gained from such a working environment becomes a lesson that each team member can share. In an open, collaborative, delegating environment the team lead will mentor the team; constantly challenging each person to take on more responsibility and grow into new opportunities. The best team leads are not information hoarders but information sharers, almost trying to engineer themselves out of the equation by teaching everything they know. In fact, this kind of leadership becomes truly indispensable because so few people are able to teach, motivate, mentor and unify a group of people toward a single purpose effectively. It’s not the information hoarded in the team lead’s head that makes him invaluable, it’s his ability to create a hyper-productive team and get things done.

As a project leader it’s important to confront the hero mentality head-on, making it clear that a hero is known for what it is: A detriment and risk to the project. Heroes are a liability. They are a bottleneck to progress, introduce the risk of “hostage projects,” generally make poor mentors and leaders, and always create specific situations that are harmful or dangerous to the project.

Unfortunately, putting an end to hero culture is often not an easy task. Many workplaces that embody hero culture don’t understand the problem — they think everything is “just fine,” and look to the hero as a critical resource, someone that has saved the project or the company time and again. Especially in young or inexperienced organizations, the difference between a supportive environment and a destructive one is unclear. The hero continues to operate above and apart from the team, often disregarding what little authority or direction he disagrees with. Inexperienced team members don’t know they should have a team lead that is mentor, guide and teacher. Organizations can be set up in such a way that the hero figure is empowered beyond reasonable boundaries, as often happens when clear structure and accountability is not in place. Combined, these problems can create the environment where a hero-mentality, embodied in someone who is ill-suited to create unity, lead, and mentor, ends up holding the project hostage. Most often, the evidence will point to the root problem: The team will constantly run into problems only one person can solve; team members will disagree with the hero and often not achieve consensus; much of the team will be “out of the loop,” particularly where the hero is involved; overall, the team will operate either apart from the hero or as individuals, not a cohesive group. Perhaps most indicative: The hero has sole authority over the project, yet little accountability. This is common in so-called “flat” organizations. I tend to avoid organizations that strive to be “flat,” as it’s really just a way of saying “we don’t want to deal with the fact that someone has to be in charge.” The simple truth is that leaders and managers need to have the authority to implement policy. Good leaders and managers will find ways to do it without using their authority unless necessary.

The easiest way to fight hero culture is from a position of authority, such as the project sponsor or project manager role. Given the advantage of authority, the hero can be given a choice: Either become a collaborative leader, or face what amounts to demotion as a new leader steps in. Some heroes won’t be able to make the right decision and will end up leaving the project — but others will embrace the idea of transforming themselves into a positive influence. I’ve seen this happen in a few cases and can honestly say the results were extraordinary. It could be that your hero’s spirit is willing but he doesn’t recognize there’s a problem. Likewise, it could be that your hero is struggling to move into a management role and needs guidance himself. Sometimes you’ll find out the hero was thrust into a leadership role without wanting it, and will happily step aside.

Whether tackling the problem from a position of authority, or from the inside, there are a few strategies that will help to ease the process. Developing a collaborative environment is a first step at ending the hero culture. This means putting in place tools and processes to share information, including an open information environment. Get information out of everyone’s head and into a tool that facilitates group review and commentary, such as a wiki or document repository. This can begin by emphasizing brainstorming sessions, collaborative documentation and group exercises to design and implement solutions. Often group development can be a productive tool, as well (some environments, such as Extreme Programming, push pair programming as one example — I don’t believe pair programming should always be put in practice, but this is a good example of when it makes sense). Project deliverables should also be managed in an open, collaborative environment. Use a project or task tracking system that lets everyone see what’s going on, what’s being delivered and how it’s being done, and most important: Focus on shared responsibility and avoid having unique specialties in favor of collaboration.

The team should also push for opportunities to advance skills and individual knowledge. Avoid “information silos,” or individuals who hold all the answers to a specific problem. It’s healthy for teams to have more than one expert in an area. Not only does it reduce risk, it also affords a more collaborative environment where two or more people can openly discuss a solution and work together on implementation. Any time you hear “only one of us knows how to do that,” immediately think in terms of how you can turn one into two or three people.

Demand a leader that is a good mentor. If the team hero isn’t up to the job, find someone who is — and be vocal about wanting an environment that supports growth. A healthy work environment includes ample opportunity to take on more responsibility. Any project manager that hears you want the responsibility will start casting about for a means to give it to you — and that usually means making sure the team leader can advance his team.

Ultimately, your work environment is in your hands. If you’re aware of the problem, identify it and and surface it — but do so in a constructive way. Have ideas and solutions ready to solve the problem, and emphasize the value it will bring to the team or organization. Focus on the facts as much as possible, like productivity gains the team will experience when it has greater bandwidth, and how getting to market more rapidly (and probably with a better, more robust product) will boost return on investment.

Related posts:

1. Hiring for the culture
2. Fix your boss (or, reduce risk to quality using a matrix approach)
3. Whole teams

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.

Related posts:

1. Why Agile isn’t enough (and why it doesn’t work)
2. Common oversights in choosing methodology
3. Scrum is not an agile methodology