The following is a collection of the 10 most common mistakes that a new agile team can make in IT.
- Fear
- Poor communication
- Poor team structure
- Poor estimation & Picking incomplete backlog items
- Poor planning
- Poor testing
- Ignoring customer/user feedback
- Lack of team empowerment
- Lack of retrospective and demo meetings
- No plan to address employee resistance
1. Fear
Fear drives bad decisions and practices that can frustrate. 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. Do not finger-point in case of failure. Learn from it and a single miss will translate into dozens of future successes.
2. Poor communication
Even with the most meticulous documentation, the best way to discover issues and blockers is through face-to-face communication. A brief, face-to-face meeting among all team members serves to let everyone know what work happened, what work is planned and what issues may prevent work from happening. Choose quality over quantity with regard to the information being shared. 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. Stable means team members have time to grow with each other. A truly cross-functional team has all of the necessary skills to move a user story to completion. 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.
4. Poor estimation & Picking incomplete backlog items
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 the team knows how quickly they can complete work. In a first step complexity of the new work is relevant and not individual’s availability. Start with using abstract values to represent the size of new work (i.e. colors or t-shirt sizes). Once user stories are sized and committed to in an iteration, individual capacity comes into play in form of hourly task estimates. Only accept completely specified stories for a sprint. Dependencies and impediments should always be cleared before to ensure a reliable estimation.
5. Poor planning
Compared to waterfall and other approaches, some may believe that there is little to no planning with Agile. That is not at all true. The difference with Agile is that this critical action is ongoing instead of a one-time event that gets checked off at the beginning. Think of it as a continual process that has to occur at varying levels of complexity and granularity. Expect and commit to spending 20% of available work hours for planning in order to be successful.
6. Poor testing
Agile isn’t about delivering software faster; it’s about delivering quality software faster. You may believe testing is done last, after developers complete coding but 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/user feedback
Customers/Users are your most important stakeholder. Let them help your organization craft the vision for features and functionality. Review the most popular requests when refining the backlog.
8. Lack of team empowerment
There are three steps to empower the team: 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.
9. Lack of retrospective and demo meetings
All meetings should include a retrospective aspect. 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? What adjustments can be made? At the end of an iteration, host a demo meeting with the organization to show the work the team has completed. Other teams will be able to provide you with valuable insights.
10. No plan to address employee resistance
Change is tough, and some people may resist the switch to Agile. Be prepared for this scenario by full management support. 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.
Read the full article by Broadcom here.