Fundamentals of agility: The target

The focus on the target is an essential element of the engineering. The question is to know if it is possible to focus on the target. Often this target is too big or too fuzzy so that the members of the team can focus them on it.

With the V cycle, there is no definition of the limit of the target. The good teams will choose realistic targets and the others rarely. The agile methods define realistic targets.

In agility, the length of the stories or the tasks is surrounded. For the stories, the length of each story has a value in the Finobacci series. Only the stories which have a length under 7 are analyzed and can have a sufficient priority to be included in the next sprint. For the other, either they are not having priority, or they are factorized in sub-story enough small. The tasks must not be last more than one day.

The focus on the target is easier with agility because the targets of each member are more accurate. Particularly with Scrum, the roles of each are exactly defined. The members of the team program and test. They know the entire project and work on each part of it. The pair programming allow understanding the way of working of the other members. The standardization of the rules of programming, commentary and literature give a common base of working. The members can be focused on the production of a quality code. The Scrum master is focused on the respect of the rules of the agility and also on the rules defined by the company and the team. The Product Owner is focused on the needs and the priorities of the customer. The customer is focused on the appropriateness between the product and the user’s needs. It is recommended to him to factorize his needs so that they are easy to understand.

It is always easier to focus on a small target. The fractal dimension of an IT project is often forbidden. When I watch a project, I start by seeing algorithms, next in the upper dimension objects which organize and perform these algorithms, next packages which propose contracts, next services which propose more complex contracts, finally software which supply services and interact with the users. In each dimension, the analysis, the description and the programming must ask less than one day. This length is the full time of focusing on an accurate continuous work.

The target is the aim of each member of the team. The Agile Methods propose a way to create targets which have a realistic length.

About craft in IT

Throughout my career and in particularly during my interviews, I met people who would consider IT like a craft activity. The difference between Craft and Industry is less in the quantity than how to make.

A craftsman makes masterpiece for each customer and a manufacturer produces consumer goods. This difference shows an important perspective on the way to work. A manufacturer produces objects which have to satisfy to the bigger number. A craftsman makes a particular object for a specific person.

In IT, a wrong idea is to think that the software is a masterpiece but it is a usual illusion for many reasons. First, the programmer thinks he is the first to solve the problem. Even if it is a new case, the elements of the problem already exist. It is enough to analyze and to factorize the problem to know the solution already known. The programmer’s work consists more in assembling permanent solutions to create quality software, than to rewrite algorithms that other validated before. Second, software is not for a specific use but it is an ordinary tool. Another illusion is for the customer. He often thinks his problem is specific, but his problem is mostly the same of his competitors at less. Finally, IT is an engineering work where the true difficulties are in the understanding the customer’s needs.

Another difference is about economical aspect. An IT firm must respect two principal constraints: cost and delay. Unlike a craftsman who realizes a masterpiece, the means are limited.

Quality also has a different meaning. For a craftsman, it is intrinsic because he works for a unique customer. For a manufacturer, it is a more complex idea because it works for customers and users which have different needs and targets. They all work towards the success of the company but the constraints of their works are not the same.

The IT as an industry must satisfy customers and users. An additional problem arise, the users don’t have the same needs. During the analysis of the needs of the users, the correct definition of the roles of each user is very important and to understand the need of each role. Indeed, in all company, it is necessary to forget people because they change quicker than the role. Each role defines precise duties. Some people can have some roles. A role expresses the job of the user and is shared by many companies. Some role exists in all company.

A classic problem for IT companies include Software Engineering Company, software editor is to focus to the technology. They must follow the technologic changes which are difficult because they are quick. But it is an illusion because it is often the updating of existing technology. Three real revolutions take place: Object programming, Agile Method and cloud computing because they change the level of abstraction of the job which they concern: programming, the organisation of job and the infrastructure which are fundamentals for IT.

The IT is an industry in its huge majority. Some specific cases exist with few programmers who are often the best. A programmer generally puts together validated components. The heavy analyst’s task is to understand the needs of customers and users. The Scrum Product Owner must obtain the realization of standard functions and in the same time managing the belief of the customer about the specificity of his company.

Des bases de l’agilité : L’objectif

La focalisation sur l’objectif est un élément principal de l’ingénierie. La question est de savoir s’il est possible de se focaliser sur l’objectif. Souvent cet objectif est trop grand ou trop flou pour que les membres de l’équipe puissent se focaliser dessus.

Dans le cycle en V, il n’existe aucune définition de la limite d’un objectif. Les bonnes équipes vont choisir des objectifs réalistes et les autres rarement. Les méthodes agiles définissent des objectifs réalistes.

Dans l’agilité, la dimension des stories ou des taches est limitée. Pour les stories, la taille de chaque story a une valeur choisie dans la suite de Finobacci. Seules les story dont la taille est inférieure à 7 sont analysées et peuvent avoir une priorité suffisante pour faire partie du sprint suivant. Pour toutes les autres, soit elles ne sont pas prioritaires, soit elles sont décomposées en sous-story suffisamment petites. Pour les taches, elles ne doivent pas durer plus d’une journée.

La focalisation sur l’objectif est plus facile avec l’agilité car ceux de chaque participant sont plus précis. En particulier avec SCRUM, les rôles de chacun sont parfaitement définis. Les membres des équipes réalisent ou testent le code. Ils connaissent la totalité du projet et peuvent intervenir sur toutes les parties de celui-ci. Le travail en pair programming leur permet de connaitre la manière de travailler des autres membres de l’équipe. La normalisation des règles de codage, de commentaires, et de documentation offre un socle commun de travail. Les membres peuvent se focaliser sur la production d’un code de qualité. Le Scrum Master se focalise sur le respect des règles de l’agilité mais aussi sur les règles qui ont été définies par l’entreprise et l’équipe. Le Product Owner se focalise sur le besoin et les priorités du client. Le client se focalise sur l’adéquation entre le produit et les besoins de ses utilisateurs. Il lui est d’ailleurs recommandé de décomposer ces besoins pour qu’ils soient facilement compréhensibles.

Il est toujours plus facile de se focaliser sur un objectif petit. La dimension fractale d’un projet informatique est souvent oubliée. Lorsque je regarde un projet, je commence par voir des algorithmes, puis à la dimension supérieure des objets qui organisent et exécutent ces algorithmes, puis des packages qui remplissent des contrats, puis des services qui remplissent des contrats plus complexes, puis des applications qui fournissent des services et interagissent avec l‘utilisateur. A chaque dimension, l’analyse, la description ou la réalisation doit demander un travail de moins d’une journée. Cette durée correspond aux temps maximum de focalisation sur un travail précis continu.

L’objectif est le but de chaque membre de l’équipe. Les méthodes agiles proposent une solution pour créer des objectifs dont la taille est réaliste.

De l’artisanat en informatique

Tout au long de ma carrière et en particulier pendant les entretiens d’embauche, j’ai rencontré des personnes qui considéraient l’informatique comme une activité artisanale. La différence entre l’artisanat et l’industrie tient moins dans les volumes traités que dans la manière de faire.

Un artisan réalise des chefs d’œuvre pour chacun de ses clients et l’industriel des biens de consommation. Cette différence ne concerne pas tous ceux que se prétendent artisan. Mais elle offre une perspective importante sur la manière de travailler. Un industriel réalise des objets qui doivent plaire aux plus grand nombre. L’artisan lui réalise un objet pour une personne particulière.

En informatique, une idée fausse est de penser que le programme est un chef d’œuvre est une illusion habituelle. Et cela pour plusieurs raisons, la première est de croire d’être le premier à résoudre ce problème. Même, si la situation est nouvelle, les éléments qui vont permettre de le résoudre existent déjà. Il suffit d’analyser et de décomposer le problème pour savoir ce qu’il faut chercher comme solutions validées. Le travail de programmeur consiste plus à assembler des solutions pérennes pour créer un programme de qualité, qu’à réécrire des algorithmes que d’autres ont validé depuis longtemps. La seconde est que le programme n’est pas destiné à un usage exceptionnel mais c’est un outil du quotidien. Une autre illusion est celle du client. Il s’imagine très souvent que son problème est particulier. Alors que son problème est la plupart du temps le même que ses concurrents au moins. Enfin, l’informatique est un travail d’ingénierie où la vraie difficulté est dans la compréhension des problèmes du client.

L’autre différence est sur les aspects économiques. Une entreprise informatique doit respecter deux contraintes majeures : les coûts et les délais. Contrairement à un artisan qui réalise un chef d’œuvre, les moyens sont limités.

La qualité a aussi une signification différente. Pour un artisan, c’est une notion intrinsèque car il travaille pour un seul client. Pour un industrielle, c’est une notion plus complexe car il y a des clients et des utilisateurs dont les besoins et les objectifs ne sont pas identiques. Ils concourent tous à la réussite de l’entreprise mais les contraintes de leurs travail ne sont pas les mêmes.

L’informatique en tant qu’industrie doit satisfaire des clients et des utilisateurs. Un problème supplémentaire se pose, c’est que les utilisateurs n’ont pas les mêmes besoins. Lors de la phase d’analyse des besoins clients, il est très important de définir correctement les rôles de chaque utilisateur, et de comprendre les besoins de chacun de ces rôles. En effet, même dans une petite entreprise il faut faire abstraction des individus car ils changeront au cours du temps alors que les rôles évolueront peu. Chaque rôle correspond à des fonctions précises. Certaines personnes pourront être associées à plusieurs rôles. Un avantage est que ces rôles sont en réalité une expression du métier de l’utilisateur et est partagé par des sociétés différentes. Ils existent même des rôles qui existent dans toutes les sociétés.

Un problème courant dans les sociétés informatiques (SSII, intégrateur, ou éditeur) est la polarisation sur la technologie. Il est certain que le suivi des évolutions technologiques est un problème en informatique car il est rapide. Mais c’est une illusion car c’est souvent la remise au goût du jour de technologie qui existe déjà. Il existe trois véritables révolutions : la programmation orientée objet, les méthodes agiles, et le cloud computing car elle change le niveau d’abstraction du métier qu’elle concerne : la programmation, l’organisation du travail, et l’infrastructure qui sont les trois bases de l’informatique.

L’informatique est une industrie dans son immense majorité. Il existe quelque cas particulier qui concerne peu d’informaticiens qui sont souvent les meilleurs. Un programmeur assemble le plus souvent des composants validés. L’analyste a la lourde tache de comprendre les besoins des clients et des utilisateurs. Le scrum product owner doit lui faire réaliser des fonctions standards tout en gérant la croyance de l’utilisateur dans la particularité de sa société.

Fundamentals of agility: Time boxing

The time boxing is a main part of agility. But, it’s a difficult idea to explain precisely and to implement. The basic idea is to control and encapsulate the time of the action.

The time boxing allow to an agile team and its members to control the working time and the time limit for the realization by cutting in tasks. Each task is so small it’s possible to define exactly the working time and respect this time. This way of working is applied on all the activities from the realization to the meeting and the personal projects. In fact, it’s a way of thinking, each time I’m going to do something; I begin with the valuation of the work. If the time is too big, which mean that the valuation is imprecise, I break up it to valuate each part as well as the integration.

The simplest sample is the management of meetings. For the industrial quality a meeting is defined in order of priority by the agenda, the length, the participants with a role, a day and a time, and a place. A meeting doesn’t respect the agenda or the length failed. When you prepare a meeting, you start by define a target. This target gives the points to tackle. Each point is evaluated. If a point is difficult to define or estimate, it will be split. When all the points are completely define and valuate, the agenda is done. Careful, a meeting can’t take more than 2 hours. Otherwise the points discussed after will be skimmed over or settled. In this case, you must organise some meetings with smaller targets perfectly defined and a synthesis meeting. Sometime, you can organize a meeting with some targets; you should separate them with ns introductions and conclusions to allow to the members to know the target of the meeting at a time.

Define a time for a task and do it in the time expected show the control on the achievement.

This is a basic aspect of the agility. In fact, when the set up Agile Methods is to delivery in a defined time some functions divided in tasks. These functions are done which means that they can be tested and tested, with no bugs. The only remarks must be improvements to obtain a perfect adequacy with the needs of customers and users. The definition of the done is an essential part of the agility.

Now, we can master the working time because if the breaking up of the tasks is enough short. The tasks are already known and their valuation known. A known task was not necessarily done before but a similar task was done in which you can valuate the new easily.

In another part, this mastering of the working time allows a realistic undertaking toward customers. They can see unlike previous experiences, the deliveries are done in the time with a good quality. They use less time to test the delivery and these tests are about the functional part and the imprecision on the product that is generally associated to communication troubles between the customer and the product owner. Some points often minor are difficult to explain precisely.

This way also avoids starting an unrealistic project. Often for a customer or a user, a function is simple in his opinion but lead to difficult troubles for the programmer. If the customer participates to the planning meeting, he can understand the difficulties to realize these functions. The explanation shows to a customer that the evaluation is realistic and is the sum of the tasks from which he isn’t used to thinking.

This communication way is another basic part of agility. It leans to the transparency and the honesty. It is naturally going to a trust relation where the parts communicate more information to each other what avoid mistakes and allow finishing more quickly a good and efficient solution.

Des bases de l’agilité : le time boxing

Le time boxing est une notion difficile à traduire en français. La traduction la plus fidèle est la gestion du temps par encapsulation. Cette idée parait simple en anglais et compliqué en français. En fait, elle est simple à expliquer mais difficile à réaliser.

Le time boxing doit permettre à une équipe agile et à ses membres de contrôler le temps de travail et les délais de réalisation en découpant les taches pour travailler uniquement sur des taches avec un temps de réalisation maitrisable et définissable. Cette manière de travailler concerne toutes les activités de la réalisation aux réunions et les projets personnels.

En fait, c’est plutôt une attitude mentale, chaque fois que je me prépare à faire une action, je commence par estimer le temps dont j’ai besoin. Si ce temps est trop important. C’est à dire que son estimation est floue, je la décompose pour pouvoir estimer précisément chaque partie y compris l’intégration.

L’application la plus simple est la gestion des réunions. Pour la qualité industrielle, une réunion est définie par ordre d’importance par un ordre du jour, une durée, des participants avec un rôle, une date et une heure et un lieu. Une réunion qui ne respecte pas l’ordre du jour et sa durée est une réunion ratée. La préparation de la réunion commence par se définir un objectif. Cet objectif fournit des points à aborder. Chaque point est estimé. Si un point pose des problèmes (définition, estimation), il doit être décomposé. Lorsque les différents points sont complètement définis et chiffrés, l’ordre du jour est réalisé. Attention, une réunion ne doit pas durer plus de 2 heures, sinon les points traités après seront survolés ou liquidés. Dans ce cas, il faut organiser plusieurs réunions avec des sous-objectifs parfaitement clairs et une réunion de synthèse. Parfois il est possible d’organiser une réunion avec plusieurs objectifs, il faudra prévoir de la séparer avec des conclusions et des introductions pour permettre aux participants de savoir l’objectif de la réunion traité à un moment donné.

Définir un temps pour une tache et réaliser celle-ci dans le temps prévu montre la maitrise de la réalisation. C’est le premier pas dans le contrôle de son travail et vers le travail de qualité.

C’est un aspect fondamental de l’agilité. En effet, la mise en place des méthodes agiles a pour objectif de livrer dans un temps défini des fonctions réparties en taches. Ces fonctions sont finies, c'est-à-dire qu’elles sont testables et testés et ne contiennent pas de bug. Les seuls remarques doivent être des évolutions pour obtenir une parfaite adéquation avec les besoins des clients et des utilisateurs. La définition du fini est un élément essentiel de l’agilité dont je parlerais dans un prochain article.

Il est aujourd’hui possible de maitriser le temps de travail car si la décomposition des taches est suffisamment fines, les taches sont déjà connues et leurs chiffrages possibles. Une tache connue n’a pas forcément été déjà réalisé avant mais une tache similaire a été réalisé ce qui permet de chiffrer l’actuelle facilement.

D’autre part, cette maitrise des temps de travail permet un engagement réaliste vis-à-vis du client. Il peut voir que contrairement aux expériences précédentes, les livraisons sont réalisées dans les délais et que le produit est de bonne qualité. Il consacre moins de temps à tester le livrable et ses tests concerne les aspects fonctionnels et les imprécisions sur le produits qui sont généralement liées à des problèmes de communications entre le client et le product owner. Il existe toujours des points souvent de détail qu’il est difficile d’expliquer.

Cette approche évite aussi de s’engager sur des projets irréalistes. Souvent pour un client ou un utilisateur, une fonctionnalité est simple de son point de vue mais pose des problèmes complexes à la réalisation. Sa participation à la décomposition de la fonction permet de lui faire comprendre les difficultés qui seront rencontrées lors de la réalisation. Cette explication montre à un client que le chiffrage ne sort pas d’un chapeau mais est la somme de taches auxquelles il n’est pas formé à penser.

Cette forme de communication est une autre base de l’agilité. Elle s’appuie sur la transparence et l’honnêteté. Elle amène naturellement à une relation de confiance où les deux parties se transmettent plus d’informations ce qui évite les malentendus et permet d’aboutir plus rapidement à une solution satisfaisante.

About quality for software

Many definitions of the quality exist. The software industry is an industry. The definition of the industrial quality is:

A quality product corresponds to the requirement press out by the customer. It isn’t the best product, it’s the product asked by the customer and the users.

The essential idea is the quality is not Excellency. A requirement of the customer can be the life term of the product.

When we make software, we have two main methods: the V Cycle and the Agile Methods.

A project which is realized with the V Cycle method use 6 ordered steps to complete the project:

· The needs analyze

· The specifications

· The realization

· The tests

· The delivery

The quality is controlled at the end of the process and concerns the entire project. Often with the delay on the project, few tests are done. These tests concern the needs describe in the beginning of the project. For the projects which need more than 3 months of work, they consider a need which is partially changed. The project quality depends on the perfect success of all the step.

For the Agile Methods, the situation is different. One of principles is to adapt the software to the consumer need during the project. Consequently, the requirements in the beginning of the project can be different of those for the delivery. In this way, the project can’t be a quality project.

The practice of the actual quality is to manage and to complete the definition of the quality with the change of the need during the project. A manufacturer built a production line for a car, use it, and adapt it during about 10 years. During this time, the norm, the law and the public taste change. It is therefore necessary to adapt original requirements to these new requirements. Yet, the cars verify the constraint of the industrial quality. In the industry, the quality is organized in step and must be verified for each component and their assembly and for the final assembly.

This approach allows seeing that the Agile Methods verify the industrial quality much better than the V Cycle. One of the foundations is the Test Driven Development. Each software element is tested and the tests are executed for each change. The tests concern the objects, the stories, the features and the software performance. In other hand, at the end of each sprint, the delivery is a quality software even if it is a partial software. For the Agile Methods, the idea of beta tester doesn’t exist. An informed user or a super user replaces it. This user is a person who knows well the job and also preferably the IT. He can use the partial delivery and can give judicious advice about the change to do. His function isn’t to discover the bugs of the software but to show the improvement which is going to allow realizing the product the most adapted to the needs of the customer and the users.