Top 10 Agile Fails Infographic
- Your Team Lacks Freedom of Movement
Your team must be empowered with freedom of movement and decision. This means engaging the team members to fully participate in planning. It also requires the team to be polled for their insights on the proposed approach to each sprint. And you as the stakeholder/team leader/scrum master must value the input of the team. Real empowerment means that the team is fully involved in making decisions that impact the final product. Management does not tell the team what to do – rather they provide a road map to what is most important. Giving this responsibility to the team makes them an integral part of the process, and fosters trust among team members. - Disregarding Feedback From Customer
The primary thing to remember is that your customer is your number one stakeholder. Without them, there would be no project to begin with. They should be fully involved in crafting the vision for the function and features of the delivered product. So when combing through the backlog and planning the next sprint, review the most popular customer requests. You may even want to tap a customer service rep as a source of data and trends with the software, since they are on the front lines with the users every day. Ensure that you’re constantly checking this feedback loop so that you’re not constantly including things the customer does not want or need. Or set up a voting site/page for customers to rate the app and give direct feedback that can then be collected and collated. - Lack of Trust
Team members, in order to work well together, must trust one another implicitly. Trust must be instilled at all levels, and it’s management’s responsibility to ensure that this trust permeates the organization by letting the team now that they are trusted to make the right decisions and take the right actions. This in turn fosters an atmosphere where the team is encouraged to learn and grow together, making choices as a group as opposed to taking direction from above. This allows the team to make missteps without overbearing reproach and finger-pointing, which in turn will help you find your true velocity. Giving your team the room to stumble once in a while will result in many solid successes in the future. - Lack of Communication
Danger, Will Robinson! Danger! As George Bernard Shaw once said, “The single biggest problem in communication is the illusion that it has taken place.” If you are not ensuring that your team is communicating regularly and effectively, treacherous waters lay ahead. Even if you have the most meticulously documented processes, failure to communicate face to face (or if not physically face to face, via direct chat/IM, Skype, or even email) will punch a serious hole in your boat. The best way to avoid this is with constant communication about issues and progress. If your team works in the same office, set up a dedicated work area for them so that they are all in earshot of each other. Or, if your team is global, use Skype or other video conferencing methods to create a virtual room for them to work in. - Lack of Proper Planning
Compared to waterfall and other software development approaches, it’s a common enough misconception that with Agile, little to no planning takes place. In fact, it’s quite the opposite – even more planning takes place on a properly executed Agile project. The major difference between Agile and other approaches is that planning is a constant state all during the project, instead of an up-front evolution that’s only done at the beginning of the project. Successful agile teams typically expect to commit at least twenty percent of their available work hours working on planning. Regularly scheduled planning, backlog grooming, iteration planning, and release planning meetings are essential for team success. Teams should work at developing a consistent schedule of these meetings in order for team members to best plan their work, which allows team members to keep looking ahead. - Inadequate Testing
Agile development is not all about the faster delivery of software. It’s really all about delivering GOOD QUALITY software, on time and budget. Testing should be an integral part of the software coding and building process, not just an afterthought that happens after the coding is done. As the user story is know prior to the start of the sprint, and testers as a part of a solid cross-functional team, tests can be written starting from this point onward based on known story values. This can and does remove potential bottlenecks early. And until the software you’re delivering has been thoroughly tested and meets the acceptance team’s criteria, the product owner should not accept delivery. Development of automatic tests can speed delivery times, but do be sure to test each and every build until it passes to the owner’s satisfaction. - Incoherent Team Structure
Truly awesome agile teams have a couple of things in common – they are both stable and cross-functional. A real cross-functional team has what it takes as far as skills to move a user story to a happy and successful conclusion. Good teams incorporate those team members that will lend their best skills to the project. For example, if the goal is to have your code fully documented, be sure that the team includes a competent technical writer. Also make sure that your tester(s) can ensure that only high-quality code gets a passing grade. Stability is a team whose members have had time to grow together as a single working unit. Management needs to challenge themselves to keep teams together through each year, quarter, or month even. Members of stable teams are well versed in learning across their roles, which benefits the entire team by allowing them to challenge each other and provide more accurate estimates as they become familiar with each others’ work skills and habits. This results in mature teams have clearly defined velocities, which provides stable predictability to owners and stakeholders. - Lack Of Good Estimation
Sizing up the scale and scope of new work can pose difficulties, particularly if you have a new team that’s not done much together before. But fret not, as good estimation comes with practice. Do communicate to management and stakeholders that the team will need a few iterations to get up to speed and figure out their velocity. Definitely do not accept projected deadlines for the defined set of features until your team is confident of the time frame it will take them to complete the work. There are some who say that you should match user story points to actual work hours. Do NOT do this! Use points or other abstractions to represent the scope of new work. Abstraction assists in tracking complexity of the story, instead of a single team member’s availability. Use of point estimation (or other abstraction) better reflects the velocity of the team as a whole. As your user stories are analyzed and set into a sprint, then an individual team member’s ability comes into play in the form of task estimates. - Not Warning People That Resistance Is Futile
Let’s face it – changing people’s work habits can be tough, and some folks might resist the switch to Agile methods. Prepare yourself thoroughly for this eventuality. Start with clear communication from management to all team members. The organization as a whole must make it crystal clear that they support the goal of team success over individual performance (or preference). Eliminate individual’s metrics. You stand or fall as a team. This is because you need to overcome a potential cultural issue – that the transparency provided by Agile will result in peer judgement. This is where building trust among team members comes in, as well as building trust between the team and stakeholders/management/product owners. Plan on having at least one person who is well versed in Agile transitions on hand during the early stages of the transition. This person will act as your early-warning system, notifying you of any warnings that things may not be going as smoothly as originally planned. - No Post-Delivery Demo or Retrospective Meetings
What, more meetings??!! Yes, it’s true. The meetings at the end of each iteration and release act as a much-needed bookend to the planning and pre-sprint meetings which complete the inspect-then-adapt cycle. These meetings should take place at every level. Daily stand-up meetings should have a retrospective component. Upon completion of each iteration, a demo meeting should be held with management and stakeholders to demonstrate the work the team has just completed. Other teams can provide insights, as well as rounds of applause.
You can adjust your cookie preferences here.