We look at the effectiveness criteria for agile methodology in the software development context, applying the same five dimensions mentioned in an old blog by Tom Graves, “Within any given context, I’ve also found it useful to compare against a relatively simple yardstick of effectiveness”. The five criteria or yardstick for effectiveness can provide a cross check when considering the use of agile methods in software development. Some of these effectiveness criteria can also be used for other methodologies within their specific contexts.
• Efficiency is dictated by how well you use your resources, and hence how you control the wastage.
Efficiency gains are achieved through small sprints and tasks of small granularity, that is, small execution duration. This ensures the principles of “fail quick”, and of course the inclusive nature of the scrum teams means we maintain transparency and adjust to changes very quickly.
Wastage does not accumulate as it would in a waterfall method, and the daily stand-up meetings would bring problems to the product stakeholders attention very quickly.
Short duration sprints also provide fast feedback to the product stakeholders, hence once again controlling wastage.
Sprint retrospectives are an invitation for the team to separate the wastage from the productive part of the sprint. This would provide information for corrective measures in the next sprint.
It is precisely for these benefits of agile execution that make it well suited for product development, particularly in the early stages when the requirements are in volatile state.
• Reliability is a combination of quality and timely delivery of the product.
Intrinsic quality is an integral part of the product design and architecture, which is reflected in the code.
Intrinsic quality is achieved through continuous dialogue amongst the team and product stakeholders through out the sprints; the design goes through the cycle of re-factoring and re-coding all through the sprints.
Extrinsic quality is that which the user of the product perceives.
As the product begins to take shape the user feedback is used through out the sprint cycles to achieve the extrinsic quality for the product.
Timely delivery is dependent on the scope and the team composition, and is thus to be negotiated at the beginning.
Team composition can and will affect the timely delivery; domain knowledge has to be transitioned and technical translation has to be achieved.
Avoiding scope creep is the most important aspect of timely delivery.
• Elegance is clarity, simplicity, and product features with which humans interact.
This should not be mistaken for some subjective judgement or criteria to be ignored. Both, clarity and simplicity are part of the design and coding structures that can lead serious maintenance and management issues that can be very costly.
Agile methods with its “fail, but fail quick” principal allow ample opportunities for achieving the principles of clarity and simplicity, through continuous refactoring and integration.
Human interaction with your product is the UI, which dictates the user experience with the product.
If you loose the eyeballs at the first instance, you may loose them forever.
Every product has a purpose; appropriateness asks whether this purpose has been met.
Is the product satisfying its purpose to the end user, is she able to do all that the product promises?
Has the product owners vision been realised? This notion of appropriateness is very much the product owners remit, the team will have executed and delivered the user stories as per his objectives.
Appropriateness also crosses into product release plans and product visibility to the user community.
The integrations of all components must be clean; one should not be able to see the stitching lines.
These are part of the design consideration during execution and are achieved by various means.
Avoid tight coupling.
Design and accommodate clearly defined API.
Publish web services and expose functionality at the correct granular level for consumption by both internal and external community.
Always ensure that modules can be switched without disrupting the product users and manage versioning outside the web service or API signature.
This blog first appeared in my Linkedin profile.