The following is a collection of the 10 most common mistakes that a new Agile team can make. You’ll find suggested remedies that come directly from our support, user learning, and coaching teams, who have years of experience guiding teams through Agile transitions.

1. Top 10 Mistakes Made by New Agile Teams
Published on Rally Help (http://prod.help.rallydev.com/help)
Top 10 Mistakes Made by New Agile Teams
The following is a collection of the 10 most common mistakes that a new Agile team can make. You’ll
find suggested remedies that come directly from our support, user learning, and coaching teams,
who have years of experience guiding teams through Agile transitions. If you’re new to Agile, Rally,
or just need a refresher, click an item in the list below to jump directly to a topic:
1. Fear
2. Poor communication
3. Poor team structure
4. Poor estimation
5. Poor planning
6. Poor testing
7. Ignoring customer feedback
8. Lack of team empowerment
9. Lack of retrospective and demo meetings
10. No plan to address employee resistance
1. Fear
Fear is a powerful emotion that is encountered in many forms. It drives bad decisions and practices
that can frustrate your new Agile team. Fear’s mortal enemy is trust. Counter fear by instilling trust
at all levels. Start by letting the team know that the organization trusts them to make the right
commitments and decisions. The team should be trusted to learn, grow, and make choices as a
group, instead of taking directives from management.
A common example of fear stifling team growth is the issue of commitment. Teams often under
commit or pad their estimates, due to fear of being responsible or blamed for failure. Initially, allow
your team to give themselves permission to miss in their estimation. Foster an environment of trust,
such that the team can explore the causes of a miss without finger-pointing. This will help you find
the true upper limit of your velocity [1]. A single miss will translate into dozens of future successes.
2. Poor communication
If your team members don’t talk to each other regularly each day, trouble lies ahead. Even with the
most meticulous documentation, the best way to discover issues and blockers is through face-to-face
communication. Foster collaboration by setting up a dedicated team area, where all team members
work within reach of each other. Use video conference and instant messenger software to create a
virtual room for global teams. In Rally, you can use notifications [2], dashboard panels [3], and
discussions [4] to enhance team communication.
Host a standup meeting [5], every day. A brief, face-to-face meeting among all team members
serves to let everyone know what work happened yesterday, what work is planned for today, and
what issues may prevent work from happening. Choose quality over quantity with regard to the
information being shared. By physically standing up in the meeting, team members will get
uncomfortable if the discussion becomes unnecessarily long. Don’t give in to the temptation to
problem solve in a standup; let your scrum master discuss the details of blocking issues with
individuals later.
3. Poor team structure
Page 1 of 4

2. Top 10 Mistakes Made by New Agile Teams
Published on Rally Help (http://prod.help.rallydev.com/help)
Great Agile teams have two common characteristics: they are cross-functional [6] and stable.
A truly cross-functional team has all of the necessary skills to move a user story [7] to completion.
For example, if your team's definition of done [8] includes fully documented code, include a tech
writer in your team structure. Additionally, include a tester to ensure the code is of high quality. The
team needs to see a user story with a wide lens, so that they can correctly estimate the scope [9].
Stable means team members have time to grow with each other. Challenge yourself to keep teams
together through each month, quarter, or even year. Consider keeping the team together as one
project [10] ends and another begins. Team members benefit by learning across their roles, and can
challenge each other to provide accurate estimates as they become familiar with everyone’s skills.
These mature teams have well-defined velocities that provide better predictability to product owners
and stakeholders.
4. Poor estimation habits
Estimating the size and scope of new work can be difficult, especially with a new team. Hang in
there; estimation will become easier with time. Let management know that the team will need two to
three inception sprints to learn their initial velocity. Don’t accept projected deadlines for the feature
[11] set until your team knows how quickly they can complete work.
Some teams may relate user story points [12] with actual work hours. Avoid this mistake! Use
abstract values such as t-shirt sizes, colors, or points to represent the size of new work. This is
important. Abstraction helps us track the complexity of the story instead of an individual's
availability. Point estimation reflects the abilities of the team as a whole. Once user stories are sized
and committed to in an iteration [13], individual capacity [14] comes into play in the form of hourly
task [15] estimates.
5. Poor planning habits
Compared to waterfall [16] and other approaches, some may believe that there is little to no
planning with Agile. In fact, there is even more planning. The difference with Agile is that this critical
action is ongoing instead of a one-time event that gets checked off at the beginning of the
development cycle. Think of it as a continual process that occurs at varying levels of complexity and
granularity. Expect and commit to spending 20% of available work hours planning in order to be
successful.
Schedule backlog grooming [17], daily standup [18], iteration planning, and release [19] planning
meetings. Develop a consistent rhythm for these meetings so team members can develop “muscle
memory” to better plan for the upcoming timebox [20]. Build the planning cadence such that the
team is looking one to two iterations ahead.
6. Poor testing
Agile isn’t about delivering software faster; it’s about delivering quality software faster. Your product
owner [21] shouldn’t accept completed work until it’s been tested and meets the team’s acceptance
criteria [22]. One way to combat poor testing habits is to place an emphasis on developing automatic
testing. Test every single build until it passes.
You may believe testing is done last, after developers complete coding. Not so! With testers sitting
on your cross-functional team, testing can begin immediately. After iteration planning, the
requirements of the user story are known. Start building tests against the value the stories provide
[23] so that they may be verified as soon as code is ready. This removes a potential bottleneck.
Page 2 of 4

3. Top 10 Mistakes Made by New Agile Teams
Published on Rally Help (http://prod.help.rallydev.com/help)
7. Ignoring customer feedback
Customers are your most important stakeholder [24]. Let them help your organization craft the
vision for features and functionality. Review the most popular requests when grooming the backlog
[25] and planning. Consider including a customer support agent as a member of the team to provide
data and trends. Check this feedback loop every iteration so you don’t continue building something
that isn’t meeting customer needs.
Rally provides an easy way to manage customer feedback with Rally Idea Manager [26]. You can set
up a customized voting site where new feature requests can be collected, organized, and voted on
by external and internal stakeholders. You can even communicate back to your customers by
posting feedback and status updates on each request.
8. The team is not empowered
There are three steps to ensuring your team is empowered in the Agile process. First, you must
engage the team by inviting members to participate in planning. Next, ask the team for their insights
on the proposed set of work. Finally, the value of these insights must be respected. True
empowerment means the team makes the decisions that impact commitment. The business does
not tell the team what to do [27], but instead provides data on what is most important.
When the team has a prioritized list of requests [28], instead of a set of directives, they become part
of the process. They may return feedback to the organization such as, “We can complete story A, but
this will mean story B must be dropped,” or, “If you must have story C done this iteration, quality is
at risk [29].” Some teams will shy away from this responsibility; they just want to follow along.
Challenge the team to grow, and foster an environment of trust to provide empowerment.
9. No retrospective or demo meetings
You thought we were done recommending more meetings? Not yet. Meetings that conclude
iterations and releases are the necessary bookends that complete the inspect-and-adapt cycle. This
happens at all levels. Your daily standup meetings [5] should include a retrospective aspect. At the
end of an iteration, host a demo meeting with the organization to show the work your team has
completed. Other teams will be able to provide you with valuable insight (plus a nice pat on the
back).
Host iteration and release retrospective meetings with your team. In these meetings, the team can
discuss what went well, what problems they encountered, and what action items are needed to
prevent issues in the next timebox. But don’t focus on just the work that was committed to;
retrospect on the Agile process as a whole. What aspects of planning are working? Is the team
encountering any of the mistakes in this list? What adjustments can be made?
10. No plan for resistance
Change is tough, and some people may resist the switch to Agile. Be prepared for this scenario by
starting with communication from management. The organization must make it very clear that it
supports the notion of team successes over individual performance. Eliminate personal metrics; you
win and lose as a group. This will combat a potential cultural problem — that the transparency Agile
provides will result [30] in judgement by peers. Again, this goes back to providing an environment of
trust.
Demand that someone experienced with Agile transitions is on-site with the team during the early
stages. He or she will be your canary in the coal mine, picking up on subtle warnings that the
process may be in jeopardy. Rally Coaches are available to assist your organization with this need.
We can customize a plan that is tailored to your needs, and emphasize the Agile concepts your team
Page 3 of 4

4. Top 10 Mistakes Made by New Agile Teams
Published on Rally Help (http://prod.help.rallydev.com/help)
requires most. We can even advise you through a quick phone session [31]. Click here [32] for more
information about our on-site coaching services.
Source URL: http://prod.help.rallydev.com/help/top-10-mistakes-teams
Links:
[1] http://prod.help.rallydev.com/help/glossary#velocity
[2] http://prod.help.rallydev.com/help/set-your-notifications
[3] http://prod.help.rallydev.com/help/customize-your-dashboard
[4] http://prod.help.rallydev.com/help/collaborate-team-members#discussions
[5] http://prod.help.rallydev.com/help/daily-standup
[6] http://prod.help.rallydev.com/help/glossary#cross-functional
[7] http://prod.help.rallydev.com/help/glossary#user_story
[8] http://prod.help.rallydev.com/help/glossary#definition_of_done
[9] http://prod.help.rallydev.com/help/glossary#scope
[10] http://prod.help.rallydev.com/help/glossary#project
[11] http://prod.help.rallydev.com/help/glossary#feature
[12] http://prod.help.rallydev.com/help/glossary#points
[13] http://prod.help.rallydev.com/help/glossary#iteration
[14] http://prod.help.rallydev.com/help/glossary#capacity
[15] http://prod.help.rallydev.com/help/glossary#task
[16] http://prod.help.rallydev.com/help/glossary#waterfall
[17] http://prod.help.rallydev.com/help/glossary#backlog_grooming
[18] http://prod.help.rallydev.com/help/glossary#daily_standup
[19] http://prod.help.rallydev.com/help/glossary#release
[20] http://prod.help.rallydev.com/help/glossary#timebox
[21] http://prod.help.rallydev.com/help/glossary#product_owner
[22] http://prod.help.rallydev.com/help/glossary#acceptance_criteria
[23] http://prod.help.rallydev.com/help/writing-great-user-story
[24] http://prod.help.rallydev.com/help/glossary#stakeholder
[25] http://prod.help.rallydev.com/help/glossary#backlog
[26] http://prod.help.rallydev.com/help/rally-idea-manager-overview
[27] http://prod.help.rallydev.com/help/glossary#to_do
[28] http://prod.help.rallydev.com/help/prioritizing-backlog
[29] http://prod.help.rallydev.com/help/glossary#risk
[30] http://prod.help.rallydev.com/help/glossary#result
[31] http://www.regonline.com/builder/site/Default.aspx?EventID=984036
[32] http://www.rallydev.com/request-rally-services-information
Page 4 of 4
Powered by TCPDF (www.tcpdf.org)