… à l'Ecole de la V.I.E …

Coaching et Team-Building : la parabole de la ceinture noire

La parabole de la ceinture noire

Imaginez un pratiquant en arts martiaux en train de s’agenouiller face au “sensei” au cours d’une cérémonie de remise d’une ceinture noire bien méritée.

Après des années d’entraînement intensif, l’étudiant a fini par atteindre l’apogée de la réussite dans sa discipline.

– « Avant que je ne t’accorde la ceinture, tu dois encore passer une épreuve », dit le Sensei.

– « Je suis prêt », répond l’étudiant, s’attendant probablement à un autre combat.

– « Tu dois répondre à la question essentielle »

– « Mais qu’elle est donc cette question ? »

– « Quelle est la vraie signification de la ceinture noire ? »

– « La fin du voyage », dit l’étudiant. « C’est une récompense bien méritée pour le travail fourni. »

Le Sensei attend davantage.

Il n’est visiblement pas satisfait.

Puis il finit par parler :

– “Tu n’es pas prêt pour la ceinture noire. Reviens dans un an.”

Un an plus tard, l’étudiant s’agenouille de nouveau devant le Sensei.

– « Quelle est la vraie signification de la ceinture noire ? », demande-t-il.

– « Un symbole du mérite et le plus grand accomplissement de notre art », répond l’étudiant.

Un instant, s’il vous plaît : imaginez un pratiquant en arts martiaux en train de s’agenouiller face au “Sensei” au cours d’une cérémonie de remise d’une ceinture noire bien méritée.

Le Sensei ne dit rien pendant plusieurs minutes, attendant.

Il n’est visiblement pas satisfait.

Puis il finit par parler :

– “Tu n’es pas prêt pour la ceinture noire. Reviens dans un an.”

Un an plus tard, l’étudiant s’agenouille encore une fois devant le Sensei.

Le Sensei demande encore à l’étudiant :

– “Quelle est la vraie signification de la ceinture noire ?

– « La ceinture noire représente le commencement, le départ d’un voyage infini dans la discipline, le travail et la poursuite d’un niveau toujours plus haut, dit l’étudiant.

– « Oui. Tu es désormais prêt à recevoir la ceinture noire et à commencer ton travail.”

…/…

à Mathilde

…

Une princesse à Rablay …

…

…/…

A celle qui se reconnaîtra

Je te donne …

… voir ici

Je te donne …

(Léo Ferré « Je te donne »
Midi première
video 01 avril 1977 1548 vues 03min 43s

Léo FERRE chante « Je te donne ».Photo de Marie diffusée à la fin de la chanson.)

Le Baudet du Poitou

Le Baudet du Poitou, une fierté du Pays mellois :

Voir sur le site de l’asinerie du Poitou ici

ou sur le site des Haras de France là

ou bien encore sur Wikipedia aussi

In english, it’s a Poitou Donkey, see this in Wikipedia.

Saint-Romans-lès-Melle dans le Pays mellois a été longtemps réputé pour ses foires aux mules.

Extrat : 9 importantes foires annuelles se tinrent longtemps à Saint-Romans qui possédait des halles, données au début du 19e siècle par le duc de Choiseul-Praslin, dernier seigneur de la commune. Il s’y effectuait de nombreuses transactions sur les mulets et les mules. Suite ici

Ci-dessous une carte postale d’une foire aux mules :

Et une des 9 auberges :

…/…

SAFe : Agile Scaled Framework (1)

SAFe is the latest Agile scaling approach.

See the Big Picture here.

In the last version (v.4.5 ), the framework is based on Lean-Agile thinking, Value Driven methods, Kanban flow, Scrum framework, DevOps and a Continuous Delivery Pipeline of Value.

It’s easy for knowlege sharing, continuous improvement, kaizen approach, configurability, implementation, guidance deploiement, and enhanced capabilities for improving the user experience and accelerating time to market.

SAFe is a simple but complexe frameworki Agile universe.

For the framework SAFe, read more here.

…/…

Essentiel vs Important

Savoir pourquoi la VIE existe, c’est important.

Mais comprendre comment Elle s’organise, c’est essentiel.

• by Rudolf STEINER, 1924 in « Cours aux agriculteurs »

Lien chez Triades editions à voir là

ou

ici

Value Driven Creation

Value.

Value : it’s all creating Value.

All the Stakeholders must be driven by creating value.

It’s the unique way to federate people in a project.

So we have motivated individuals and a whole motivated Team.

…/…

Leadership, TeamBuilding and Energy

Please stay here a few minutes, hear and see this

Hallelujah by Leonard COHEN in a Live in London Opus.

or a cover here by an autist …

Thanks

Agile failure modes and alternatives

• Agile practices don’t fail—rather the variations on Agile adoption fail”.
• What NOT to do while following certain practices in agile.
• There is no term like 99% agile. You are 100% agile or you are not

– Check book commitment doesn’t support organizational change management.

CEOs create within the company their own personal family dysfunction.

– Culture doesn’t support change.

Reward plan, and a static and prescriptive standard of work.

Try to keep cross-organizational uniformity and use PMO as enforcers.

– Do not have retrospectives, or they are bad.

Actions which come out get ignored or written off.

– In a race to finish features, the infrastructure gets worse and architecture becomes unstable.

Distributed teams make this worse.

– Lack of collaboration in planning.

Like having the whole team for release planning.

– None or too many Product Owners. Both cases look the same.

Agile is yet another hat to wear and the person is already too busy.

They check out and ask the team to just do Agile.

Can’t get past the ‘this sucks’ phase of adoption if the business is not bought in.

– Bad Scrum Master which uses a command and control style with the team to look faster, yet in reality slows things

down.

Low morale lowers IQ.

Take decisions away and it actually makes people stupider!

– No on-site evangelist.

If the teams are distributed, need one at every site.

Can’t reap the benefits of Agile or offshore without an on-site coach at each location.

No solid team. Actually missed this one, inferred. Empowered teams amplify learning.

– Tsunami of technical debt if don’t pull tests forward.

– Traditional performance appraisals.

Individual heroics rewarded, glad you’re not a team player!

– Revert to traditional.

Change is hard.

Hit the threshold where this sucks.

Revert back to old ways of doing business.

Agile control limits

Control limits

Choose the control chart which is fitting for your data

Determine the appropriate time period required for collecting the data and plotting the data collected

Collect the actual data construct your chart and analyze the data

Look for out for control signals on the control chart and investigate the cause

Out of control

One or multiple points outside the control limits

Seven points in a row above the range value

Multiple points in a row near the control limits

Tolerance

The result is acceptable if it falls with the range specified the tolerance

Control Limits

The process is said to be in control if the results falls within the control limits

Agile variance and trend analysis

A variance is the difference between an actual result and an expected result.

The process by which the total difference between standard and actual results is analysed is known as variance

analysis.

When actual results are better than the expected results, we have a favourable variance (F). If, on the other hand,

actual results are worse than expected results, we have an adverse (A).

Significance of variance analysis

The type of standard being used

Interdependence between variances

Controllability

Materiality

Variance and trend analysis

• Variance analysis is the difference between actual and planned behaviour.

For example, if you budget for sales to be $10,000 and actual sales are $8,000, variance analysis yields a difference

of $2,000.

• Variance analysis also involves the investigation of these differences, so that the outcome is a statement of the

difference from expectations, and an interpretation of why the variance occurred.

• To continue with the example, a complete analysis of the sales variance would be:Sales during the month were $2,000 lower than the budget of $10,000.

This variance was primarily caused by the loss of ABC customer at the end of the preceding month, which usually

buys $1,800 per month from the company. We lost ABC customer because we had several instances of late

deliveries to it over the past few months.

• This level of detailed variance analysis allows management to understand why fluctuations occur in its business, and what it can do to change the situation.

Agile Problem Solving

Problem solving steps

Detecting the problem

Pause and reflect on the problem

Take the problem to the team

Allow the team to act or not

Agile frequent verification and validation

Any iteration in agile development must produce artefacts, typically code, that pass the phase of verification and

validation.

Therefore, all iterations must have phases like this.

For requirements and design, the verification and validation is the result of peer reviews with team members and

with the customer

For coding, verification and validation is done by code reviews, unit testing and functional testing.

Basics of verification

Am I building the right product

Determining if the system complies with the requirements and performs functions for which it is intended and

meets the organization’s goals and user needs. It is traditional and is performed at the end of the project.

Am I accessing the right data

High level activity

Performed after a work product is produced against established criteria ensuring that the product integrates

correctly into the environment

Determination of correctness of the final software product by a development project with respect to the user needs

and requirements

Basics of validation

Am I building the product right

The review of interim work steps and interim deliverables during a project to ensure they are acceptable. To

determine if the system is consistent, adheres to standards, uses reliable techniques and prudent practices, and

performs the selected functions in the correct manner.

Am I accessing the data right (in the right place; in the right way).

Low level activity

Performed during development on key artefacts, like walkthroughs, reviews and inspections, mentor feedback

Demonstration of consistency, completeness, and correctness of the software at each stage and between each stage

of the development life cycle.

Importance of Verification and Validation in Agile

An Agile Methodology does NOT mean that there will be « frequent changes in requirements. »

What Agile specifically does is to begin with very high level view of the requirements at commencement, and

through the iterative process to begin honing those requirements with your stakeholders as they begin to interact

with the product itself.

Agile Continuous Integration

Continuous Integration is a software development practice where members of a team integrate their work

frequently, usually each person integrates at least daily – leading to multiple integrations per day.

Each integration is verified by an automated build (including test) to detect integration errors as quickly as

possible.

Many teams find that this approach leads to significantly reduced integration problems and allows a team to

develop cohesive software more rapidly.

Integration is often one of the most difficult moments in software projects.

In traditional waterfall development, the integration phase at the end of development can take a lot of time and reveal many design deficiencies.

Things become easier if the organization adopts the practice of bi-weekly, weekly, or daily builds.

The more frequently the system is built, tested, and verified, the earlier problems and deviations are found.

As with many other Extreme Programming practices, Continuous Integration is taking a known good practice to the

extreme level.

If it is good to integrate often, let’s keep the code integrated always.

The idea is to run the build and automated tests (at least the fast ones) whenever somebody checks code into the

version control system.

Usually it is done in automated manner by a tool such as CruiseControl

Benefits of Continuous Integration

When CI works well, it helps the code stay robust enough that customers and other stakeholders can play with the

code whenever they like.

This speeds the flow of development work overall; as Fowler points out, it has a very different feel to it.

It also encourages more feedback between programmers and customers, which helps the team get things right

before iteration deadlines.

Practices of Continuous integration (CI)

Maintain a single source repository

Automate the build

Make your build self testing

Everyone Commits To the Mainline Every Day

Every Commit Should Build the Mainline on an Integration Machine

Keep the Build Fast

Test in a Clone of the Production Environment

Make it Easy for Anyone to Get the Latest Executable

Everyone can see what’s happening

Automate Deployment