I have released a course on Pluralsight called Agile Fundamentals that talks about Agile Software Development in detail.
I have already written a number of articles about agile development, agile misconceptions and agile benefits. In this article I want to cover common mistakes that are made by teams new to Agile. They are in no particular order and are all equally as relevant. Not all teams make all of these mistakes, but these are observations I have seen over my career.
Fear is a powerful emotion that is encountered in many forms. For a team new to agile this is fear of the unknown as working agile is completely different to that of a more traditional waterfall process. Fear drives bad decisions and practices that can frustrate a new Agile team. The enemy of fear is trust. You 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 limit of your teams velocity. A single miss should translate into dozens of future successes.
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 old fashioned face-to-face communication.
You can foster collaboration by setting up a dedicated team area, where all team members work within reach of each other. The use of video conferencing and instant messaging software is also a good compromise where it is not possible for teams to be located together. This is especially true where companies are split across geographic locations or off shore outsourcing is used.
You should host a stand-up meeting, every day. This is a brief, face-to-face meeting among all team members that serves to let everyone know what work happened yesterday, what work is planned for today, and what issues may prevent work from happening.
The team should 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.
Poor Team Structure
Great Agile teams should have two common characteristics. They should be cross-functional and stable. A truly cross-functional team has all of the necessary skills to move a user story to completion available to the team all the time.
Stable means team members have time to grow and learn with each other. If you are the teams leader or scrum master, you should 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 will 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.
Estimating the size and scope of new work can be very difficult, especially with a new team. Estimation will become easier with time. If your team is new then you should really let your management know that the team will need two to three inception sprints to learn their initial velocity as this should give the team enough time learn how each other works together.
Until your team has this experience you should not accept projected deadlines for a feature set until your team knows how quickly they can complete work. Some teams may relate user story points with actual work hours. This is a mistake you should try to avoid. It is better to use abstract values such as t-shirt sizes, colours, or points to represent the size of new work. This is important as abstraction helps us track the complexity of the story instead of an individual’s availability. Different team members will always give a different time estimate based on their ability and experience, so this is not a good way of assessing complexity of a user story.
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.
Compared to waterfall and other approaches, some may believe that there is little to no planning with Agile. This is a common misconception. 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.
You should schedule backlog preparation, a daily stand-up, iteration/sprint planning, and release planning meetings. You should develop a consistent rhythm for these meetings so team members get used to a common pattern in their sprints. Build the planning cadence such that the team is looking one to two sprints or iterations ahead.
Agile isn’t about delivering software faster, it’s about delivering quality software faster. Your product owner shouldn’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 automated testing. Test every single build until it passes all the tests. Some people from a tradition waterfall process believe testing is done last, after developers complete coding. With Agile this is not so. With testers sitting on your cross-functional team, testing can begin immediately. After sprint or iteration planning, the requirements of the user story are known so your testers should 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 later on.
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.
Lack of Team Empowerment
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 as they just want to follow along. Challenge the team to grow, and foster an environment of trust to provide empowerment.
Lack of Retrospective and Demo Meetings
Meetings that conclude sprints or iterations and releases are the necessary bookends that complete the inspect-and-adapt cycle.
This happens at all levels. Your daily stand-up 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 for work well done. 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 time-box.
But don’t focus on just the work that was committed to. You should 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?
No Plan to Address Employee 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 performance 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.