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 can be part of your team’s current workflows. In this practical article, of a series of 2, we will explore the anti-patterns that make collaboration with the Product Owner difficult and endanger the project.
1. To Be Resistant To Change
The best way to kill the creativity and efficiency of a team is to force it to respect a strict pre-defined framework. The Product Owner must state the need and be open to the solution proposals that the team brings. The best example is rewriting an application. It can be very tempting to copy the same functionality again and be non-negotiable on the proposed solution, but this is counter-productive.
A good Agile team will take advantage of technical opportunities to reduce development time and simplify a feature. They just need to be given the opportunity to do so by remaining open-minded.
2. Do Not Allow for Mistakes
One of the basic principles of Agility is to recognize that software development always starts with a hypothesis that can only be validated when the functionality is available in production. It is also a well-known concept that mistakes are a source of innovation.
Based on these precepts, an Agile team, as well as the stakeholders involved with the team, should welcome mistakes as learning opportunities. The idea is to capitalize on quick failures by swiftly validating our hypotheses with end users and constantly readjusting.
3. Delegate Everything
The role of a Product Owner is to communicate the vision to the team, as well as to define the user needs that the application must meet. Their daily contribution is essential in order to avoid the development team prioritizing or making decisions in their place.
It is quite realistic to ask the development team to accompany the Product Owner in some of their tasks (for example, adding items to the product backlog), but the responsibility lies with the Product Owner when it is time to validate and decide
4. Not Stick to the Basics
When you start developing a need or a feature, creativity is activated and new needs emerge. It can be tempting to increase the initial scope of the project, or the current project phase. However, this obviously impacts the forecasted iteration completion, budget, or delivery date of the project.
One can also think of several solutions to meet the need expressed by the Product Owner. The idea is to stick to the most efficient and best-aligned solution, and to focus on functional aspects rather than seeking perfection.
In IT development, you should always keep in mind an MVP (Minimum Viable Product) vision, and stick to the essentials even if it means adding items to the product backlog representing these new needs, and clearly identifying them as being outside the initial scope (e.g., in a post-MVP category in the product backlog).
5. Have a Solution That Does Not Meet the Need
Software development is a complex field. It is normal to make mistakes. But the solution must at least meet the stated need, even the first version is not perfect or optimal.
Several techniques can help ensure that the solution chosen by the team meets the user’s needs. For example, you can produce mock-ups and have them validated by the Product Owner.
Personally, one of my favorite technique is to make frequent, short demonstrations for the Product Owner during development, directly at the developer’s workstation. The product then becomes a reality, and it’s an appropriate time to gather feedback since it’s not too late in the development process.
It is less costly and frustrating to change ideas along the way than after the functionality is deployed to production and the iteration is complete.
6. Consider the Design Error as a Bug
It is important, as much for the morale of the team, the perception of the client, the statistics, to distinguish between an anomaly and a design error. It must be admitted that even the best teams sometimes make poor choices of solution or misinterpret the need; this is called a design error.
On the other hand, an anomaly is rather a functionality with a processing error that makes the functionality unusable. For example, a missing validation allowing an erroneous transaction that ends in an error.
In Summary
Finally, the anti-patterns mentioned above are commonplace in a service company where the Product Owner is also the customer. It is part of the culture of failure to constantly question ourselves and to always strive for perfection. If several of these situations apply to your project, there’s no point in beating yourself up. Mistakes are human. Now that you are aware of this, choose the action that seems to be the highest priority for the team, and test it. Continuous improvement is also an iterative process, requiring frequent inspection and transparency.
However, there are many other anti-patterns that are a risk for the realization of the project, and it is in the next serie of this article that will be presented those that impact in the organization of the work in team.
