The 4 values
Value 1 : Interacting with people rather than processes and tools.
The cohesion of a team is more important than the monitoring of conventions. This sentence focuses on the quality of the individuals involved and the spirit of collaboration that makes it a real team effort. It reflects the synergy and motivation that must leave secondary, the rigidity of the process and the complexity of the tools. Elitism is left aside, often linked to technical knowledge, interpersonal skills and motivation.
Value 2 : An operational product rather than a plethora of documentation.
Partially functional software is always more valuable than careful documentation.
The goal of a software development is to produce software, the documentation must be considered as complementary support to its understanding. It is better to focus on the product rather than the elements that describe it.
Value 3 : Collaboration with the customer rather than contractual negotiation.
The customer and the supplier are partners who share a risk. Agility is about collaboration between the two parties to achieve a common goal. The client must get involved and lead the team in the realization stages. He must take ownership of the evolution of his product.
agility avoids the waste of negotiations and change requests. It proposes to invest its efforts constructively.
Value 4 : Responsiveness to change rather than following a plan.
Agility recognizes learning done during a project. That not everything is known in advance and that adaptations are inevitable. Change is integrated into the development model. The original planning should not be too detailed, as some aspects will probably never be realized. This avoids unnecessarily detailing elements too early in the project.
The 12 principles
Principle 1 :Our first priority is to satisfy the customer by delivering useful software early and regularly.
Quickly putting the software to the customer’s test is the first recommendation of Agile methods. Due to this feedback, we will know the necessary adjustments as soon as possible.
Here we find the idea of the Milkrun used in Lean steps.
Principle 2 : Change is accepted, even late in development. Agile processes exploit change as a competitive advantage for the customer.
Agile methods incorporate change management into their mode of operation. Changes are integrated when planning a new iteration.
To draw a parallel with the state of mind of Lean, we are here in « welcome positively the problems ».
Principle 3 : Frequently deliver a functional app, every two weeks to two months, with a trend for the shortest period.
We reach the idea of the first principle, increase our reactivity and our flexibility by delivering the customer as often as possible (Idea of the Milkrun). It drastically reduces the risks and can therefore adapt more easily to changes. What’s more, these fast deliveries motivate the team and help maintain a good work schedule.
Principle 4 : Managers and developers must work together daily throughout the project.
It is one of the values to minimize “ papers” and the ongoing review of contract terms. Frequent meetings with the manager are there to avoid problems and respond to problems.
In Lean Spirit, working with the customer, suppliers and all value chain partners is part of.
Principle 5 : Build the project around motivated people. Give them the environment and support they need, and believe in their ability to do the job.
The quality of a project goes through motivated and involved teams. Managers must trust them and leave the autonomy to do this work.
Principle 6 : The most effective method for conveying information within a team is a face-to-face conversation.
Direct exchange is the most effective way to decide, share … We find here the philosophy Gemba, important in the Lean method.
Principle 7 : Functional software is the best unit of measure for project progress.
It is the elements that were able to test and validate the client that are the best proof of the good progress of the project and the progress of it. The idea is always here to deviate from too heavy planning and implement the Gemba culture .
Principle 8 : Agile processes promote a sustainable pace of development. Sponsors, developers and users are able to maintain a constant pace indefinitely.
The workload must not put too much pressure on the teams because it causes abnormal fatigue. The load must be smooth in time, to avoid jolts and loads too heavy.
By doing the corollary with Lean, this principle conveys the idea of Heijunka, to ensure a constant charge and smoothed over time.
Principle 9 : Continued attention to technical excellence and design quality improves agility.
Good design facilitates system changes and maintainability. Thus, special attention must be paid to the quality of programming.
Here we find the idea of manage upstream issues and the Pilar 5 of TPM.
Principle 10 : Simplicity – the art of maximizing the amount of work not to be done – is essential.
Simplicity and minimization is one of the most important facets of Agility. We are talking here about the notion of Muda, fundamental philosophy of Lean. The challenge is to avoid any unnecessary actions or functions, not only generating work and additional problems.
Principle 11 : The best architectures, specifications and designs come from self-organizing teams.
The team must make the technical decisions because they are in the best position to take them. Technological skills must allow them the autonomy required to optimize results. Developers are often proud of their work and seek technical excellence.
This is the idea of Autonomous Production Units : multifunctional teams (maintenance, production, purchase …) to pilot the production workshops.
Principle 12 : At regular intervals, the team thinks about ways to become more efficient, then gives and adjusts its behavior in this direction.
The questioning of work processes and a foundation of Agility. At regular intervals, the teams must meet and dedicate time to review their way of doing things and know how to do better.
This principle reflects the idea of Kaizen, at the origin of Lean.
Users Stories at the center of concerns
Agility places at the center of all concerns the satisfaction of customer needs. Here we come to the same philosophy as Lean wishing to create the maximum of added value for the customer, or that the 6 Sigma aimed at targeting the Voice of Customer.
Here or in Lean Six Sigma terms, the customer need is described in Critical To Quality, Agility speaks of User Stories.
A « user story » is a requirement formulated in one or more sentences. They are used as specifications, and represent the criteria during the acceptance tests.
The use of User Story encourages not to go into detail until it is necessary. Ron Jeffries 2 proposes a 3C rule to deal with User Story :
- Card : The story is written on a fairly small map. These cards can be annotated with time estimates…
- Conversation : The details of the story will be expressed in conversation with the Product Owner. We’ll use the following conversation structure. Example : As a visitor, I can click on the button register to get to the registration form.
- Confirmation : It clearly defines the acceptance criteria.
A good User Story is defined according to the anagram INVEST3 :
- Independant : Each User Story expresses a different function than the others.
- Negotiable : it can always be reviewed and rewritten iteratively.
- Valuable : Brings a value, one more vis-à-vis the user.
- Estimable : We are able to estimate the time and cost of implementation.
- Sized to fit : Set limited scope for better understanding.
- Testable : Lets you give one or more criteria for accepting the story.
The tools of agility
Agile methods were developed in response to the inefficiency and heaviness of traditional 4 approaches. These projects are planned and aim to predict their progress through the respect of a whole set of programming standards. In contrast, agile methods prefer to adapt during the project. For this reason, the agility tools are classified according to a Adaptive – Normative 5 continuum of which here is a proposal.
← Normative ———————————————- Adaptive →
Relatively heavy method and specifying many practices and rules of development
Very light method adapting to the context and devoid of rules and development practices
RUP – DSDM / RAD – XP / ASD / FDD – SCRUM / LD / Crystal Clear – Kanban