Several bad practices can make a team less effective. First, you need to be well-equipped to recognize them. The anti-patterns presented in this article might even be part of your team’s current practices. In this second article, of a series of 2, we will explore the anti-patterns that make organizing the development team’s work less efficient and jeopardize the achievement of the project.
1. Pre-Assign Tasks
One might think that assigning work at the beginning of the sprint and specializing our employees on specific tasks will make them more efficient. However, it becomes counterproductive when a subject matter expert leaves the team, or when a developer doesn’t dare take on the highest-priority item because it is not assigned to them.
It is best to leave assigning work to the team and to do it as it comes along. There is nothing to prevent appointing an expert referent. In this way, freedom, exchange of information, pair work, and free circulation of items in the system are encouraged, constraints are reduced, and efficiency is increased.
Assigning one item per individual at the beginning of an iteration can still be a great idea, however, as long as this is done as a team and with everyone’s agreement. This ensures that developers are focused on single items from day one of the cycle.
2. Do Not Limit the Work in Progress
The best way to make a system efficient is to force all the players to focus on a limited number of items at a time. When several items are being worked on at once and there is no focus on item delivery, the team gets scattered and less efficient.
Limiting “WIPs” is a well-established practice in Kanban, a pull method.
The following order is always prioritized in a pull system:
- The item(s) closest to delivery (e.g., in testing)
- Blocked item(s)
- Longest open item(s)
3. Have Unrealistic Overloaded Forecasts
Sometimes you may fall behind in a sprint and finish certain items at the beginning of the next sprint. It is important to count all the points in the next sprint, rather than trying to re-estimate the items on the remaining work, so as not to impact the planning and distort the velocity. Velocity is the average number of relative points completed in the last few iterations.
Additionally, we should not load the team with more work than they can handle. We must also take into account the number of items not identified during planning. It is better to underload an iteration than the other way around, in order to build trust and respect our quality level. Nothing prevents us from adding an item when we see that we will finish the iteration ahead of time.
Finally, a parallel can be drawn with the number of work-in-progress (WIP) items. By respecting the team’s pace, we allow team members to focus without spreading themselves too thin on several items at once. By maintaining a constant item delivery rate, they can focus only on the work in progress. An agile board with an endless number of items hinders concentration.
4. Doing Retrospectives Where Everything Is Perfect
A retrospective is a time to exchange ideas and come up with action plans for improvement. A retrospective where everything discussed is perfect and no action plan emerges is a meeting that has not achieved its primary objective.
No team or process is perfect. There is always room for improvement. A fairly effective way to spark new ideas is to vary the retrospective formats used and allow for the more difficult conversations.
For example, the discomfort of raising an issue can come from a climate of repression, from a facilitator who is not listening, from a team leader who defends an inefficient process, etc. The culture of failure and continuous improvement is something that can be worked on, and that emerges first through listening and the will to improve.
However, it is equally important to use the retrospective to highlight positives. Reinforcing the good things that individuals do and their daily effective actions encourages the team to perform even better next time.
5. Run a Stabilization Iteration
One of the core values of agility is transparency. It is important to always expose the work that remains to be done, and to close items only when they are completed to quality standards.
When you try to go too fast and cut corners, you end up getting stuck. That’s when it becomes tempting to run a stabilization iteration. This concept doesn’t exist in agile, which instead advocates sticking to the basics and delivering quality.
It is common for a newly-delivered feature to generate ideas for changes. One highly effective practice is to leave improvement items on the iteration board. This lets the product owner note the improvement ideas and determine if the changes can be made during the iteration without impacting the goal, or if they should wait until the beginning of the next iteration or even pushed to a “post mvp” category in the product backlog. For Scrum teams relying on velocity, it is equally vital to point out this improvement item before starting it.
6. Make Emergency Additions During the Sprint
An agile team that has chosen the Scrum framework should not be ruffled at every turn by emergency additions to the iteration. These are counterproductive, distorting the team’s velocity and its ability to meet iteration forecasts.
If you frequently find yourself in this situation, perhaps the Kanban framework would be more appropriate to your practices. In Kanban, we rely mainly on the number of items completed (throughput), cycle time, and probabilities to make delivery forecasts. The notion of fixed iteration and relative cost is not part of Kanban practices.
In summary
To conclude, the anti-patterns mentioned here are commonplace issues in organizing an agile team. Constantly questioning yourself and always striving for perfection belongs to the culture of failure. If any of these situations apply to your project, there is no point in beating yourself up. Mistakes are human.
But now that you are aware of them, decide on the highest-priority action for your team to take and test it. Continuous improvement is also an iterative process requiring frequent inspection and transparency.
