If your organization is currently following something like a waterfall process, the people at every stage in the cycle may be comfortable with the roles they have, and won't be anxious to try something new. You may need to show them just how much more effective and productive the organization could be with a scrum-based process.

Executives may be concerned they'll have less control over a team that self-organizes, and that they'll have less input into a process that generates its own ideas. Point out to them that an agile process gives them the opportunity to shift and adjust priorities every sprint, adapting to the marketplace more effectively, while providing valuable feedback that they can use to help guide their decision-making process.

Engineering managers may be confused about what their role is in a team that manages itself, but that concern grows out of a semantic misconception about the concept of a team being self-managing. Managers are still essential to help the team allocate resources, resolve personal issues, and identify and retain talent. Managers also bring their own background and knowledge to the whole development process. Engineering managers are free to dedicate a portion of their time to hands-on work as one of the engineers on a team, but their main responsibility is securing the team's place in the organization, making sure they have the tools and resources they need, and defending them from distractions so they can continue with their scrum process.

Designers may wonder how they're going to fit into a scrum process, when their work doesn't necessarily follow the same cycle as the rest of the team. Show them that scrum provides designers with increased opportunities to have more impact before decisions get made, because designers can be involved in every stage of the development, and participate from the planning stages all the way through release.

Engineers may be concerned about the change in their roles, especially if they've gotten used to doing one thing very well. Agile puts a greater responsibility on each engineer to play a broader role on the team, but it also opens up new opportunities for learning and growth. The stability provided to engineers by commitment to a sprint, and the confidence that the requirements they've agreed to won't change until the sprint is over, may be strong selling points in an organization where interruption and chaos have been a problem.

Adopting agile isn't a one-way conversation. The champions of scrum should listen, and learn from the concerns of the people who are going to be asked to change their approach during this process. For everybody, it's useful to remember that scrum is always an experiment that's just going to last for the length of the next sprint, with the opportunity at that point to revisit and change anything that doesn't seem to be working. Sometimes the experimental nature of scrum is one of the most compelling arguments for giving it a try.

Although scrum isn't that complicated, and can be described pretty thoroughly in a book, it's invaluable to have the team trained by someone from outside the organization who understands agile.

An objective, third-party trainer can step into an organization and see problems in a way that a person inside the organization may not be able to. A good trainer will also be able to coach people through some of the more subtle or complex aspects of the process, making sure they have a full understanding not only of what they're doing, but why they're doing it.

Scrum training can take one or two days for the entire team, and may be best done off-site, in a neutral place where people won't be distracted by the day-to-day work currently going on. Don't try to shortchange your organization by giving them less training than they need. It's too easy to start applying the labels of scrum to a process that's anything but agile.

Getting everybody's active and focused participation is important for the scrum training to take root. Anybody who isn't properly trained may not understand how scrum is supposed to be applied, and that can lead to frustration and confusion that's easily avoided with a little preparation.

The list of people to invite to the training should include some representatives of senior management, as well as all the people in the organization who are going to be participating in the rituals on a daily basis. You don't have to get everybody in the company trained, but anybody whose role involves direct interaction with the scrum team is a likely candidate.

It may not be necessary to hire anybody new in order to implement scrum in your organization. Most of the roles in an agile team can be filled by people who already exist in the organizational hierarchy.

A product manager may be a likely candidate for the product owner role on a scrum team. Engineers—whether junior, senior, or management—should all be considered equal on the development team for the sake of scrum, despite the differences in their ranks in the organization. Often QA engineers are also included in scrum, which provides a number of benefits in terms of redundancy, cross-training, and organizational reach.

Project managers may be the best people already working in the organization to step into the role of scrum master, with some training about the differences between the skill set involved in managing projects versus running scrum. In a pinch, any member of the development team can be trained to act as scrum master. However, a good scrum master may be the best new hire to make when implementing scrum.

Somebody who understands how scrum works, and is familiar with the issues that can arise, can smooth out the rough edges more easily than a person just getting up to speed with the process. It's less important for a scrum master to be familiar with the type of work you're doing than it is to have someone good at coaching people through the scrum process.

Scrum is all about establishing a sustainable process that adds real value, and reviewing that process on a regular basis in order to make sure it's producing the desired results. So why not use agile techniques to make sure scrum is working for your company?

One of the most useful techniques when implementing scrum in a new organization is to establish a baseline of productivity before scrum, and use that to measure the effectiveness of scrum. Where you establish that baseline, and how you measure it, are very subjective. Each organization has its own standards and productivity indicators.

For example, a web development team may judge itself based on the number of comparable features it's able to add to a website. A mobile development agency may track how quickly they're able to get from concept to implementation with a typical client. The ability to fix or address bugs may also be relevant. Ask around, and find out how the company currently judges its own performance. (You may be surprised at how little formal attention is paid to the matter.)

Before implementing scrum, pull together a representative sample of data about the performance of the organization without scrum. That way, you'll have a comparison point to use when evaluating how effective scrum is, and reporting on it to interested parties. Keep updating the data as the team applies scrum and develops its agile abilities.

If you don't see improvements, you can use the scrum process to raise the issue during a retrospective, and figure out what's working, what isn't, and how you can improve.

When a team is starting out using scrum, they may not understand how much time to allocate for their rituals. Defining a time box in which the ritual must be completed helps focus everybody's attention, and shows respect for the team's time. There's a temptation for new teams unsure about how much time to allocate to leave the time box undefined for the various aspects of the ritual.

It's especially important when teams are starting out to define time boxes explicitly for every aspect of a ritual. Sometimes these time boxes may just be guesses, and the team will need to learn by iterating from sprint to sprint just how much time they need. It's better to propose a wildly incorrect time box and try to enforce it than it is to leave the time box loose. The exercise of proposing and enforcing time boxes demonstrates respect for the team's time, and respect for the process.

There are some experts who advocate reducing the length of time boxes to the minimum length possible when teams start exceeding their time boxes consistently, and then working closely with the team to help them get through all the stages of each ritual within the very limited time that's been allocated. This helps establish the importance of defining and respecting the time box for each aspect of the ritual. And if the team mentions at the retrospective that the time box was too short, it can be extended by consensus for the next sprint.

There comes a point at the end of many planning rituals when the team is agreeing to a backlog for the sprint. At this stage, the product owner should already have organized into priority order the stories that have been estimated, and considered what would make a sensible increment for the product at the end of the sprint.

As estimated stories get moved into the sprint backlog, the team discusses how much work they believe they can get done that sprint. Often, the last story added to a sprint backlog will not be large enough to bring the team up to their projected velocity based on their historical performance. At that point, the team may try to negotiate with the product owner about the order of the remaining stories, in order to get a story with the optimum number of points added to the sprint backlog so their commitment exactly matches their expected velocity.

This unwise exercise is optimizing for the sprint, and it demonstrates a basic misunderstanding of the point of scrum. The prioritization of the stories, and the purpose of working on them in order, is about adding value to the product, not pushing forward an agenda around optimizing the scrum process. When it comes down to it, the work is more important, not the number of points completed in a sprint.

It's better to leave that sprint backlog a little short, and agree with the team that they may start work on the next highest priority story once all the stories they committed to in this sprint are done. After the commitment for the sprint backlog is completed, it's perfectly fine for the team to start working on a story of any size that has the next highest priority, even if they don't expect to complete it within the same sprint. Ultimately, the team's point velocity is estimated across multiple sprints, and it will all average out.

The purpose of the daily standup is to capture the heartbeat of the team, for the sake of the team. These rituals are kept short in order to respect everybody's time. One of the first mistakes teams tend to make is to treat the daily standup as if it were a team meeting. This could be played out in many ways, including having the team sit for the daily standup, planning announcements at the beginning of standup, and not limiting cross-talk during standup.

Everybody is expected to stand during the ritual, so that nobody feels inclined to let the ritual exceed its time box. No devices or other distraction should be in anybody's hands, and nobody should be working on their laptop or talking about anything other than the story currently being discussed.

It's a slippery slope if you start allowing people outside of your team to include announcements at the beginning or the end of standup. Announcements tend to encourage more discussion, and that can quickly lead to standups that last longer than 15 minutes.

There should only be one person speaking at a time during the standup, and that person should be the engineer discussing what was done since the previous standup, what will be done by the next standup, and whether there are any blockers. Issues will come up that need further discussion, but that discussion needs to be taken off-line for follow-up after the standup is completed. Everyone on the team should feel empowered to support the scrum master in cutting off other conversations and keeping the standup focused.

One of the premises of scrum is that the engineers will have the opportunity to plan ahead for the duration of the sprint, without worrying that their work is going to be interrupted by distractions and side projects. The team commits to a sprint backlog, and it's up to everybody to defend the integrity of that backlog and not allow additional work creep in.

The reality—particularly for web and mobile development teams—is that things come up. Servers go down. Features break. Time-critical announcements happen. Users get confused by new features and they need to be adjusted. Urgent issues need to be addressed that were not anticipated when the sprint began.

In traditional scrum, any change to the stories committed to in the sprint backlog demands that the team stop the sprint, go through a new planning ritual, and establish a new sprint backlog. This is considered a draconian measure, and has been put in place to discourage anybody from violating the integrity of the sprint.

Web and mobile development teams need to incorporate a certain degree of flexibility into their process, due to the dynamic nature of their work. It would be very impractical if the team had to start a new sprint every time a broken form needed to be fixed, or a press release needed to be edited. But there's a balance that must be maintained. It would be just as inefficient if part of the team had to drop everything and start working on a new, urgent feature every time an executive or a client got a brilliant idea for a new feature.

It's the nature of web and mobile work that the team needs to be flexible enough to deal with emergencies, but they also need to be strict about what constitutes an emergency. This is something the scrum master, the product owner and the team should define explicitly as part of the team's scrum contract.

Any new work pulled into a sprint should be expected to reduce the team's velocity. That additional work should not be estimated, since it was not part of the team's sprint backlog commitment. If the team starts allowing new stories to creep into a sprint on a regular basis, that will pull them away from their backlog commitment, and will be reflected in their velocity.

Making time to address urgent issues is essential, with the understanding that urgency is a concept everyone on the team needs to agree on. If the integrity of the sprint seems to be broken too regularly or too casually, it's something the team should definitely be discussing during the retrospectives.

Every team needs to come up with a clear definition of done. Part of that definition should always include meeting all of the story's acceptance criteria as it was written. This gets tested during the demo. It's important to be consistent about the way stories are accepted at demos, and not to allow the standards to get too flexible.

One common issue that comes up is teams that allow stories to be accepted when the acceptance criteria are not fully met. Sometimes, stories are accepted into a sprint, but the work on them lingers into the beginning of the next sprint, because they were "almost done." This confuses the end of one sprint and the beginning of the next, making it more difficult to say clearly what was done in one sprint, what needs to be done in the next one, and what the team's real velocity is.

It's also vital that teams come to demos prepared to demonstrate all the work they did in the sprint. Frequently, teams find themselves sitting around waiting while the developer finishes deploying code, or adjusting the staging environment for the demonstration. While it's reasonable to expect that there are sometimes emergencies that get in the way, it's the responsibility of the developer who worked on the story to make sure it's ready to demo, and that the product owner knows how to walk through the demonstration.

Some teams take a very strict approach to this, not accepting any story that isn't an exact fulfillment of all of the acceptance criteria and ready to demonstrate at the start of the demo. While that may seem harsh, the important thing to remember is that getting things into the sprint is not as important as getting the work done.

Teams can be as severe or as lax as they like around their demo acceptance criteria, as long as they're consistent. There's nothing wrong with erring on the side of being severe, and making sure that what was done in the sprint was completed within the sprint. The critical issue is to make sure everybody agrees to the process and understands the importance of following it.

Without retrospectives, scrum doesn't have the opportunity to learn from its mistakes, or benefit from its excesses. Retrospectives also serve a strong team-building function, in that they allow the team members a chance to share what's on their mind with their colleagues. While the most common problem teams have with retrospectives is not holding them at all, next on the list would be trying to resolve the problems that come up during a retrospective at the ritual itself.

Retrospectives are an opportunity for everybody on the team to bring up anything they think went well or didn't go well during the previous print, and to discuss how to address the issues going forward. This touches on potentially sensitive topics, and can bring a lot of emotions to the surface. For people who feel they may be on the negative side of a discussion, there's a strong impulse to try to resolve the problem then and there.

There are several reasons why a retrospective is not the best occasion for resolving issues that come up:

It's up to the scrum master to remind everybody that the retrospective is not an occasion for solving problems, but rather for recognizing that they exist, and for then committing to solve them during the upcoming sprint.

It's reasonable to allow the conversation around a problem to go on for a little while, so that people have the opportunity to fully understand all sides of an issue, and commit to finding a reasonable resolution during the sprint. But if that discussion gets too deep into the details of how to solve the problem, it may be time to cut the discussions short out of respect for everybody's time.