This article discusses the Scrum Manifesto and the Agile Manifesto. The article discusses the history of the manifesto and the 4 values of the Agile manifesto.
The History of Agile
A 59 Seconds Agile Video Animation
The Agile Scrum Manifesto For Product Owners
Early 1990’s saw a number of software development projects being cancelled. Those which were completed did not meet current needs of the business. The reason behind this was that the business needs were changing quickly. Traditional software development was not a fast process and was rigid towards changes. There was a huge time gap between business needs and actual delivery of the software to market. With this frustration in mind, seventeen thought leaders met at The Lodge at Snowbird ski resort in Utah, in 2001 to find answers to challenges faced in traditional software development processes. They came up with four values which came to be known as “Agile Manifesto”. This Manifesto was to ensure the development of high-quality and working software quickly.
The Agile Scrum Manifesto Values
The 4 values of Agile Manifesto read:
– Individuals and Interactions over Processes and Tools
– Working software over comprehensive documentation
– Customer collaboration over contract negotiation
– Responding to change over following a plan
The Agile manifesto states while there is value in the items on the right, we value the items on the left more. Let’s look at each value in more detail and how a product owner can imbibe these values in his and scrum team’s work.
The Scrum Manifesto: Individuals and Interactions over Processes and Tools
Tools and Processes are not capable of responding to changing business needs. It is people and their interactions with each other which will lead to a quick response to changes. If a software development is highly dependent on processes and tools, it takes much more time to accommodate new ideas or new requirements. That is why Agile puts a lot more emphasis on people and their ability to adapt to new ideas. Agile, as a set of values and principles, stresses the need of tools. Tools are needed at various stages of software development. The importance of tools is not undermined, but the tools and processes should act as enablers for the changes and not limit or inhibit people’s ability to change.
A product owner is the owner of business requirements. This role requires him to be a bridge between stakeholders/customer and the development team. The Product Owner needs to be abreast of the changing needs of the business and communicate on-time and as needed to the development team. He has to create understanding on the product backlog between various stakeholders through interactions with various individuals. He needs to communicate product vision and ensure clarity of stories of next few sprints to all development team members.
Apart from being an owner of the product backlog, product owner also needs to enhance understanding of this value among his team. He needs to empower development team to collaborate and prepare them to adapt to changes.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
The Scrum Manifesto: Working software over comprehensive documentation
Traditional software development models were dependent heavily on documentation. It took a lot of time to develop technical requirements, design documents, test cases, etc. and each document passed through stages of reviews and approvals. Agile does not eliminate documentation altogether. It focuses on developing just-enough documents required for the development team to start their work.
In an Agile environment, Product owner and scrum master both work towards creating working software for the customer to make sure that business value can be achieved early. User Stories are built for each requirement and contain enough details for the development team to begin work on the functionality.
Working software means the software meets what is known as the definition of done (DOD). A DOD would typically ensure that the working software delivered has been developed with sufficient controls like reviews and testing in place, it has been integrated and is adequately documented. PO Defines the DOD for working software at the beginning of the project which will be delivered at the end of each sprint to the customer.
Customer collaboration over contract negotiation
The traditional way of doing business required formal negotiation with the customer at the beginning of the project and re-negotiations done, whenever required. The customer was involved in the negotiation of requirements at the beginning in great detail and would finally have a look at the deliveries after several months. Whenever changes were required, re-negotiation was done before the change could be incorporated into the software.