Agility : Principle


Principle 7 : An operational software (an operational product) is the main measure of progress of a project

The 4 values ​​of Agility are divided into 12 principles. As and when I approach them in the transformations, I have identified success factors according to 3 focus: intensio- from a team point of view; Extensio-from a managerial or organizational point of view; Mago-from an individual point of view. The objective of this article series on the Agile Manifesto is to share these different focuses.

Principle 7- An operational software (an operational product) is the main measure of progress of a project

When we talk about operational, we mean here, which is appropriate to the needs of the stakeholders. Therefore, the solution must be easy to handle by stakeholders and quick to test.

Focus- Intensio, from a team point of view

This is a special moment for the team: the meeting with the client. In any Agile startup, this aspect is extremely important. It must be prepared upstream with the client.

Remember, there are no specifications but quick deliveries to validate with the customer that its needs are met by the product delivered.

It is an invitation to dialogue on the proposed solution. The ultimate verdict is when the customer himself takes delivery on hand during the demonstration. By its simplicity, delivery is an invitation to use immediately. The customer thus takes possession of his product at each stage.

In order for this to work, you must determine with your customer the acceptance criteria for each delivery period. It will also take into account, periods to work on the robustness of the features or products delivered: indeed, a solution designed for 10 people has nothing to do with a solution for 1000 people.

This validation principle on the software itself allows the implementation of value 4 of the Agile Manifesto: accept the change at any time in the development of the project.

For this to be possible, each development must be easy to install and test, and the installed features must not be dependent on each new delivery.

That’s why development teams engage in a quality process from the start. This gave birth to a software craftmanship community, having itself a manifesto.

This community is very active and defends the quality of the deliveries made and even claims a code like an ARTISANAT of ART.

To my knowledge, Agile products, other than software, have no Quality label.

Here we touch the main pitfall of Agility on a scale. The team to keep deliveries quality and flexible will have to adopt clear operating rules both with its client and management.

For software, the team will often have to integrate habits integrating each line of codes tests, and isolating the features of each other. The Test Driven Development or the clean code will be strengthened as well as the ability of the team to identify and anticipate problems.

Automation testing will also have to be challenged to allow teams to continue to deliver and / or position themselves on other value-added products

Focus Extensio, from an organizational point of view

In terms of organization here, it is the contact with a real use of the delivered products as well as the customer contact who will be challenged by the management. Indeed, in scale transformations, direct contact with the customer is lost. He is replaced by Products Owners.

Organizations often do not keep pace with deliveries and delivery becomes mechanical. We deliver every 15 days, whatever the cost, even if there is no reason at this rate. It is at this moment, that the quality problems and the resistance to the Agility is likely to be born.

Here the management must guarantee the meaning to be given to Teams and DARE to stop a project if it has entered an operational phase.

Maintaining this phase is possible when the company is fully organized in Agile mode. The organizational matrix can not work because it generates delays due to a non-functional process and multiple activities making it impossible to manually integrate the delivered features.

In this case, the teams are thus autonomous and self-managed production units.

The SAFEe model, Scaled Agile Framework, makes it possible to set up an Agile process without compromising the functional organization of the companies in transformation. Nevertheless, it will be necessary to ensure that the teams are autonomous and self-managed production units. (Re-read Principle 3 to learn more)

FOCUS MAGO, from an individual point of view

When an Agile team is working well, Principle 7- An operational software, (an operational product) is the primary measure of progress of a project is the benchmark. The success of the team is visible and envied. It is then possible to think an Agile to scale.

However, if success makes the team visible, the individual here will also see new criteria for measuring individual performance. He enters a phase of denial because the individual is not a machine. Delivery over short periods makes sense only if the team delivers value each time.

If the added value delivered is maintained, the individual then enters a FLOW- High skill + high challenge = flow.

The passion for his work will be maintained then. On the other hand, if the organization does not change, deliveries pile up and make no sense. The individual demotivates and stops progressively delivering on a regular basis. If the company continues to ask the team for ongoing deliveries, then the team will burst. Individuals will go elsewhere. They themselves transformed by this FLOW to which they will have tasted and acquired individually.

The company will be left alone in the face of its doubts, and a transformation that is no longer one but a return to the controlling pragmatism called Production, and so ape by Charlie Chaplin, modern times.

Read also: Essay: Why employees love Scrum and not the bosses!

The levers of your business transformation.

Transform the team, talk with an Agile coach.

This article was conceived and written by Dominique Popiolek, leader and professional coach.