As on today, if you
search for Agile, or Agile related information over the internet, you will be
greeted with search result pages displaying all sorts of information pertaining
to Agile – right from Agile training and coaching to Agile gurus offering their
“esteemed” insights and experience relating to various Agile frameworks. More
recently, it has become very common to see scaled versions of Agile appearing
in the searches – SAFe, Scaled Agile, ScrumButs, AgileLive, Jira Agile, Quickscrum - the
list is not big but worthy of being considered – and all of them proclaiming
their efficiency in being “effective”, and above all “Agile”. It would be
wonderful to know more about these versions, but a basic question always keeps
on popping up – Is the client really following Agile in a true sense? Are you a
hard-core Agile supporter or a ScrumBut? Maybe, it would be more worthwhile to
ascertain whether you, or your client, are in fact following Agile in the first
place, let alone other scaled versions of Agile.
Here are a couple of
pointers to help you know if you are “Agile” or not.
Is development carried out through iterations?
Needless to say, the
main purpose of implementing an Agile framework is to benefit through product
increments in a consistent manner. Nobody can claim they’re following Agile if
their project development process does not support regular product increments
at the end of sprints. In addition to iterative development, Agile
implementation should also support dynamic collaboration – sharing of feedback
and information amongst the product owner, scrum master, scrum team, and the
stakeholders. Iterative development and collaborative nature are Agile trademarks,
and it is most essential for organisations to support these features if they
claim to be Agile.
Can changes be incorporated during the product
development cycle?
One of the main
reasons why people opt for Agile is its ability to incorporate changes in the
product definition even while the product development process is currently
underway. It is a unique selling feature of all Agile frameworks, and is
synonymous with developing a project while still maintaining its business value
– at all times. Irrespective of the changes taking place in the market –
whether big or small – the project development process should have, and retain,
its capability to dynamically change the functionality developed, and offered,
by the product features as and when necessary. Agile projects should support
this feature.
Can development be carried out in “bits and pieces”
rather than “as a whole”?
Perhaps what makes
Agile frameworks so unique are their iterative structures supporting daily
sprints. In scrum or XP, the product development is carried out in the form of
daily sprints. Special events are held to plan the sprint (the sprint planningmeeting) and ensure that proper and acceptable product increments are availed
at the end of sprints (sprint reviews and retrospectives). The development
carried out in “bits and pieces” should result into shippable functionality
(successfully developed user stories), and should also be acceptable to the
project owners (stakeholders). “Small sized” consistent development, which is
bug free, should have the capability to later integrate in a correct functional
manner so as to form the “complete” product – an euphemism which conveys
“Development in pieces to be later integrated to form the actual product.”
As on today,
organisations are not just limited to using traditional versions of Agile
frameworks. There are subtle variants, which can be scaled up or down as per
the need, and which can be “tailored” to meet the unique project development
needs of business concerns. It may not be possible to state or define the exact
set of parameters which a project management methodology, or framework, should
satisfy to be considered Agile, since Agile is all about “inspecting” and
“adapting”. The main essence of Agile lies in its ability to change itself, its
working, and mould itself to suit the specific development related needs, as
the case may be.
However, it may be
certainly possible to “check” for some “trademark” features to ascertain
whether Agile exists in a project or not.
Use Free scrum tool from www.quickscrum.com
Source:-
| http://EzineArticles.com/8576627 |
No comments:
Post a Comment