Your SlideShare is downloading. ×
  • Like
Top 10 Mistakes Made By New Agile Teams
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Top 10 Mistakes Made By New Agile Teams

  • 410 views
Published

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, …

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.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
410
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
10
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 TeamsThe following is a collection of the 10 most common mistakes that a new Agile team can make. You’llfind 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 resistance1. FearFear is a powerful emotion that is encountered in many forms. It drives bad decisions and practicesthat can frustrate your new Agile team. Fear’s mortal enemy is trust. Counter fear by instilling trustat all levels. Start by letting the team know that the organization trusts them to make the rightcommitments and decisions. The team should be trusted to learn, grow, and make choices as agroup, instead of taking directives from management.A common example of fear stifling team growth is the issue of commitment. Teams often undercommit or pad their estimates, due to fear of being responsible or blamed for failure. Initially, allowyour 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 findthe true upper limit of your velocity [1]. A single miss will translate into dozens of future successes.2. Poor communicationIf your team members don’t talk to each other regularly each day, trouble lies ahead. Even with themost meticulous documentation, the best way to discover issues and blockers is through face-to-facecommunication. Foster collaboration by setting up a dedicated team area, where all team memberswork within reach of each other. Use video conference and instant messenger software to create avirtual room for global teams. In Rally, you can use notifications [2], dashboard panels [3], anddiscussions [4] to enhance team communication.Host a standup meeting [5], every day. A brief, face-to-face meeting among all team membersserves to let everyone know what work happened yesterday, what work is planned for today, andwhat issues may prevent work from happening. Choose quality over quantity with regard to theinformation being shared. By physically standing up in the meeting, team members will getuncomfortable if the discussion becomes unnecessarily long. Don’t give in to the temptation toproblem solve in a standup; let your scrum master discuss the details of blocking issues withindividuals 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 teams definition of done [8] includes fully documented code, include a techwriter in your team structure. Additionally, include a tester to ensure the code is of high quality. Theteam 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 teamstogether through each month, quarter, or even year. Consider keeping the team together as oneproject [10] ends and another begins. Team members benefit by learning across their roles, and canchallenge 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 ownersand stakeholders.4. Poor estimation habitsEstimating the size and scope of new work can be difficult, especially with a new team. Hang inthere; estimation will become easier with time. Let management know that the team will need two tothree 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! Useabstract values such as t-shirt sizes, colors, or points to represent the size of new work. This isimportant. Abstraction helps us track the complexity of the story instead of an individualsavailability. Point estimation reflects the abilities of the team as a whole. Once user stories are sizedand committed to in an iteration [13], individual capacity [14] comes into play in the form of hourlytask [15] estimates.5. Poor planning habitsCompared to waterfall [16] and other approaches, some may believe that there is little to noplanning with Agile. In fact, there is even more planning. The difference with Agile is that this criticalaction is ongoing instead of a one-time event that gets checked off at the beginning of thedevelopment cycle. Think of it as a continual process that occurs at varying levels of complexity andgranularity. Expect and commit to spending 20% of available work hours planning in order to besuccessful.Schedule backlog grooming [17], daily standup [18], iteration planning, and release [19] planningmeetings. Develop a consistent rhythm for these meetings so team members can develop “musclememory” to better plan for the upcoming timebox [20]. Build the planning cadence such that theteam is looking one to two iterations ahead.6. Poor testingAgile isn’t about delivering software faster; it’s about delivering quality software faster. Your productowner [21] shouldn’t accept completed work until it’s been tested and meets the team’s acceptancecriteria [22]. One way to combat poor testing habits is to place an emphasis on developing automatictesting. Test every single build until it passes.You may believe testing is done last, after developers complete coding. Not so! With testers sittingon your cross-functional team, testing can begin immediately. After iteration planning, therequirements 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 feedbackCustomers are your most important stakeholder [24]. Let them help your organization craft thevision 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 providedata and trends. Check this feedback loop every iteration so you don’t continue building somethingthat isn’t meeting customer needs.Rally provides an easy way to manage customer feedback with Rally Idea Manager [26]. You can setup a customized voting site where new feature requests can be collected, organized, and voted onby external and internal stakeholders. You can even communicate back to your customers byposting feedback and status updates on each request.8. The team is not empoweredThere are three steps to ensuring your team is empowered in the Agile process. First, you mustengage the team by inviting members to participate in planning. Next, ask the team for their insightson the proposed set of work. Finally, the value of these insights must be respected. Trueempowerment means the team makes the decisions that impact commitment. The business doesnot 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 partof the process. They may return feedback to the organization such as, “We can complete story A, butthis will mean story B must be dropped,” or, “If you must have story C done this iteration, quality isat 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 meetingsYou thought we were done recommending more meetings? Not yet. Meetings that concludeiterations and releases are the necessary bookends that complete the inspect-and-adapt cycle. Thishappens at all levels. Your daily standup meetings [5] should include a retrospective aspect. At theend of an iteration, host a demo meeting with the organization to show the work your team hascompleted. Other teams will be able to provide you with valuable insight (plus a nice pat on theback).Host iteration and release retrospective meetings with your team. In these meetings, the team candiscuss what went well, what problems they encountered, and what action items are needed toprevent 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 teamencountering any of the mistakes in this list? What adjustments can be made?10. No plan for resistanceChange is tough, and some people may resist the switch to Agile. Be prepared for this scenario bystarting with communication from management. The organization must make it very clear that itsupports the notion of team successes over individual performance. Eliminate personal metrics; youwin and lose as a group. This will combat a potential cultural problem — that the transparency Agileprovides will result [30] in judgement by peers. Again, this goes back to providing an environment oftrust.Demand that someone experienced with Agile transitions is on-site with the team during the earlystages. He or she will be your canary in the coal mine, picking up on subtle warnings that theprocess 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 4Powered by TCPDF (www.tcpdf.org)