Many factors can be a catalyst for bad software: chosen tools, team communication, the personal stake developers have in its success, testing methodology.
Very often, dev-teams fail to deliver in time, fail to deliver an end-value — the value for their end-user.
Risks cause this problem: either by people (management) or economics (lack of resources, changes in the market). Here are more detailed examples:
🏁 Missing the deadline
For example, due to unforeseen problems. Every project is a challenge for the whole team. The day of delivery comes faster and faster. It is highly likely that you will solve unexpected problems till the deadline, once you are already too far along with the project.
📉 Misunderstood business
We know that the central role of Product/Project managers is to collaborate and make sure that no business requirements are left out. Unfortunately, it often happens that the software is put into the staging or worse into production, but it still doesn’t solve the user problem. Moreover, it’s a waste of time, money, and maybe a loss of an opportunity for business.
🏗 More changes required
The “successful” product release is not the “Happy End” for dev teams. It’s the beginning. The business has more and more requirements to improve and grow the product—solve more user problems. Developers must deliver more value—features.
💸 High cost of change
And along with new features, the sub-optimal system/architecture’s defect rate must be changed; in the worst case, this kind of system must be replaced.
🚲 Rich features that fail
Just because cool features are fun to implement, it doesn’t mean they are relevant to business goals—satisfy users and earn more money.
Most developers want to get paid well and have fun at the same time. In programming vocabulary, “Fun” means tackling exciting and challenging problems. For product development, it means “imaginary problems.” In this case, the real product problems that have to be solved—get lost.
Considering the risks above, the developers have to be agile and find a way to develop software in new conditions.
And the best choice would be Extreme Programming (XP). This methodology addresses risks at all levels of the software development process. It’s incredibly productive, helps deliver high-quality software, and provides a lot of fun to execute.
Missing the deadline
👉 XP calls for short release cycles and implementing the highest priority features defined by the product manager first.
Traditionally, after the release of requested features, there are 1-4 weeks iterations with users to get fine-grained feedback from them about the product progress.
This approach allows dev teams to solve the right user problems faster, even during an iteration before new planning.
Misunderstood business
👉 XP asks users to be a part of the product development team by implication. That helps the development team to continuously refine user needs during product development. The learnings from the user interactions with the product will be reflected in the new product release.
More changes required
👉 XP shortens the number of changes in the release. Because of the methodology’s purpose, there are fewer changes during the development of a single release. It means the user can give early feedback for the uncompleted feature. And that allows the dev team to make fewer changes to this feature in the future.
High cost of change
👉 XP always keeps the system/architecture in prime condition. It’s based on a reliable and comprehensive suite of tests re-running after every tiny change. Tests ensure a system quality baseline. And that reduces the cost of any such change.
Rich features that fail
👉 XP asks programmers to accept responsibility for estimating and completing their work. They focus on the highest priority tasks along with the strong communication in the cross-functional agile development team and prefer the simplest solution for those. In turn, that ensures that only the most valuable features are implemented, and there aren’t many “rich features” that nobody needs.
Paul Graham@paulg
Idea derived from a suggestion by @lisperati: what if there was an upper bound on the amount of code in a product, so that if you wanted to add code, you'd have to delete some too?18:36 PM - 11 Feb 2020
54
786
💬 Conclusion
There are many useful and efficient Agile software development methodologies, and Extreme Programming (XP) is one of them.
The main advantage of Extreme Programming is that this methodology allows software development companies to eliminate many risks: save money and time required for product realization.
It shares all Agile principles along with the intense end-users involvement in the software development process, strong communication on the team, and iterative cycles of development.
Don’t miss upcoming blog posts about Extreme Programming that will be covering planning, testing, development, design architecture, and deployment, follow me on Twitter to not miss a new post.
Thank you for reading!
Cheers, Ilona
Photo by Web Donut from Pexels
Top comments (1)
I am likewise maintaining a business and these days I am taking assistance from the top business scholars of the Landlord Business Plan site. Truly from here, I have got such a great amount of data about the business that how we should maintain a business effectively.