5 checks for effectiveness of Agile

We look at the effectiveness criteria for agile methodology in the software development context, applying the same five figure1dimensions 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.

About KM Mukku

Kick-start, build and manage teams in product development (particularly in the financial domain), and enjoy all in adaptive case management, business process design and business process improvement. Currently holding the position of CTO at coMakeIT.
This entry was posted in agile. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s