Understanding agile methodology

The traditional approach to software development no longer lives up to expectations. It is a process that is at once too lengthy and risky, often with the spectacular, much-anticipated product launch never getting off the ground.

Not so, when applying the agile methodology to the development process. When doing "small steps" in "small teams" enables software development teams to deliver value with greater speed and less stress.

As there have been many inaccuracies and misperceptions about agile over the years, the following is here to set record straight.

The background of agile software development

While discussing the agile methodology, one must refer to a meeting which took place in 2001. When seventeen IT experts and practitioners met in Snowbird, Utah, to discuss what were the current methods in software development.

Their purpose was to brainstorm on what could be done to make the software development process more efficient. In their view, the industry was in a deplorable state, with the inefficient Waterfall method being de rigueur for developers at that time.

The participants questioned whether working in a large team with a rigid plan was, in fact, sensible. Instead, they began to consider the advantages of breaking down a project into smaller units and working on them in correspondingly smaller teams.

Despite doubts about whether such a diverse group would succeed in working out a coherent position, an accord was eventually reached. Thus, the agile manifesto was born and from which the agile movement formed, along with the Agile Alliance - a non-profit organization supporting those who want to apply the rules of agile methodology.

It was the beginning of the significant changes that would occur in the areas of project management and software development.

The Agile Manifesto

The agile rules were defined and signed by all participants attending the meeting in Utah, including:

• Kent Beck - co-creator of eXtreme Programming (XP);
• Mike Beedle - co-author of Agile Software Development with Scrum;
• Arie van Bennekum - the owner of Integrated Agile;
• Alistair Cockburn - creator of the Crystal Agile Methodology;
• Ward Cunningham - creator of the CRC design method and inventor of WikiWikiWeb;
• Martin Fowler - author of Analysis Patterns, UML Distilled, Refactoring, and Planning Extreme Programming;
• James Grenning - author of Test-Driven Development;
• Jim Highsmith - creator of Adaptive Software Development (ASD);
• Andrew Hunt - co-author of The Pragmatic Programmer;
• Ron Jeffries - co-creator of eXtreme Programming (XP);
• Jon Kern - supports clients to succeed in delivering business value through software development;
• Brian Marick - software testing consultant;
• Robert C. Martin - known as "Uncle Bob", author of "Clean Agile: Back to Basics";
• Steve Mellor - inventor of Object-Oriented System Analysis (OOSA);
• Ken Schwaber - co-creator of Scrum;
• Jeff Sutherland - co-creator of Scrum;
• Dave Thomas - co-author of The Pragmatic Programmer.

After the discussion, they gathered around the blackboard and wrote the Agile Manifesto:

"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."

It was also during this meeting that the term "Agile" was chosen. Soon, the website www.agilemanifesto.org was created and the agile methodology began its wholesale conversion of software development teams everywhere.

Agile methodology: values and principles

When we consider the values defined in the Agile Manifesto, we see that the focus of the agile methodology is on the customer, leaving the long-term product goal in the background.

Incorporating these values in the software development process is a win-win situation for both sides: it enables team members to meet the true needs and expectations of the customer whilst enjoying a more favorable and thus productive working environment in which to do so.

The Agile Manifesto lists the principles that contribute to creating this positive working environment, and are as follows:

The principles of the Agile Manifesto (source: www.agilemanifesto.org/principles.html):

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity - the art of maximizing the amount of work not done - is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The values and principles of agile methodology were formulated in a simple, comprehensible way. They clearly assert that software development should be aligned with business objectives, programming team members should closely cooperate with business representatives, and all should be ready to promptly pivot according to changing market requirements.

The principles of agile also relate to the culture of work. They promote trust, collaboration and knowledge-exchange between junior and senior team members, and favor face-to-face meetings over lengthier (and potentially meaningless) project-oriented ones.

What is agile methodology?

Such a question will usually appear at the beginning of an article. But to establish a more comprehensive definition of what agile is, I felt it better to first share the history of its development, and then move on to outlining its values and principles.

Getting straight to the point, then, the characteristics that define agile are:

it is an iterative approach to software development and project management;

it supports teams in delivering the work results in a faster, more efficient way;

agile teams are smaller, doing smaller segments of work;

with agile, both plans and results are evaluated on a regular basis, giving the opportunity to adjust according to changing requirements;

continuous collaboration both with team members and project stakeholders;

agile allows for product quality improvement at each release;

agile focuses on client satisfaction;

agile sustains its focus on long-term goals.

Sprint and user stories

These terms are an integral part of the agile definition.

Sprints are particular project cycles. These are the 'small parts' I mentioned earlier that team members work on. Sprints are short periods (usually two weeks) during which work is focused on user stories. A user story is a set of product features comparable to KPIs in a given project cycle.

The main benefit of dividing a project into sprints is that it renders the entire software development process more manageable. More specifically, sprints make it easier to identify potential risk factors that may arise in the process, and therefore easier to make the adjustments required for rectifying those factors.

Agile development team

Agile challenges the assumption that great things are achieved only by great teams. Agile believes the opposite to be true.

An agile team is much smaller in size than what one finds in the traditional approach. It mostly consists of developers and testers, and will usually include a product owner and project manager (a.ka. 'scrum master').

A product owner represents the interests of the project stakeholders whereas the scrum master facilitates communication, organizes sprint sessions and measures progress.

List of rights in agile

Anyone dealing in software development knows how hard it can be to find a compromise between a technical team and business representatives. Such difficulty can lead to internal conflict which may jeopardize the project's outcome.

Aware of this challenge, the authors of the Agile Manifesto then composed a special list of rights for both parties. They noticed how these rights are not divergent and, in fact, fit together most conveniently, illustrating once again agile's tremendous capacity for streamlining project management.

Rights of business representatives

"Business" in agile is represented not only by customers but also the product owner, the project leader, and any others not involved in the technical side of the software development.

The business list of rights prepared by the authors of the Agile Manifesto includes:

right of access to the project plan and to information on its progress;

right to gain the best possible value in each iteration;

right to modify the plan without exposure to significant cost;

right to cancel the project and claim it as-is to an extent equal to the investment made.

Rights of the agile software development team members

The list of developers' rights includes:

access to the project specifications, time schedule, and list of priorities;

right to deliver exceptional quality;

right to request support from the other team members;

right to estimate and make necessary updates;

right to take responsibility for the work.

An analysis of these rights shows that each project, even in agile, needs a plan. But the question is how detailed this plan should be. The authors of the list of rights claim that a detailed plan can only be prepared once the project is done.

Thus, their call for greater flexibility. On one hand, this flexibility must secure business interests (monitoring the level of investment made), and on the other, guarantee freedom of action for developers.

Why choose agile?

Agile software development is now one of the most often applied methodologies by software houses and other organizations involved in the software development process.

You can see why:

adaptability to change - working in iteration enables developers to adjust quickly to evolving customer needs;

transparent collaboration - agile ensures all parties are up to date with the project's current level of progress;

reduction of technical debt - unlike the traditional approach, defects and feature changes are identified during the process and put in the product backlog which provides a more immediate opportunity to rectify them;

risk minimalization - agile's iterative processes are more conducive to minimizing technical debt, rendering less project risk as a whole;

high quality - working in small project cycles lets developers focus more intensively on refining a selected set of features;

schedule planning - dividing the project into sprints makes it easier to plan delivery dates;

customer satisfaction - user stories in agile represent customer requirements and act as a driving force in the software development process, bringing real value to the customer;

project control - working in agile makes it easier for each side to monitor the progress and facilities the decision-making process.

Agile methodologies

The agile approach has spawned numerous methodologies which are now applied in areas beyond software development and project management.

Here are some more popular examples:

Scrum

Scrum belongs to the most applied agile methodologies. It is divided into sprints - cycles of development. The product goal is defined with each sprint bringing the team closer to it.

The main advantage of Scrum is full transparency through which all involved can readily follow the project's progress. Success depends on good sprint planning and the right allocation of tasks and responsibilities.

Kanban

Originally developed in Japan, Kanban is an example of agile methodology that is now widely used in business-related processes (e.g. HR, marketing).

Kanban uses a board format divided into headed columns, e.g. "To do", "Doing", "Done", etc. Each column displays the workflow within a project. According to the project progress, the information presented in the columns changes. Once a new task is introduced, a new card is created.

The main advantage of Kanban is that when employed in a given project, it allows one to see "the bigger picture".

Extreme Programming XP

Extreme Programming XP was developed by Kent Beck - one of the authors of the Agile Manifesto. In this method, the software is tested from day one with the collected feedback used to implement improvements.

The objective is to discover the simplest solution required at that point in time whilst downplaying attention given to long-term product goals.

Extreme Programming XP values communication, simplicity, feedback, courage, and respect. Here, the advantage is found in the simplicity of the code that allows for improvements to be made as and when they are needed.

Lean development

This methodology has origins in Lean Manufacturing created by Toyota. Lean Development seeks to eliminate any activity that doesn't bring value to the customer, saving time and money by doing so.

Lean Development focuses on quality and quick delivery, placing particular value on the collaboration and knowledge-creation through which future benefits are to be gained.

Crystal

Crystal is perhaps the most flexible of all methodologies. It grants team members full freedom to set their own processes, thus obliging them to communicate and collaborate among themselves and to optimize the use of their individual talents.

Crystal places value on people, interactions and skills, making it ideally suited to autonomous, experienced software development teams.

These methodologies are just a few examples of agile's great versatility; there are many more which its values and principles govern.

Dynamic Systems Development Method (DSDM), Feature Driven Development (FDD), Scaled Agile Framework (SAFe), to name a few.

Yet their links to agile are at times controversial.

Robert C. Martin admits that he wrote his book "Clean Agile: Back to Basics" because the simple message of agile had become blurred. As Agile had come to be associated with methods such as Kanban, Lean, and SAFe, they had for him increasingly less to do with agile's original concept.

For learning more about what original agile is, Martin's book is indispensable.

The main conclusions we can draw by considering the various agile methodologies that have developed are that a) the iterative approach works, and that b) there is no return to such cumbersome, traditional methods as Waterfall.

Another conclusion would be that there is no one-size-fits-all methodology out there. Development teams and project managers must instead analyze the advantages and disadvantages of each approach in order to choose the one that is most suitable for the project at hand.

Or they can create their own.

This is what we do at Startup House. We create our own methodologies that best serve our customers and developers, and we base these on our experience in the many successful projects we've worked on. The Product Discovery Process is just one example.

We cannot imagine software development without agile, its values and its principles. We believe in the iterative approach and in prioritizing customer needs. We believe in the power of cooperation and continuous improvement.

We've long recognized that agile teams have the advantage over traditional ones. For supporting our clients, this is why we outsource experienced agile product teams.

So, whenever your project needs a boost and/or delivering bang-on time, contact us and we'll ensure you get the right people in place to make it happen.