Agile, Scrum, and Customer Oriented Development

A Classic Software Development Problem

Have you ever been involved in a large software development effort that spanned several months only to have customers not use it? Most developers have and probably more than once.

Assuring that software you develop actually addresses the needs of client has always been one of the biggest challenges in software development. Addressing this problem was one of the motivations behind the Agile manifesto. The first guiding principle of the Agile manifesto states:

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

What is the Agile Manifesto

The Agile manifesto was developed by a group of seventeen software developers who met in Utah for two days in February 1991. It reads as follows:  

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.

While the Agile manifesto and the underlying principles are non-specific about software development practices, most people will agree that there are two hallmarks of an agile software development team or process:

• Early, frequent, and continuous delivery of software
• Customer collaboration 

If you actually follow these two principles you are very likely going to deliver software that customers actually want to use.  

When an organization starts being “agile” it’s relatively easy for them to get into the habit of delivering software to their customers frequently. Customer collaboration unfortunately is a lot harder to get right and is the subject of the rest of the article

The Scrum Methodology does not guarantee Agility

If you are a software developer then chances are that you have heard of the Scrum Methodology. You can find a brief description on Wikipedia and more extensive documentation at JeffSutherland.com/ScrumPapers.pdf.

In a nutshell Scrum involves teams delivering software in incremental periods called sprints or iterations. The scrum team consists of a product owner, a scrum master, and team members. The product owner is called the voice of the customer, and acts as a proxy for the customer at the planning meetings.  

Many people equate Scrum with Agile, and its creators have promoted it heavily as an Agile software development process. It may come as a surprise that you can follow the Scrum methodology to the letter and completely ignore actual customers!

In the Scrum methodology the only point at which customers might get involved is during the sprint review, but this isn’t obligatory. The theory is that having a product owner (who is usually a product designer, product manager, or software developer) act as a proxy for a customer is good enough. The problem is that they aren’t actually customers. They have their own biases and agendas that aren’t necessarily in line with customer desires or needs.  

I’m not suggesting that Scrum is a bad software development methodology, or that product owners are pointless. I’m saying that to avoid creating a feature that is a YAGNI (You Aren't Going to Need It) you have to actually collaborate directly with your customers during your iterations.  

Summary: Customer Oriented Development

Agile is more than just a buzzword; it represents a number of desirable goals and principles for commercial software development.

While Scrum and other Agile software development processes have proven value, I propose organizations adopting these methodologies still need to assure that their software development process is driven by customers.  

I assert that the following principles can help any software development team, regardless of the methodology they may use, to assure a customer oriented development process:

1. Deliver software to customers early and frequently 
2. Gather feedback from customers after each delivery and share with the entire development team 
3. Involve customers in reviewing and prioritizing user stories 
4. Don’t implement things customers haven’t agreed to
5. No one can substitute for an actual customer

References

• Writing The Agile Manifesto, by Martin Fowler 
• Examining the Agile Manifesto, by Scott Ambler
• Agile Principles and Values, by Jeff Sutherland
• History: The Agile Manifesto
• Learning Scrum - The Product Owner