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:
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 - in Agile teams
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. 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, dashboard panels, and discussions to enhance team communication.
Host a standup meeting, 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
Great Agile teams have two common characteristics: they are cross-functional and stable.
A truly cross-functional team has all of the necessary skills to move a user story to completion. For example, if your team’s definition of done 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.
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 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 set until your team knows how quickly they can complete work.
Some teams may relate user story points 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, individual capacity comes into play in the form of hourly task estimates.
5. Poor planning habits
Compared to waterfall 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, daily standup, iteration planning, and release planning meetings. Develop a consistent rhythm for these meetings so team members can develop “muscle memory” to better plan for the upcoming timebox. 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 ownershouldn’t accept completed work until it’s been tested and meets the team’s acceptance criteria. 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 so that they may be verified as soon as code is ready. This removes a potential bottleneck.
7. Ignoring customer feedback
Customers are your most important stakeholder. Let them help your organization craft the vision for features and functionality. Review the most popular requests when grooming the backlog 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. 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. Rally Idea Manager is included in Rally’s Unlimited Edition. To view upgrade options, click here.
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, but instead provides data on what is most important.
When the team has a prioritized list of requests, 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.” 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. Yourdaily standup meetings 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 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 requires most. We can even advise you through a quick phone session. Click here for more information about our on-site coaching services.