What Is Agile?

Agile software development is an approach to developing and delivering working software into production in incremental, iterative work cadences, known as sprints.

Being ‘agile’ is more of a philosophy than a set of rules. It is a mindset to continually improve; to embrace new ideas and implement the best ones, testing in the wild all the while to find what really works. Collaboration, feedback and iteration are key.

In this post, I will briefly touch on the Agile Manifesto where it all started, before looking at some basic concepts (feedback) and alternatives (waterfall), before the main bulk of the article, which is the flavors of Agile, including XP, Kanban and, primarily, Scrum.

The Agile Manifesto

 

The Agile Manifesto, a set of principles developed by software industry leaders back in 2001, is where much of the agile movement started:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

While there is value in the items on the right, 
we value the items on the left more.

And some of the principles behind the manifesto are below (you can find the full list here).

Satisfy the customer
Welcome changing requirements
Deliver working software frequently
Business and developers must work together daily
Simplicity (maximizing the work not done) is essential
Self-organizing teams

 

Agile Basics: Feedback

Although there are many important aspects to agile, one of the key ones for me is feedback. Obtaining feedback early and often, and to use that feedback to continually improve, is key. This facet of agile has been coined Feedback Driven Development(1). The feedback can come from all facets of a project, including users & customers (via demos), the development team (via pair programming and code reviews), and the code itself (via tests). The team can also assess itself and provides feedback using retrospectives.

 

Agile alternatives: Waterfall

It is also useful to talk about what Agile is not. Agile is not “waterfall”.

Waterfall is an approach to software development where each phase (requirements, design, implementation etc) needs to be completed before the next (e.g., define all requirements, before doing a ‘big upfront’ design etc). Due to its inflexible nature, waterfall is more applicable when requirements are fixed with no ambiguity, such as manufacturing plants, than to software development.

 

Agile Flavors

What are the flavors of Agile?

There are many implementations of Agile, but the main ones are

• Extreme programming (XP)
• Kanban
• Scrum

I will focus mainly on Scrum in this article, but…

 

XP

Extreme programming, or XP, is an agile approach that focuses mainly on software quality through activities such as pair programming, Test Driven Development and continuous integration. The name comes from not just doing things, but doing them in an extreme way, or turning the dial up to 10 (or 11). For example, don’t just do code reviews, do constant code reviews where the other developer stands beside you as you type (which ultimately becomes pair programming).

 

Kanban

Kanban is a scheduling system. It was originally developed at Toyota to control the supply chain and inventory-control, and improve manufacturing efficiency.

 

In the software world, kanban as an agile approach can be suited to environments that are more dynamic and constantly changing.

Rather than having fixed sprints, as with Scrum, there is a continuous flow where team members pull the highest priority tasks from a queue when they are free. Since the only thing that really matters is the top of the queue, the backlog can be reorganized at any time with little negative impact. I have seen Kanban used successfully in support type environments.

 

Scrum

Scrum is arguably the most popular approach to agile. At its core are 3 main roles:

• ScrumMaster
• Product Owner
• Team

ScrumMaster

The ScrumMaster is responsible for making the process run smoothly, removing obstacles, and for running the critical meetings.

 

Product Owner

The Product Owner is responsible for defining, recording and prioritizing the requirements (including maintaining Product Backlog), and generally acting as the interface to the business. The Product Owner also makes the final call on whether a feature is “done done”, that is whether it meets all requirements to a suitable level of quality.

 

Team

The folks who develop and test the product. Ideally, the team is self-organizing in that they can decide the who and how of the work to be done. Typical team sizes are 5-9 people.

 

In addition to the 3 main roles of Scrum, there is also an additional role that is not always considered core, but which is increasingly an integral part of Agile, and that is the Development Manager. I discuss this role more in a separate post What is a Dev Manager.

 

Summary

So we have touched upon some of the basics of agile, and covered some of the common flavors, including Scrum. But really these are just guidelines. You can and should pick and choose what works best for you.

Further reading

Recommended books

• The Art of Agile Development
• Practices of an Agile Developer: Working in the Real World
• The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win

Useful links

• http://www.agilenutshell.com/what_is_agile
• https://www.blossom.co/blog/agile-software-history,
• https://www.cprime.com/resources/what-is-agile-what-is-scrum/
• http://www.allaboutagile.com/what-is-agile-10-key-principles/
• https://www.scrumalliance.org/community/articles/2014/september/principles-of-accountability-for-agile-organizatio
• https://www.scrumalliance.org/community/articles/2014/april/accountability-in-scrum

References

1: The term Feedback Driven Development was coined by Dr. Venkat Subramaniam, https://www.agilelearner.com

 

Tags: agile, extremeprogramming, kanban, methodology, scrum, scrummaster, xp