In an ideal world, the stakeholders would know what features they want in their product from day 1. Developers (Scrum Master) would know the cost of each feature in terms of time and effort and therefore be able to estimate cost correctly. A simple low risk formula for success. Unfortunately, the reality is very different for most, this is because the stakeholder rarely knows what the final product should be, resulting in constant change (refactoring), increasing project cost and risk.
But this is why we have Agile in place – to deal with the changing requirements?
Agile software development, is built to manage changing requirements, this is widely accepted but even with Agile development in place, every change to requirements adds additional cost to the project. Herein lies dangerous thinking that just because your project is an Agile Development project that everything that can be done, is being done to mitigate the risk of changing requirements. More specifically, the real danger here comes from complacency, the acceptance that changing requirements are inevitable and that if it changes it doesn’t matter because your team is using Agile and therefore you dont need to know what the features are upfront. If this is your thinking, your team might be practicing Agile but not very effectively.
As to how Agile your development team is, is a question of how successful your team is at implementing agile, doing everything that makes Agile development successful. Since Agile development is most valued for enabling adaptation to changing, logic dictates that the most effective of Agile of teams have the lowest number of changing requirements. No doubt there will be those thinking – right now, – that it is the stakeholders responsibility to know what features they want not the developers! Unfortunately, this statement is just another sign of a less Agile Developer / team. Is it not the responsibility of the development team to know what they are developing?
Perhaps then, when outsourcing Agile software development projects the first question a CIO should ask of a potential provider is what is your average number of changes to requirements per project.
So quite simply put: – one of the single most dramatic ways to improve your Agile Development and cut costs for the stakeholder is to communicate effectively on the topic of product features. So why do so few achieve excellence in this regard?
Both sides are to blame here, because the developer does have a say in how things are done (will come back to this) although the root cause is clearly the responsibility of the stakeholder and lies firmly at the door of the CIO. What we are talking about here is the collection of product demands from across the enterprise. With Agile development, Stakeholders now expect to be consulted at every level and have full access to software development processes and progress (complete transparency) though tools such as codeBeamer ALM ; however rarely does the developer have access to the mechanism used for the collection of demand. The Transparency does not go both ways, changing this is key to reducing the number of changing requirements and therefore key to reducing costs for the client.
How can the Developer ensure the Feature Demands are collected effectively and transparently?
Enter Demand Management: How Simple Collaborative Feature Prioritization Manages Risk and cuts costs.
It is in the interests of all parties that the product (software) demands (feature suggestions) are collected transparently and collaboratively, after all one idea for a feature may spark other ideas. Since this is a ongoing conversation, a single meeting on the topic is just not sufficient. The decision making process that determines that one idea is better or more important than another determines the feature requirements and the minimal viable product for release. This should not be left to chance but decided through collaborative prioritization, feedback from across all departments with a vested interest in the project to be developed. At the end of the process there should be no question as to what the feature priorities should be, the decision is made (at least in part) by the future users. Based on this information Stakeholders can assign feature value and prioritize. Factors determining prioritization (aside from enterprise feature demand) include.
- Unknown factors
- Specific Feature ROI
- Old cost vs New Cost
- Reduced Risk
Why codeBeamer ALM is necessary?
codeBeamer ALM integrates Demand Management into the Application Lifecycle and within its feature set. It is completely integrated, no additional add-ons required and no hidden costs. It provides piece of mind for both software developer and client that feature demands are collected effectively thereby improving the quality of the entire project. It reduces the need to change requirements later on and thereby reduces risk and cost.