Some takeaways from last week’s BA conference at ThoughtWorks-Pune, although not related to thorough req. analysis, but in condensed version of few amazing talks blended with my personal inputs.
A good process approach gives good results on short, medium and long terms. Measuring the trends for monitored parameters helps to check if there exists a decline in them. It is important to see that after 6 months, 1 year, or after a specific period your project does not fall into technical debt issues (“spaghetti code”). Serious technical debt problems is a sign of non-Agile process. That result from a primary Agile principle. ”Continuous attention to technical excellence and good design enhances agility.”
Some common practices and principles one must keep a check on:
- Your documents should be effective: rather short, but must contain the essential information.
- As derivate issue: your products should have good architectures and good design, resulted from continuous adaptation.
- The developers should be able to sustain Agile specific activities, such as refactoring and TDD. Also an Agile developer should have design and architecture knowledge on vertical dimension and also system analysis abilities – on horizontal dimension.
- You should have already a good history on responding to changing requirements and often deliveries of value encapsulating software.
I agree that many of the soft metrics like associate satisfaction, customer collaboration and improved team interaction are the core, in case of sizable teams the following metrics are ones that can be very helpful :
- Speed to Market/Cycle Time (reduce)
- Client reported defect trends (reduce)
- Unplanned attrition (reduce to show associate satisfaction)
- Customer partnership agreements (eliminate projects without a customer)
This metrics need to evolve and usually outlive their usefulness after 6-9 months as teams seek to meet the metric rather than adopt an agile mind set and continuously improve.
However, to check whether your system is Agile and is working properly try answering these simple questions honestly :
- Are we continuously improving our process?
- Are we delivering working, tested, valuable software every month or less?
- Are we delivering what the business needs most?
If you can answer yes to those three questions then definitely, “Agile is working for you.”
People who read “Success factors to know if Agile is really working for your project.” also read :
