Anti-Patterns in Agile Product Development — Part II

As we know in companies that are IT-based or like to be, teams will work individually to advance them if there are multiple products. This may pose a new problem for us, although it also has some benefits. The new problem is called “silo”, which means that teams are isolated.
In our view, silos are like a poisonous plant in the organization and represent a bigger problem called lack of communication. This allows development teams not to have a uniform picture of the status of their organization’s products, their progress, and development, as well as mid-level and senior executives, unable to integrate defined strategies with the collective and orderly movement of the organization. Implement.
There are several solutions to this problem, including those I have experienced, such as holding Tech Meetings and later reducing organizational floors, using Open Office, reducing bureaucratic processes, and … I would point out that.
Also, to improve the communication status of the teams, we can move them to face-to-face meetings by reducing textual correspondence and, of course, taking into account the psychological conditions and personality types of the individuals.

When we say that the development team is locked in to develop a product that relies too heavily on a particular technology or vendor. Here we have to differentiate using a particular technology as “one of the available solutions” and “the only available solution”.
If we rely too much on technology and need for further development, if our choice is wrong, it will create more workloads and do repetitive tasks, brainstorming team members and more.
A good solution is to study as much as possible before using a particular technology to make better choices.

Extra engineering:
If the structure (architecture), as well as the design of our product, are too complicated to be defined, for example, if the UI / UX design is full of unnecessary steps or elements and as a result, the user’s mind becomes involved That doesn’t benefit him and ultimately turns our good product into an unusable product with several good features (which of course is still useless).

Gold-plating is a term used when a lot of effort has been put into doing a less valuable job. Our effort to do things beyond the defined need does not help to increase the value of that product. Of course, any effort over-defined does not mean “over-engineering” though it can be.
Why do teams do this? In my experience, overtime occurs when product and development teams try to influence their customers or stakeholders, perhaps because they want to offset their delay or even To demonstrate their capability, it does not help either the team or the project.
In inexperienced development teams, this happens when team members, based on their learning path, want to do things in high-priority and emergency projects that we would generally be forced to do again if the decision was not made. That one of the more experienced developers should spend more time modifying the work done by the less experienced person. This is also recommended for Code Review as well as full coordination with Tech Leaders.

What can we do to prevent Gold-plating? The answer is very simple.
If a feature or product meets the need, stop spending more time on it.
If you want to add even more attractive features to your product, be sure to negotiate with the stakeholders before making any decisions. Be careful that customers or stakeholders do not feel that you are wasting even a small portion of their capital. Avoid overtime on anything that distracts the product from its original purpose.

End of Part II.

PMO expert and project manager who loves reading and writing, nature, animals, and art.