We at Geveo are very familiar with the Agile methodology for software development, experiencing it practically every day of our professional lives. However, it is important to be aware of not just the concepts of Agile, but also the core values and reasons behind doing what we do. In order to get that understanding, the best place to start is by taking a glimpse into history. Hence:

A bit of history

Agile development has been around for a very long time. It has its roots in both iterative and incremental software development, which have been practiced since as early as the 1950s. During the 1970s, evolutionary and adaptive development methodologies emerged, which led to a series of lightweight but nevertheless highly popularized software development frameworks being introduced later in the 1990s, such as rapid application development (RAD) (1991), unified process (UP) and dynamic systems development method (DSDM) (1994), scrum (1995), extreme programming (XP) (1996), feature-driven development (1997), etc. All of these lightweight frameworks would later on become a part of the huge umbrella that would be Agile.

But the real origin or ‘inception’ of Agile development happened in 2001, when 17 software developers, which included highly famous personalities such as Kent Beck and Robert Martin, had a meeting in Utah, USA, to discuss the above mentioned lightweight software development frameworks. The outcome of this meeting would be the publication of the Agile Manifesto, which would become a highly popular reference for modern day Agile practitioners all around the world.

What defines Agile?

“We are uncovering better ways of developing software by doing it and helping others do it.” - This is the opening statement that can be found in the Agile Manifesto given by its authors. It elaborates this statement by introducing 4 key concepts which are followed very closely in Agile development, and which are preferred over more traditional concepts which can be found in earlier software development methodologies (e.g. - the waterfall methodology). These 4 concepts are explained below:

Individuals and interactions over processes and tools

This directly ties in with the concept of the Agile development team. The productivity and overall success of the project would depend on the team and the interactions of its members, more than relying on the effectiveness of certain processes and tools/techniques.

Working software over comprehensive documentation

Documentation is good. There is no doubt about that. It helps someone who reads through it to understand the features of a system. However, an even better demonstrative tool would be the actual working software, no matter how small a distinct feature may be.

Customer collaboration over contract negotiation

To play it safe, we would want to sign hard and fast contracts with customers for extended time periods. However, by allowing a certain level of flexibility from both sides, and keeping the negotiation table open at all times, it helps to create more understanding and trust between all parties involved, and ultimately has a very positive impact on the project.

Responding to change over following a plan

We definitely need to have a plan when starting any project in life. But having a strict, immutable plan would result in various undesirable results when faced with unforeseen external factors and impediments. Allowing and responding to change helps to accommodate and compensate for such unavoidable circumstances, and sometimes even shape the path of a project to an even better outcome than previously expected.

The 4 concepts explained above make up the core of the Agile development framework. While the more traditional concepts do indeed have value, the key thing to note is that the more modern ‘Agile’ concepts are valued more.

The Team

The most important aspect of Agile development is the development team. An Agile team should ideally be self-managed. The moment some external party comes into the picture and starts making decisions, is when the actual problems start. Hence Agile discourages the concept of project managers, and instead, the team itself deals directly with the customers/clients.

The ideal number of team members in an Agile team is up for debate. When the team size increases, it takes a toll on the team’s productivity. On the other hand, if the team has only a couple of members, it might be difficult to complete a significant portion of work during a given sprint/iteration. The ideal team size should take into account many factors, including the skill sets of the individual members, project costing, sprint size, etc. More importantly, the team should be able to maintain a constant rhythm and velocity without affecting its performance and the quality of the deliverables.

Scrum vs Kanban

Scrum and Kanban are probably the two most popular ‘Agile’ frameworks that are used for software development. They are both iterative work systems that rely on process flows and aim to reduce waste. However, there are some key differences that separate the two:

1. Roles & Responsibilities - Scrum has many roles for the team (e.g. - Scrum-master). However, in Kanban, although in some instances there may be a project manager, there are usually no predefined roles for the team. Team members are encouraged to take up tasks whenever they are free to work.

2. Delivery Timelines - In Scrum, iterations are fixed time intervals called sprints, in which a portion of work must be completed and ready for review. Alternatively, in Kanban, products and processes are delivered continuously on an as-needed basis (with deadlines decided by the company as required).

3. Modifications/changes - Scrum highly discourages changes during a sprint. But Kanban allows for changes to be made in the middle of a project, allowing for iterations and continuous improvement prior to the completion of a project.

So one might ask which of these two frameworks is best to follow? Well the answer is that it depends on various factors both internal and external to the team (e.g. - project timeline, costing, availability of team members, etc.), and deciding on the best option is a matter of weighing these factors considering the pros and cons of both methods. An even better option would be to combine both these methods into what is known as the “Scrumban” methodology, which incorporates elements from both these popular choices. “Scrumban” has increasingly become popular during recent years.

Why Agile?

Seeing how popular Agile development has become among most software companies in the modern world, one might ask what the reason for this popularity is. The answer is quite simple: with Agile you have much less to worry about, and more room to change. You don’t need to go through the hassle of changing an entire codebase just because you already developed the whole thing and when you show it to the customers they change their mind about something. You progress through a software project in iterations, similar to writing the chapters of a storybook, where you can always make changes to the overall story along the way. Above all else, it values the individuals that take part in it, allowing them to develop themselves while contributing positively to the project, which guarantees overall success for the effort.

For further reference, listed below are the 12 principles that should be followed by agile software as set forth by the authors of the Agile Manifesto:

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

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

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

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

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

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

7. Working software is the primary measure of progress.

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

9. Continuous attention to technical excellence and good design enhances agility.

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

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

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