welcome to why use agile in this session we will discuss why the agile
methodology was selected as the basis for delivering projects without systems
in this session will answer the question why agile will discuss the to agile
manifestos that provide guiding principles for this approach the
manifesto for agile software development and the manifesto for software
craftsmanship given all of that motivation and guidance will also look
at how to work in an agile way today the user is king and they can have very high
expectations over time people have been getting closer to technology to the
point where the normal citizen has become a daily consumer of technology
and a very savvy one at that end users feel that they know best and they demand
to be heard so from a solution delivery perspective it's increasingly often the
case that these key users are the ones deciding the go/no-go agile was designed
to work closely with the end-users in order to get early feedback from them
during the development process and then iteratively enhance a solution based on
what is most valuable to them the agile approach provides a stark contrast to
the waterfall methods of the past Waterfall methods were based on
countless meetings and miles of documentation which made it difficult to
cope with the demands and the pace of the world today the competitive
landscape of business today can be very aggressive and it's time to market and
require quicker responses to change in the end users perception of value so
ensuring that the apps we're building and delivering are actually driven by
the end users perspective of value is now key for the survival of any company
so what are the fundamental goals of solution delivery and why should we
choose an agile approach to address them well there's an interesting quote from
Darwin about natural selection which sort of applies it's not the strongest
of species that survives nor the most intelligent but the one most responsive
to change so from a Darwinistic perspective angel' principles seem to be
on the right path as they address the three fundamental goals of today's
solution delivery fast time to market ability to respond to change and being
driven by the business value now back in the beginning of 2001 a small group of
people got together to try to come up with a set of core values that are
common to successful delivery teams and their projects they documented these
values and wrote the manifesto for agile software development
it starts with we are uncovering better ways of developing software by doing it
and helping others do it the group wanted people to know that this was
based on real experience and that they wanted to help others and it had quite
an impact as Kent Beck Martin Fowler and many other thought leaders of the time
were part of this group the manifesto and its principles are truly important
in our practice as they provide a clear framework to follow and they convey the
collaboration and constructive mindset that's so important here are some of the
comparisons they created to try to describe these principles individuals
and interactions over processes and tools now this is not to say that
processes and tools aren't important but we should focus on the importance of the
team on the collaboration between team members and on working together toward a
single and shared purpose the discussions discovery and resulting team
learning are just as important as the solution that's being built
working software over comprehensive documentation while important
documentation is not a goal per se it's just a means to an end
unfortunately tons of documentation for a solution does not imply high quality
and sometimes the need for that much documentation actually implies the
opposite customer collaboration over contract negotiation in this case no
one's saying that we don't need contracts and that all collaboration can
be informal but this comparison describes the mindset that's necessary
to be able to respond to change ensuring that the final solution fits the
business need and because change is always going to occur responding the
change should be more important than following a plan now iteration by
iteration while the solutions being built the key users are experiencing and
providing feedback about it this allows the users needs to be better understood
than they are at the start of the project and this often results in
changes to the goal of the project because the extra details or different
perceptions of what represents the most value to the business user has changed
no doubt this change should not only be expected but actually embraced as it
will ensure better value and higher adoption in 2009 the manifesto for
software craftsmanship tried to reinforce certain aspects of the
original principles while highlighting the key trait software professionals
aspire to which are not only working software but also well crafted software
and that means focusing on the design and technical quality not simply
responding to change but actually doing it with a focus on steadily adding value
not only individuals and interactions but also a community of professionals
and not only customer collaboration but also productive partnerships
highlighting how the relationship Queen these parties should be viewed and
nurtured now all this sounds great so to be fair let's also focus on a few
of the pitfalls that can occur when people abuse agile which will refer to
as avoiding fragile so well-crafted software over comprehensive
documentation but it needs to be centered around clearly written user
stories everything that should be implemented should be clearly stated in
the user story and it's related acceptance criteria being responsive to
change and always focusing on adding value is good but we're also following a
high-level plan and the iteration scope is sacred and must remain intact in fact
iteration scope should be viewed as an agreement where the delivery team
commits to deliver the agreed-upon scope and the customer agrees and commits that
the scope definition is sufficient to mitigate the risk of change requests
that could interrupt the iteration we also need to follow a well-structured
process it's not by chance that we will get all the flexibility that agile can
get us we can achieve it but we need to follow a structure and plan and a fully
productive partnership with the customer but paying close attention to very
clearly managing expectations and assuring alignment when change does come
and assuring those changes can be accommodated directly in the existing
time box
so let's do a quick comparison of agile and waterfall they both follow the same
kind of delivery stages requirements design implementation testing and then
deployment however they have very different approaches to these stages
plenty of software great software and lousy software as well has been built
over the years so while waterfall is planned driven
each stage generally finishes before the next one can begin according to some
plan that is mostly defined at the very start of the project agile is value
driven going through several iterations sometimes called sprints and each sprint
comprised of the stages we just described but with a list of
deliverables planned for each sprint the deliverables are prioritized by business
value as determined by the customer also users can provide feedback about the
solution at the end of each sprint thus keeping the solution closely aligned
with their needs it's also too important it's also important to emphasize that
agile iterations are meant not to be like this but like this and that's to
say that agile aims to deliver value to user at the end of each iteration
meaning that not only mere parts or disconnected components of the solution
are delivered but rather a piece of functioning software that's useful
testable and has some value so what is working in an agile way well let's start
off by defining a time box or a project budget usually this is defined from an
initial sizing which should include all the initial requirements assumptions
constraints and objectives basically all the knowledge gathered at the start of
the project this initial sizing should also take into consideration that most
gathered knowledge will be at a high level and that more details will be
incorporated during the project this resulting time box should be kept frozen
until the end of the project allowing for more accurate cost estimation and
plan for time to market the next step is to assign features to specific
iterations to do this we should categorize and prioritize all of the
requested features the top priority features often called must-haves should
be the ones that are the most important provide the most business value or are a
core piece of functionality after the must-haves we determine the things we
should have and then finally the could haves which are also referred to as
nice-to-haves while prioritizing we should also take into account any
dependencies between features this may potentially raise the priority of less
important features now once the prioritization is complete we can sort
all the features and assign them to specific iterations within the time box
iteration lengths are fixed and not flexible in any way meaning that
iterations end regardless of whether or not the assigned work is complete now at
the end of the prioritization the first iterations should be covering the top
priority features the last iterations will include the least important
features so even at this stage in the project we can perform a simple health
check or sanity check a basic rule of thumb tells us that must-haves should
correspond to roughly 60% of our effort should haves another 20% and could have
another 20% this way there's a low risk of having to move important features out
of the current release when must-haves are higher than 60% of all the features
it indicates the need to discuss and review the reason for these priorities
because if everything is important then nothing is really important now if
you're listening closely you may have noticed that I mentioned that features
can be moved out of the current release let's look at why that might happen once
iterative development starts at the end of each iteration a demo is performed
for the users to allow them to provide feedback this feedback must be handled
to maintain alignment with the biz this needs handling the feedback may
require minor changes to the existing features or larger changes like adding
new features minor changes can usually be addressed in the next iteration while
new features need to undergo the same prioritization process that we just
discussed if the new features have higher value than the existing ones the
existing features should be moved to a future release otherwise the new
features have less value than the existing ones and they should be moved
to a future release usually the features left out will be nice to have and
therefore the entry of any new features provide more value which is completely
appropriate this reprioritization process also allows new features to be
included while keeping the time box frozen and last but not least having key
users provide their feedback during the demo at the end of each iteration is
great and it becomes even more valuable after an iteration or two when the users
realized that their feedback is being included in the solution this increases
their motivation and strengthens the collaboration of the team which helps
the solution stay more closely aligned with the business need now on a slightly
different note here is a now famous quote from Reed Hoffman the founder of
LinkedIn if you are not completely embarrassed by the first version of your
product you've launched too late now this quote can be considered a bit
controversial but it attempts to highlight the importance of launching a
product and new features and then iterating rather than taking additional
time to try to make it perfect before launch and this is a good contrast
between the way that waterfall used to do things compared to the new agile
approach
so we've covered a lot of ground in this session from my agile is a good approach
for developing software today to the principles from the manifestos that help
define the agile movement to what it actually means to work in an agile way
so that's it for this session on why use agile thanks for watching and have a
great day