Despite trying to achieve simplicity, Agile teams may still run across difficult issues. In this section some of the more common challenges are explored.
It is not uncommon for a team to have incomplete work at the end of an iteration. Unfinished work is an important issue to identify as it signals a potential problem with one or more aspects of the team. When an iteration is planned, the team sets an expectation with the customer. When those expectations are not met, the customer could lose faith in the team’s ability to deliver, which introduces conditions that make success less achievable. Unfinished work should always be analyzed by the team during every iteration retrospective. This is where the team can better understand why the work was not completed and is likewise an opportunity to chart a better course going forward.
There are only a few things that teams can do to manage unfinished work. First, the team can move the work forward into the next iteration. This is normally done with work that has been started and is close to completion. Work that is not done—and was not even started— is usually moved back to the main backlog and is prioritized and rescheduled with the rest of the backlog items.
Incomplete work normally does not count towards team velocity, however, some teams like to have an earned value approach. Most teams only factor in completed work when calculating velocity since one of the reasons work may be left incomplete is because more was scheduled in the iteration than its capacity allowed.
Teams should avoid extending the duration of an iteration to finish incomplete work. To reinforce the hard stop, some teams end iterations mid-week to reduce the temptation of using weekends as iteration buffers. Strict time boxing of iterations is an important tool in helping the team produce more predictable and repeatable results. If work does not fit within an iteration, the team should take the opportunity to assess the reason why so they can eliminate such issues in future iterations.
Bugs are a different type of requirement, one the team does not value. Bugs are waste in the eyes of an Agile team. Any time spent fixing a bug is time taken away from producing customer value, and is one of the reasons Agile teams strive for “zero defect” products. Nevertheless, bugs are an inevitable and must be addressed by all Agile teams. But being unpredictable, they cannot be planned as consistently as requirements from an iterative perspective.
Perhaps the most common way to handle bugs on a project is to allocate a particular amount of capacity in the iteration toward fixing bugs. Obviously, iterations early in the project will not need the same bug-fixing allocation as an iteration immediately preceding a production release, so this allocation should be adjusted by the team over time.
It is very difficult for even the most experienced Agile team to forecast bugs and predetermine how they will affect the time allocation in an iteration. Consequently, bugs are pulled into each iteration’s bug allocation based on its priority and impact. Since critical bugs can manifest daily, the bug backlog must also be managed daily, a process more commonly known as bug triage. Bug resolution is also very difficult to estimate since teams usually have to work to reproduce bugs and research the root cause before any time estimate for a bug can be made.
Every project will contain a degree of uncertainty. Agile teams encounter technical uncertainty (what technology, approach, or design to employ), as well as uncertain requirements. Uncertainty is usually resolved through a combination of experimentation and further research. Agile teams work to address uncertainty with a “spike.” Like almost all things on an Agile project, a spike is a timeboxed amount of time dedicated to addressing an uncertainty. For example, an Agile team may not know the correct approach for a certain technical problem or integration. In this case, the team will schedule a spike time boxed to 3 or 4 hours, where one or more members of the team would perform further research or experimentation required to help resolve the uncertainty. Spikes are scheduled in the iteration as any other requirement and decomposed into tasks accordingly.
Agile teams focus on removing waste and sharing knowledge. The following four meetings are critical to this process and should never be skipped because they are a critical best practice in Agile planning:
Some teams who adopt Agile struggle with process design which of necessity allocates meeting time to maximize communication and collaboration within an iteration. It can be tempting to skip these meetings to instead complete work, but beware. This can have a detrimental impact on the end result and hamper the team’s ability to achieve its project goals.
Many teams choose to stop doing iteration retrospectives, which are meetings held at the end of an iteration where the team gets together and openly share what they believe went well, and specifically, what needs improvement. Retrospective meetings are perhaps the most important part of any Agile process as they are a direct conduit to delivering customer value more effectively. In fact, the retrospective meetings and the process improvement ideas that result in action are exactly what makes the team “agile.” Retrospective meetings are the critical mechanism to help drive continual and ongoing process improvement on a team.
Another potential meeting casualty is the daily standup, known in the Scrum methodology, as the Daily Scrum. The daily standup is typically held at the same time and location every single day and is strictly time-boxed. Each member of the team answers three questions.
Daily standups provide a mechanism to ensure that each team member has an understanding of what work has been done and what work remains. Daily standups are not status meetings and they are not meant to inspire discussion or problem solving – they are a mechanism for the team to share state and to uncover problems inhibiting their ability to achieve their goal.
Another version of the daily standup focuses more on the flow of work rather than individual inhibitors. Instead of the team answering the three questions above, the team looks at each of the items that are in progress and quickly discusses what can be done to usher the items through the workflow.
Again, the daily standup is an extremely important tool for teams to help identify issues during the development process providing the team with the opportunity to remove those issues before they impact delivery. Without these meetings teams can easily miss opportunities to resolve issues as quickly as possible.
Another critical meeting is the iteration review meeting. During these meetings the team meets with the product owner to demonstrate what was accomplished during the iteration. This meeting is simply a demonstration rather than a presentation. During this review meeting, the project is assessed against the iteration goal that was determined during the iteration planning meeting. This meeting is a critical feedback loop with the team. Neglecting to perform this meeting means that valuable feedback is ignored. Some teams feel that they haven’t produced enough during an iteration to warrant an iteration review. However, Agile teams strive to get feedback on everything they produce as quickly and as early as possible to help ensure the appropriate value is being targeted and delivered. These are essential if the team is to make beneficial course corrections that may come out of the review meetings.
Perhaps one of the most important meetings of an Agile team is the iteration planning meeting. During the iteration planning meeting the business sponsor/users (referred to as the Product Owner in Scrum) describes the highest priority features to the entire team. The team has the ability to ask questions so that they can appropriately define the work they need to accomplish. In addition, during this meeting the team will help determine the goal for the iteration, helping to drive decision making and focus during the iteration. The iteration planning meeting is critical for a number of reasons. First, it helps ensure that the entire team has a crystal clear understanding of the user requirements. It facilitates direct interaction with the users instead of relying upon documentation alone for the information transfer. Without this forum for communication and alignment, there is a strong chance the team will misunderstand project requirements. This cascades to poor decomposition of work, poor sizing and estimation, and most importantly, the team risks missing the opportunity to provide optimum value possible to its users.
Learn more about Agile planning? Download our FREE e-book, The Ultimate Agile Planning Handbook!
Here are some of the other topics it covers:
Do you need a tool to manage your agile projects?
Try TeamPulse, for FREE!
Subscribe to be the first to get our expert-written articles and tutorials for developers!
All fields are required