10 Ten Key Factors for Agile Project Success

By Mark C. Layton

Here are ten key factors that determine whether an agile transition will succeed. You don’t need all issues resolved before you begin. You just need to be aware of them and have a plan to address them as early in your journey as possible.

The first three are the strongest indicators for success. Get those right and the likelihood of your success increases dramatically.

Dedicated team members

Team members should be dedicated — product owner, development team members, as well as scrum master — to a single project at a time. This is especially critical at the beginning, when the scrum team and the rest of the organization are still learning what it means to value agility and embody agile principles.

If team members are jumping between project contexts hourly, daily, weekly, or even monthly, the focus on getting agile techniques right is minimized at the expense of just trying to keep up with multiple task lists. Also, the time lost due to the continual cognitive demobilization and remobilization involved with task switching is very costly to each project involved.

If you think you don’t have enough people to dedicate to your scrum teams, you definitely don’t have enough people to thrash them across multiple projects simultaneously. The American Psychological Association reports that task switching wastes as much as 40 percent of time.

Collocation

The Agile Manifesto lists individuals and interactions as the first value. The way you get this value right is by collocating team members to be able to have clear, effective, and direct communication throughout a project.

Collocation is the first crucial element of an agile environment. Bell Laboratories showed a fifty-fold improvement in productivity simply by getting individuals and interactions right through collocation. With this success factor addressed adequately, customer collaboration, working functionality, and responding effectively to change become much more of a reality.

Automated Testing

Development teams cannot develop at the rate technology and market conditions change if they have to manually test their work every time they integrate new pieces of functionality throughout the sprint. The longer teams rely on manual testing, the larger the holes in test coverage become — manual testing simply takes too long and in reality becomes spot-checking. Without automation, scrum teams will struggle to completely deliver value in every sprint.

Enforced definition of done

Ending sprints with non-shippable functionality is an anti-pattern to becoming more agile. Your definition of done should clarify the following:

  • The environment in which the functionality should be integrated
  • The types of testing
  • The types of required documentation

The scrum team should also enforce its definition of done. If scrum teams tell their stakeholders that they are done after a sprint, but an aspect of the definition of done is not met, the work to finish meeting the definition of done must be added to the next sprint, taking capacity away from working on new valuable product backlog items. This scenario is a Ponzi scheme.

Development teams get to done by swarming on user stories — working on one user story together at a time until it is complete before starting the next. Developers hold each other accountable by ensuring that all rules for their definition of done are satisfied before starting a new user story. Product owners review completed work against the scrum team’s definition of done as soon as developers complete it, and the scrum master ensures that developers resolve issues rejected by the product owner before moving on to new user stories.

Swarming to follow a clear definition of done makes sprints successful.

Clear product vision and roadmap

Although the product owner owns the product vision and product roadmap, many people have the responsibility to ensure the clarity of these agile artifacts. Product owners need access to stakeholders and customers at the beginning during project planning as well as throughout the project to ensure that the vision and roadmap continually reflect what the customer and market need. Purpose-driven development delivers business and customer value and mitigates risk effectively.

Without a clear purpose, people wander and lack ownership. When all team members understand the purpose, they come together. Remember the agile principle, “The best architectures, requirements, and designs emerge from self-organizing teams.”

Product owner empowerment

The product owner’s role is to optimize the value produced by the development team. This product owner responsibility requires someone to be knowledgeable about the product and customer, available to the development team throughout each day, and empowered to make priority decisions and give clarification in the moment so that development teams don’t wait or make inappropriate decisions for the product’s direction.

Although all roles on the scrum team are vital and equally important, an unempowered and ineffective product owner usually causes scrum teams to ultimately fail at delivering the value customers need from the team.

Developer versatility

You probably won’t start your first agile project with a development team that has the ideal level of skills required for every requirement on your product backlog. However, the goal should be to achieve skill coverage as soon as possible. Your team will also be challenged to meet its sprint goal if you have single points of failure on any one skill, including testing.

From day one, you need developers on your team with the intellectual curiosity and interest to learn new things, to experiment, to mentor and to receive mentoring, and to work together as a team to get things to done as quickly as possible.

Scrum master clout

As you depart from command and control leadership to empower the people doing the work to make decisions, servant leadership provides the solution. With formal authority, a scrum master would be viewed as a manager — someone to report to. Scrum masters should not be given formal authority but should be empowered by leadership to work with members of the scrum team, stakeholders, and other third parties to clear the way so that the development team can function unhindered.

If scrum masters have organizational clout, which is informal and is a socially earned ability to influence, they can best serve their teams to optimize their working environment. Provide training and mentorship to ensure that your scrum masters develop the soft skills of servant leadership and put off the tendencies of commanding and directing.

Management support for learning

When executive leaders decide to become agile, their mindset has to change. Too often leadership directives without any follow-through for supporting the learning process to implement the changes. It is unrealistic to expect all the benefits of following agile principles after the first sprint.

The bottom line: If support for learning is merely lip service, scrum teams will pick up on it early, will lose motivation to try new things, and will go back to waiting for top-down directives on how to do their job.

Transition support

Good coaching at leadership and team levels increases your chances to succeed. Coaching provides support in the following forms:

  • In-the-moment course correction when discipline starts to slip or mistakes are made
  • Reenforcing training
  • One-on-one mentoring for specific role-based challenges
  • Executive leadership style and mindset adjustments