Scrum Part 1 – Agile Manifesto



Scrum is an iterative and incremental agile software development methodology for managing product (software) development. We cannot discuss about Scrum without understanding Agile. In fact, many people could not run Scrum successfully because they do not have a clear fundamental understanding about Agile manifesto. When we understand the idea of Agile, all the prescriptive activities / ceremonies in Scrum would make better sense. First let’s look the 4 manifesto for Agile software development:

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

Individuals and interactions over processes and tools

Individuals and interactions over processes and tools

In development team, Agile encourages team members to interact with each other such as talking face to face, instant messaging, or email communication – instead of heavily depend on project management tool such as Trello, Asana, JIRA, etc. For example, if a team member notice there is a defect in the code written by another team member, he is encouraged to talk the other team member directly (maybe to discuss the root cause and possible solutions) instead of creating a ticket, assign to him in JIRA and call it a day.


When individual interaction take precedence, team members build the bonding to cover each other back. When processes and tools take precedence, team members would only look at their own plate and teamwork rarely happens. Having said that, it does not mean processes are not important. They are important to facilitate the operation but processes and tools should not be the central of development team. It is the team members who are building the product (software), the processes and tools are merely there to facilitate them to get their job done.


Working software over comprehensive documentation


Logically speaking, would you rather to have a working software, or a pile of comprehensive documentation? Theoretically it is best to have both. Unfortunately projects often lacks the most precious commodity – time. If the team has to choose either one, it should always be working software (duh?). First, documentations are often outdated and team members are unconsciously trained to not rely on documentations because the perception is documentations are inaccurate anyway. Second, it is much easier to navigate a working software than to navigate a 200 pages functional specification document. Documentations are often the poor fella sitting at the shared drive that no one looks at. Always choose to build a working software over writing comprehensive documentation when facing the challenge of limited time. After all, what is the purpose of documentation if the software is not working?

Customer collaboration over contract negotiation

Customer collaboration over contract negotiation

This might not be directly relevant to the team members who are actively building the product (software). It is a mindset the business decision makers should have. When business negotiates a contract with customer (regardless internal or external), a set of objective or functional requirement is often agreed upon. However with today’s speed of change in market, circumstances tend to change faster than business could anticipate. It is impractically for business to re-negotiate a new contract whenever a change take place. Both the development team and business must understand that collaboration is what makes great software. Customer has the understanding of the market to describe the requirements; while development team has the skill to transform requirements into features.


Collaboration with customers is one of the fastest ways to make customers happy. There are some customers from hell but those are exceptions. Generally customers do find greater satisfaction if customers are aware that development team put their business success in their best interested over making money from them with a contract.

Responding to change over following a plan

Responding to change over following a plan

If Plan A doesn’t work, don’t worry, the alphabet has 25 more letters. The ability to respond to change is the core of Agile. Thanks to today’s speed of change, the only constant in the market is change. If internal speed of change is slower than external, the business is doom to fail. So if things tend to change so often, why bother to have a plan? A plan is made base on best knowledge and known facts at that point of time. It provides a guideline to keep team members on track. Team members might learn higher quality knowledge and identify invalid facts along the way. The team would make use of the new knowledge and more accurate facts to deal with the situation more efficiently.

Responding to change over following a plan.joke

Managers should be the leaders to head the change response but ironically it is also the managers who are often very reluctant to change and claim “We have a plan, we need to follow our plan”. This could happen for various reasons and the justification could be valid or otherwise. Not all changes happen for a better outcome however if the team could identify a change is happening (or has happened) and an appropriate response is required, the team should respond by introducing a new plan. There is little value in protecting the ego and refusing to change. Responding to change might be painful in the beginning, but it always yield better return for the project on the long term.

This is a quick introduction on the Agile. On Part 2, we will discuss more on the prescriptive activities in Scrum.

Leave a Reply

Your email address will not be published. Required fields are marked *