Scrum & Agile Manifesto Principle 1

Many software development companies are striving to become more agile and the Scrum is the agile buzzword #1 at the moment. The problem is that some companies or teams want to adopt Scrum just because they read about it on the internet and they are sure that if it is a simple agile framework it must be very easy using it. Besides, who wouldn't want to be more agile in these days?

Some people start using Scrum although they know almost nothing about the Scrum. It makes me really sad when I meet people with the following mindset "Scrum == Sprint". Yes, all they know about Scrum is that you have to work in some iterations called "Sprint". And at the end of the project they are so disappointed because the project was not as successful as they expected. That is because the Scrum is dramatically different from traditional sequential development. 

 

Every Scrum team member must be familiar with the basic values of Scrum. That's why I decided to wrote 12 posts about the foundation of all agile methodologies including Scrum: Agile Manifesto Principles. In every post I try to will explain one principle in a very simple way.

 

Here is the first principle:

 

Our highest priority is to satisfy the customer

through early and continuous delivery

of valuable software.

 

At the start of the new project you have to answer one really big question, what exactly are we building? The short answer is, that you must build the software that is going to be of value to the customer and will satisfy their needs. But in the reality it is not so simple to achieve that.

 

In the sequential development project you would first start with a lengthy up-front requirement-gathering phase. The result of this phase would be hundreds of pages of detailed requirements documentation where all features are equal important. Let's face it, the customer don't care about documents and UML diagrams and it is hard to get the right information from the customer and put it on the paper. They just want to get the software that maximizes the added value to their business and they don't know exactly what that value is on the first day of the project. There is a big chance that there will be some disappointment on the customer side when the software will be presented for the first time at the end of the project, although the software works as at it is described it the documentation.

 

There is a total different story with Scrum teams which adapt early and continuous delivery of valuable software because the client is involved throughout the lifetime of the project. That is how you can get early customer feedback and valuable emergent requirements. Scrum team documents all the features in a product backlog, which is a master list of all desired functionality not yet in the product. Product backlog is also known as prioritized feature list and priority is assigned based on the items of most value to the business or that offer the earliest ROI and value. Product owner has to groom the product backlog continuously because items are added, removed and reprioritized each sprint as more is learned about the product being developed. The result is that the most important and highest-priority items are implemented first because they are found at the top of the product backlog.

 

So, remember two words about this principle: satisfy (the customer) and valuable (software)!

 

You can find a very brief explanation of agility here.