The AGILE approach

Agile software development is a group of software development practices based on
iterative and incremental development; in this framework, requirements and solutions
evolve through collaboration between self-organizing, cross-functional teams. In this
approach there is an emphasis on software quality, adaptation to change, and involvement
of team members, that is resumed in the twelve principles of the AGILE manifesto:

  1. Customer satisfaction by rapid delivery of useful software.
  2. Welcome changing requirements, even late in development.
  3. Working software is delivered frequently (weeks rather than months).
  4. Working software is the principal measure of progress.
  5. Sustainable development, able to maintain a constant pace.
  6. Close, daily co-operation between business people and developers.
  7. Face-to-face conversation is the best form of communication (co-location).
  8. Projects are built around motivated individuals, who should be trusted.
  9. Continuous attention to technical excellence and good design.
  10. Simplicity- The art of maximizing the amount of work not done – is essential.
  11. Self-organizing teams.
  12. Regular adaptation to changing circumstances.

Maybe not all these points can be applied to any project, but certainly some of these
guidelines will favour its success. These are some AGILE practices that I would like to implement in my current work context (some of them I already did!):

  • Systematic delivery of results through use of a versioning system (e.g.: Git);
  • Active involvement of the team through use of a Wiki page
  • Involvement of the team in the development of requirements and testing of the
  • software;
  • Incremental development by providing the software to the end users at the end of each module, rather than at the end of the project;
  •  Knowledge transfer, through automated generation of documentation (e.g. Doxygen); automated documentation is more ”AGILE” than technical manuals, since we can generate it more often with a minimum effort;
  •  Flexible, ”bottom-up”, decisions regarding adopting of software frameworks and tools;
  •  Frequent refactoring with emphasis on non-functional characteristics of the software: expressiveness of the code, reusability, etc; the use of good design patterns will ease the debugging and the development of new features, and will increase the ownership the software by a larger number of people;
  •  Prioritize testing; testing is a very important stage of the software development cycle and it should not be left only to developers and stakeholders, who will focus on certain aspects of the application; to guarantee a good quality and usable product in a shorter lapse of time, testing should be also performed by specialized and independent professionals.

An emphasis on software quality (rather than pushing towards adding new functionality)
will generate less bugs and ease the task of debugging. It will also make the software more
adaptable to change, enabling to implement new features. Software that did not focus
on non-functional characteristics can quickly become obsolete, defeating the purpose for
which it was built in the first place.
According to the principles of incremental development, it is easier to start with a
simple piece of software and keep adding functionality to it, than to start with a very
complex plan that will never be achieved. With an approach of having ”often releases”
we always have the guarantee of having functioning pieces of software, even if they are
not complete.
The AGILE manifest calls for a small team, that works closely together; this is because larger teams need more logistic to be coordinated, which makes them less AGILE.
According to this article, the typical roles in an AGILE team are:

  • Team Lead: this role encompasses the soft skills of project management but not the technical ones; e.g.: facilitating the team, obtaining resources for it, and protecting it from problems (also refered as ”Scrum master”).
  • Team member: this role includes modeling, programming, testing, and release activities (also refered as developer or programmer).
  • Product owner: this role, also refered as ”on-site customer” or ”active stakeholder”, represents the stakeholders. This is the responsible for the prioritized work item list (called a ”product backlog”), for making decisions in a timely manner, and for providing information in a timely manner.
  • Stakeholder: a stakeholder is anyone who is a direct user, indirect user, manager of users, senior manager, operations staff member, the ”gold owner” who funds the project, support (help desk) staff member, auditors, developers working on other systems that integrate or interact with the one under development, or maintenance professionals potentially affected by the development and/or deployment of a software project.

Although it is important to have in mind this structure in order to distribute responsibilities, roles are not fixed positions; members can accumulate more than one role and
roles can include more than one members (or none). Also, roles may change over time.
In order to build a high-quality working system on an incremental basis, we also need
a ”supporting cast”:

  • Technical experts: sometimes the team may need the help of technical experts to help them overcome a difficult problem, and to transfer their skills to one or more developers on the team (e.g.: database expert, GIS expert).
  • Domain experts: As the product owner represents a wide range of stakeholders (not just end users), it isn’t reasonable to expect them to be experts at every single nuance of the domain. Thus the product owner may sometimes bring in domain experts to work with the team (e.g.: African small-scale fisheries expert, Small-scale fisheries statistical systems expert).
  • Independent tester: effective AGILE teams often have an independent tester working in parallel, that validates their work throughout the lifecycle.

Final Thoughts

I ask myself – and the followers of this blog – the following questions:

  • What is the “minimum” size of an AGILE team? Could we have a team of one-member or that does not make any sense?
  • Is it more AGILE to have one developer, one database expert and an analyst (for instance), or to have three people sharing the three roles?
  • Should developers also accumulate the role of testers?
  • Can a practice such as Extreme Programming be implemented over distance? Does the whole AGILE approach make sense without physical proximity?

Look forward for some opinions on this!

Leave a Reply

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

You are commenting using your 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 )

Google+ photo

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

Connecting to %s