Anti-Patterns in Agile Product Development — Part III
Most people may think that we can help the project grow by more and sometimes overworking, but is that true?
Documentation:
One of the fundamental reasons to focus on Working Software rather than generating comprehensive documentation is that the documentation is time-consuming, which is valuable time for the development team. We call this the View-graph Engineering and, like Gold Plating, the result of not focusing on practical and time-consuming tasks for less valuable work.
Instead of freely focusing on coding and resolving technical problems, our developer friend spends time documenting, reporting, and presenting. This is more common in organizations with pyramid or class structure issues. Because under these circumstances, a developer becomes overwhelmed with processes to explain and demonstrate the product to work on the product.
The usual solution to this counter-pattern is to reformulate the software product development team structure. It is also measurable and justified because it takes as much time as developing an MVP when developers spend documenting, presenting, and reporting.
Remember that the original MVP product’s value is worth it when your developers spend it.
Fire Drill:
When we are approaching our product lunch, if we do not do many of the essential planning and analysis steps correctly, the workload on developers will increase, and they will spend more time on development. The product and they will advance it. Part of this is related to prioritizing tasks.
If the amount of work done by the development team in each Sprint is less than required during the product preparation period, most of the pressure will shift to the last days.
Here are the Scrum Master and PO who should be able to manage the scheduled tasks well. More product owners in Business where stakeholders and Scrum Master clearly define needs as facilitators alongside teams.
Unfortunately, if we face these conditions, we need to know that reaching the deadlines we have committed to delivering the product will sacrifice the quality of the work of software developers and, in turn, create “technical debt” for us.
Superheroes:
The anti-pattern of the fire drill generally leads to another anti-pattern, relying on product development on superheroes — highly skilled people in software product development who suddenly arrive and do unfinished work and are finally appreciated.
Keep in mind that the people in the development team need to have a spirit and a sense of trust. As facilitators and managers, you have to create that feeling, creating the kind of situation where “we always need superheroes,” What they do during the product development process will not be considered. Still, all the fate will include a superhero who will “save the product.”
As product managers or owners alongside the development team, our job is to build trust with development team members and help them improve their development speed and remove obstacles in their path.
Remember that if the people who make the product (the development team) don’t “believe” it or lose their spirits, it is virtually doomed to failure even if delivered to the customer.
End of Part Three
Feel free to comment below. Please hit that clap button to help others find it if you enjoyed this article.
