Delivering Odoo the Agile Way

An Introduction to Agile Way - Blog Series 1

Odoo Delivered in Agile Way

How about adopting a proven project management process to deliver a versatile software?

Contact us

We have adopted the Agile approach to delivering our software implementation projects. 

Why Agile:

a) We are working mostly with young and dynamic company leaders who want an insane amount of work done in the shortest possible time.

b) The technology transformation happening in our market is highly disruptive for client businesses. Rapid strides are happening ever since cloud technology became mainstream.

c) The political, economic, social changes happening around us is turning the world upside down. One global pandemic has changed how businesses operate. This is truly a VUCA environment globally and in the market we operate. VUCA Stands for Volatile, Uncertain, this has created a volatile, uncertain, complex and ambiguous situation for everyone.

d) Plans keep changing and we were no more able to stick to the plans we make at the beginning of the project. We are unable to satisfy some of those wish lists that become part of binding contracts we sign with the clients. 

What's Agile:

The Agile Manifesto is comprised of four foundational values and 12 supporting principles which lead the Agile approach to software development. Each Agile methodology applies the four values in different ways, but all of them rely on them to guide the development and delivery of high-quality, working software.

 

1. Individuals and Interactions Over Processes and Tools

The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.” Valuing people more highly than processes or tools is easy to understand because it is the people who respond to business needs and drive the development process. If the process or the tools drive development, the team is less responsive to change and less likely to meet customer needs. Communication is an example of the difference between valuing individuals versus process. In the case of individuals, communication is fluid and happens when a need arises. In the case of process, communication is scheduled and requires specific content

2. Working Software Over Comprehensive Documentation

Historically, enormous amounts of time were spent on documenting the product for development and ultimate delivery. Technical specifications, technical requirements, technical prospectus, interface design documents, test plans, documentation plans, and approvals required for each. The list was extensive and was a cause for the long delays in development. Agile does not eliminate documentation, but it streamlines it in a form that gives the developer what is needed to do the work without getting bogged down in minutiae. Agile documents requirements as user stories, which are sufficient for a software developer to begin the task of building a new function.The Agile Manifesto values documentation, but it values working software more.

3. Customer Collaboration Over Contract Negotiation

Negotiation is the period when the customer and the product manager work out the details of a delivery, with points along the way where the details may be renegotiated. Collaboration is a different creature entirely. With development models such as Waterfall, customers negotiate the requirements for the product, often in great detail, prior to any work starting. This meant the customer was involved in the process of development before development began and after it was completed, but not during the process. The Agile Manifesto describes a customer who is engaged and collaborates throughout the development process, making. This makes it far easier for development to meet their needs of the customer. Agile methods may include the customer at intervals for periodic demos, but a project could just as easily have an end-user as a daily part of the team and attending all meetings, ensuring the product meets the business needs of the customer.

4. Responding to Change Over Following a Plan

Traditional software development regarded change as an expense, so it was to be avoided. The intention was to develop detailed, elaborate plans, with a defined set of features and with everything, generally, having as high a priority as everything else, and with a large number of many dependencies on delivering in a certain order so that the team can work on the next piece of the puzzle.