10 Ten Key Factors For Agile Project Success
10 Ten Key Factors For Agile Project Success
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.
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.
Ending sprints with non-shippable functionality is an anti-pattern to becoming more agile. Your
definition of done should clarify the following:
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.
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.”
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.
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:
Reenforcing training