Posts
Until the introduction
of Agile, the standard software development life cycle (SDLC) was a
Waterfall approach, where each stage of the SDLC had to be completed
before the next one could begin. Requirements had to be gathered in
great detail. Design would only begin once the requirements were
completed. Development began once the design was complete, and
testing didn’t start until development was done. This method left
those people with a vested interest in the project (stakeholders)
wondering what was taking so long. There was nothing tangible to show
that any progress had been made.
The basis of working
Agile is the Agile manifesto from the founders of Agile: We
are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:
- Individuals and interactions over Processes and tools
- Working software over Comprehensive documentation
- Customer collaboration over Contract negotiation
- Responding to change over Following a plan
That
is, while there is value in the items on the right, we value the
items on the left more.
Let’s just establish
right now that “Comprehensive documentation” is referring to
planning and tracking documents, not user assistance. The point is
that Agile values a product that people can use over writing about
what that product is going to be or should be.
The introduction of
Agile was a new way of thinking. Instead of detailed requirements,
there were user stories. Each story identifies the person
associated with the requirement, what the requirement is, and what
this functionality will help the person to achieve. For example,
purchasing agents need the ability to enter order information online
so that it can be sent directly to outside vendors. This may be
considered a very large user story, which is referred to as an epic.
This epic can be broken into smaller user stories, which will make
it easier to provide estimates and will enable work for smaller user
stories to be associated with different iterations.
Some examples of
smaller user stories that could be associated with this epic would
be:
- Purchasing agents must have the ability to enter a vendor’s name, address and telephone number and associate it with a vendor number so that the purchasing agent can use the vendor number when placing future orders.
- Purchasing agents must have the ability to select from a list of standard products when placing an order so that consistent terminology is used and inventory can be tracked more effectively.
Using these user
stories, the Agile team assesses and estimates the complexity of the
software design and development associated with them. These estimates
are in the form of points. The larger the number of points
associated with a user story, the more complicated and time-consuming
the design and development is believed to be.
Unlike a waterfall
SDLC, which is a linear approach, Agile is iterative. Before each
iteration, which is called a sprint, the Agile team agrees on
the tasks they are going to complete during the sprint. The total
points estimated for the completed tasks is referred to as the
velocity. The planning for the next sprint should change based
on what happened in previous sprints. For example, if the velocity
for the previous sprint was 50 and the team had estimated they could
complete 75, the team may select less user stories to complete and
aim for 50 the next time. After a few sprints, the team and
management can get a good picture of the velocity and predicted end
date of the project, given the current scope and resources. That’s
one of the benefits of Agile. The information learned during one
iteration can be applied to the next iteration instead of identifying
lessons learned at the end of a project so that they cannot be used
until the next project.
A
lot more can be said about Agile and Agile tools, but we’re hoping
to just establish the background for you to understand the following
series of stories. Debbie Kerr, Ursula McCloy and Fei Min Lorente are
three people who work in Agile environments. This introduction will
be followed by articles where each of them describe how Agile has
been implemented at their work places. Although Agile provides a new paradigm for software development, it favours people over processes, making an Agile experience in one company vastly different from the next.
