aot 2009Monthly :

in Agile

What about the team?

What about the team?

Individuals and interactions over processes and tools. This basic core value stated in the Agile Manifesto implies so much it’s hard for     anyone to totally grasp it.  As an Agile coach I owe it to myself and to my clients to properly understand this value and do my best in   helping teams and organizations apply it.  But how can we achieve an efficient level of interactions that is high in value?

I don’t impose a lot of conditions to organizations who want to start a so called Agile project but there’s one where negotiation is not    possible : Having a team.  Not a group of individuals working for the same manager but a team of professionals aiming for the same goal.  If this can not be appreciated by the organization, I see no need to go any further.  It’s the foundation to any successful I.T. project!  And forget about  moving on to the “working software”, “customer collaboration” and “responding to change” values without a solid team.

I enjoy taking it one step further by creating a team where the frame of mind is one of a small company.  While respecting the fact that team members are proud to be working for their employer (at least I hope  they are), they need to create this small company feel and understand that THEY are responsible for the failure or success of THEIR project. With this philosophy in place, rich, open and honest interactions become essential.  Of course this doesn’t happen over night and a team needs to move through those well known “Forming, Storming, Norming and Performing” stages.

If you want your project to succeed, you need individuals that are able to interact efficiently. Efficient interactions happen when individuals are aiming for the same goal, trust each other and are accountable for their success.  Put together a team of competent, cross-functional professionals, allow them to reach a performing stage and there’s not much they can’t achieve.  Oh! By the way, this perfect team includes the client…

in Développement logiciel

Using metaphore in the application domain

Tuesday I caught the presentation “System metaphore revisted” by Joshua Kerievsky and Brian Foote. The presentation was interesting, but left me with some mixed feelings.

Firstly let me say that I was not previously familiar with XP’s metaphore. I will not attempt an exmplanation, I may get some important points wrong, and in any case there is already existing liturature on the subject.

Their presentation brought up various example of metaphores applied to entire systems, and the continual reflection that goes into finding an appropriate metaphore. A good metaphore can facilitate understanding of the system and generate insight into new ideas. This is inded a powerful tool.

Metaphore is already present in much of our common, every-day software landscape, and helps express the behaviour of many of its components. Some plaform examples include pipes and streams, some system examples include folders and files and desktops. These metaphores provoke clues as to what is being described and the kind of behaviour that can be expected.

A few questions in the room were raised about how the metaphore relates to the use of the ubiquitous domain language advocated in DDD. The answers did not resolve the uneasyiness that I felt at the idea of mixing metaphore in the domain language or in replacing the domain language with a metaphore.

The idea of metaphore appears to work well in a context where you are developing YOUR application and you are your own client. I really dont see the interest in using a metaphore to describe an application in a context where the domain is already well defined and provides a wealth of terms to describ it. Better yet, the domain language does not need translating between developers and users. It seems wastfull and dangerous to add potential confusion to an already difficult process.

A side disscussion after the presentation with Rebecca Wirfs-Brock and Michel Feathers (I hate plugging names, but the insight is not my own), lead to the suggestion that the value of the metaphore arises from providing a parallel for a behavior we can relate to. A given metaphore provides an insight for a kind of problem. Perphaps we need a catalog of metaphores that can help to simplify the expression of common subsystems.

So in order to simplify the expressing of something with assembly line charactersistics the assembly line metaphore is appropriate. Certainly a small body of metaphores could easily cover a good number of underlying application behaviors. These start to tend towards patterns and frameworks: “if faced with such and such a situation, apply this kind of solution”.

A cautionary note is due here: it is impossible to expect a catalog of metaphores to meet high-level application needs, if this was possible a handfull of applications would have dominated the world’s business world. Alas things are not that simple.

I think these guys have done some cool stuff with the idea of the metaphore, and I can see an interest in exploring it when the domain is mine to choose. I’m relatively certain that the overhead of model to domain translation required to communicate with clients is unnecessay and unjustifiable on a project with a pre-defined domain language.

in Vie @ Pyxis

Agile 2009 Jour 3 – J’ai encore soif!

Aujourd’hui, grosse journée avec des sessions dès 9h. Et je vous rassure, le titre ne fait pas référence à la bière que j’ai bue ce soir à la soirée francophone ;)

La journée a très bien commencé avec une session sur le leadership par Mme Leadership en personne : Pollyanna Pixton. La présentation s’appelait “Stepping Up and Stepping Back: The Leadership Tipping Point” et c’est le 3e module sur 4 d’une formation sur le leadership conçue à la base pour IBM.

Elle a sa façon à elle de présenter le leadership : “Step back and let them do their job!”. Elle insiste énormément sur l’importance de faire confiance à tous nos collègues: “Si vous ne leur faites pas confiance, ils le savent!”, “Suspicion is a permanent condition”. Elle soutient que les vrais leaders ne prennent jamais de décision. Surtout quand ils sont haut dans la hiérarchie…

Elle nous a même fait faire un exercice intéressant. Nous avons discuté pendant quelques minutes avec notre voisin de table. L’un d’entre nous était un “worker bee” et l’autre le “leader”. Le worker exposait un problème, et le leader NE DEVAIT ABSOLUMENT PAS DONNER DE SOLUTION. Ça me rappelle beaucoup ce qu’on a vu en formation de coaching et ce qu’on doit faire comme caddy. J’ai réussi à me taire, mais j’ai de nouveau réalisé à quel point c’est difficile! La conversation est allée dans le bon sens lorsque j’ai demandé à mon interlocuteur de me dire la raison pourquoi il pensait que j’étais mieux placé que lui pour prendre cette décision.

En bonus, j’ai appris l’existence d’un bouquin qu’elle a trouvé très inspirant : The Seven Day Week-end. Le bouquin parle d’une compagnie brésilienne, Semco, qui ressemble étrangement à Pyxis… Les sceptiques seront confondus! Qui disait qu’on ne pourrait pas scaler?

Imagine a company where employees set their own hours; where there are no offices, no job titles, no business plans; where employees get to endorse or veto any new venture; where kids are encouraged to run the halls; and where the CEO lets other people make nearly all the decisions. This company—Semco—actually exists, and despite a seeming recipe for chaos, its revenues have grown from $35 million to $160 million in the last six years. It has virtually no staff turnover, and there are no signs that its growth will stop any time soon.

En sortant de ce meeting, en se retrouvant tous les 3, on a discuté de ce qu’on avait entendu dans nos sessions. Il est intéressant de voir comment des interprétations à première vue opposées se révèlent être des aspects d’une même réalité, vus d’angles différents, et tout à fait complémentaires au final. Je ne vous en dis pas plus, on va sûrement produire quelque chose là-dessus…

Malheureusement, j’ai suivi son conseil d’aller au deuxième module qu’elle présentait en après-midi. Or, ce n’était pas la meilleure idée, car beaucoup de matériel se répétait. Normal, c’étaient 2 sessions différentes, pas une session de 180 minutes!

Bon, je vais me coucher. Je vais vérifier quelques fois mon cadran, car demain matin ne serait pas un bon moment pour ne pas me réveiller :p

in Vie @ Pyxis

Agile 2009 Jour 2, ça n’arrête pas…

Aujourd’hui j’ai assisté à 5 sessions et j’ai marché un peu dans Chicago. L’heure de notre présentation s’en vient (jeudi matin) et je commence à être nerveuse, mais je me dis que c’est une bonne chose que j’assiste à autant de présentations, ça me permet d’enrichir le nôtre!

Alors aujourd’hui, j’ai assisté à :

  • Keynote: par Alistair Cockburn. Bon orateur, évidemment… Si j’ai bien compris, il a dit qu’il y avait à peine 5 compagnies au monde qui arrivaient à exprimer les besoins des clients sous la forme de spécifications exécutables? Ai-je mal compris? Aussi, c’est le premier que j’entends soulever des craintes par rapport à la monotonie des processus continus à la Kanban…
  • Pragmatically “Crossing the Chasm” from Project-level to Enterprise Adoption : Celle-là a viré, croyez-le ou non, en discussion sur l’efficacité des meetings! Le modèle qu’il propose pour les transitions Agiles est inspirant, ça permet de structurer facilement une roadmap avec un client.
  • ScrumMasters Considered Harmful – Where Did It Go Wrong? : déception ici… J’aime bien sa liste de “symptômes” qui révèlent les ScrumMasters nuisibles. Il soutient avec raisons que les ScrumMasters sont souvent mal choisis et ne connaissent pas bien leur rôle.
  • Can you hear me now? Good… : sur les outils utilisés dans les projets distribués. Très bon contenu, enfin une présentation concrète! Ça manquait, sur ce stage…

…et un “talk” surprenant d’un des Vendors : “Fixed-Price Contracts in Agile Development” (par des gars de Danube). Pourquoi surprenant? Parce que les commanditaires, en général, profitent de cette demi-heure pour vanter leur produit, pas pour discuter d’un sujet X. Mais aussi, car il est surprenant qu’il ait réussi à nous communiquer une présentation qu’il donne habituellement en une heure en 20 minutes, coincées entre UrbanTurtle et les sessions d’après-midi, dans un bruit épouvantable de chocs d’assiettes et des échos des autres discussions l’entourant.

Mais vous savez quoi? Sa réponse à lui c’est d’utiliser les Function Points de COSMIC pour définir une entente dans le contrat. Je pourrai vous en parler davantage quand j’aurai digéré ses slides, ce midi je n’ai pu que les survoler. Mais c’est intéressant, ça nous permettra de pousser notre réflexion sur ce sujet déjà.

Pour les intéressés à voir le résultat de ma marche dans Chicago, une ville extrêmement propre et sécuritaire (et on comprend pourquoi quand on entend parler des lois qui la régissent!), mes photos sont ici : IsaAtPyxis

Vous saviez qu’il y a une “Agile Lawyers Association“?
La citation de la journée : “Kick people out of the SHU box!” ~A. Cockburn.

in Agile

Agile2009 – Jour 1 – Integration Tests Are A Scam – J. B. Rainsberger

I went to see J.B. Rainsberger’s “Integration tests are a scam” today at Agile 2009.

A good portion of the presentation focused on the sheer numbers of tests required to tests the combined complexity of many classes integrated together. His argument being that the gap between the actual coverage of integration tests and adequate coverage is largely unmeasurable, but makes for such uncertainty in test coverage as to make integration tests mostly meaningless. In fact worse, they lead to a false sense of security.

His solution to this is one of separating dependencies (notably services) with interfaces (see the dependency inversion principle) and using these interfaces to:

  1. test the client object using mocks
  2. test the server object via its interface to ensure contract (interface) compliance

This will allow a great deal of confidence in the successful integration of components because their interactions have been validate sufficiently with incurring the cost of integration tests. In fact he recommends putting integration tests aside, only bringing them in to find specific bugs, but throw them away once the bug is solved and unit tested.

Another important advantage of this approach is the increased test execution speed. This goes without saying.

Past experimentation with this led me to the conclusion that some of the pain you feel when using mocks to test each class in isolation is tied directly to the design of the code being tested or mocked. Consequently the cure for this pain is a modeling one. Breaking down objects into smaller ones with fewer dependencies helps to reduce the complexity of the individual components (see the single responsibility principle).

Applications go from small model/large objects to large model/small objects.

This poses a new problem for teams. Breaking objects down into smaller ones can be a challenge, especially for developers less comfortable object modeling concepts. This often leads to a clutter of very poorly named objects that are unnavigable. Great attention must be put into ensuring navigable namespaces and classes.

The presentation did not state that acceptance, stress and other types of tests should be dismissed, but ultimately that interaction testing with integration tests was unjustifiably costly for its poor ROI.

All in all a well presented, if a controversial subject. I agree that favoring unit and interaction tests is a great way to develop with code confidence. I’m not sure I’m ready to throw away integration testing, but maybe I’ll give it a try for a bit. Who knows, maybe I’ll like it.

What do you think?

in Agile

Agile2009 – Jour 1 – Sessions

Voici les sessions auxquelles Isa, Erik et moi avons assistées:

Moi
Workflow is Orthogonal to Schedule – Mary Poppendieck
New Approaches to Risk Management – David Anderson
Lets stop calling it “agile” – Bas Vodde, Steven Mak
Integration Tests Are A Scam – J. B. Rainsberger

Isa
Distributed Agile Development: Experiments at Microsoft patterns & practices – Ade Miller
Value or Velocity? – Brandon Carlson
Zen and the Art of Software Quality – Jim Highsmith

Erik
Using the Agile Testing Quadrants to Plan Your Testing Efforts – Janet Gregory
Advances in Release Planning – Jim Highsmith
Integration Tests Are A Scam – J. B. Rainsberger

in Agile

Agile2009 – Jour 1 – Workflow is Orthogonal to Schedule – Mary Poppendieck

Note: Je prends des notes pendant les sessions. Voilà pourquoi ça peut sembler un peu “décousu” :0) Je tente de résumer en gros ce qui a le plus retenu mon attention.

Séance #1 – Workflow is Orthogonal to Schedule
avec Mary Poppendieck

J’ai bien fait d’arriver tôt, il y a une bonne vingtaine de personnes debout!

Mary nous présente certains détails de la construction de l’Empire State Building de NY:
- September 22, 1929 : Demolition started
- January 22, 1930 : Excavation started Excavation started
- March 17, 1930 : Construction started
- November 13 1930 : Exterior completed
- May 1, 1931 : Building opened Building opened exactly on time
>18% under budget

Quelques clés de la réussite?
- Focus sur le “flow”
- Travail d’équipe : client (propriétaire), architecte et constructeur
- Des constructeurs expérimentés
- “Flow” constant des camion (matériel), pas de stockage (“pull”)
- Découplage au maximum: conçu pour un maximum d’indépendance
- “Cash flow thinking”: 10k$ par jour de retard (représente 120k$ aujourd’hui)!
- “Design” basé sur les contraintes: date limite, $$$$, lois de la physique, aire disponible, zonage
- Embaucher les personnes qui comprennent les détails tôt dans le processus de “design”, il n’y a rien qui vaut plus l’expérience!
- Travail d’équipe: respect et confiance
- Réduction de la complexité en découplant judicieusement == réduction des dépendances
- Bien comprendre les contraintes à tous les niveaux
- Le DONE: doit être très bien compris!
- Encore: TOUT le monde travaille pour arriver à la date limite…. TOUS ensemble, tout le temps.
- Re-encore: bon travaille d’équipe au “top level”

Il y a eu ensuite le parallèle avec le Kanban. (voir présentation pdf)

Il y a eu une question intéressante d’une personne qui disait que les itérations “forçaient” le travaille d’équipe. Elle se questionnait à savoir comment ça pouvait bien fonctionner avec le Kanban…
R: Si tu es obligé de “forcer” le travailler d’équipe… ce n’est pas juste avec le Kanban que ça ne fonctionnera pas…!

in Vie @ Pyxis

Agile2009 – L’arrivée

Je viens d’arriver.
C’est excitant.
Notre booth (Urban Turtle / GreenPepper) est tout juste à coté de celui de Microsoft! Yeah!

Francois nous dit qu’il y a quelque chose qui se trame avec Sonar (http://sonar.codehaus.org/). Rien de concret encore.
À suivre…

Dans le taxi entre l’aéroport et l’hôtel de la conférence (une heure “pogné” dans le “traffic”), Erik, Martin, Isa et moi avons échangé sur les sessions qui semblaient intéressantes.
Selon nos intérêts, ça s’est bien distributé.

Voici où et quand seront les conférences Agile20xx pour les trois prochaines années:
2010: Nashville, Tenesse, 9 au 13 août
2011: Salt Lake City, Utah du 7 au 13 août
2012: Grapevine, Texas du 13 au 17 août

Alors, c’est parti!
Première conf pour moi: Workflow is Orthogonal to Schedule avec Mary Poppendieck

in Nouvelles et événements

Rencontre de la Communauté de pratique en planification le 15 septembre 2009

Venez assister à la conférence “Agile du point de vue d’un PMP”

L’inscription en ligne sera disponible sous peu sur le site du PMI Montréal http://www.pmimontreal.org

Conférencier : M. François Beauregard
Il est fondateur de Pyxis. Animé d’une passion pour le développement logiciel, François souhaite participer à des projets de développement logiciel dont les résultats sont exceptionnels tout en maximisant la qualité de vie et la satisfaction personnelle de tous les intervenants. Il agit comme accompagnateur, formateur, facilitateur et conseiller expert pour des entreprises désirant améliorer leur productivité en développement informatique et adopter une approche Agile. En juillet 2002, avec des collègues de Pyxis, il a fondé Agile Montréal, un groupe d’intérêt sur les méthodes de développement Agile, et y fait des présentations régulièrement.

2. Thème principal
Le but est de faire une présentation d’introduction à l’agilité. En introduction, les similitudes, les différences et les parallèles entre l’approche en cascade et l’approche Agile seront exposés afin d’éclairer et de briser les stéréotypes de l’approche Agile. Dans un deuxième temps, une démarche de transition vers l’Agilité sera expliquée.
Entre temps, je vous invite à écouter (et publiciser!) notre tout nouveau podcast : http://voxagile.pyxis-tech.com/

COÛT
Gratuit

QUAND
Le Mardi 15 Septembre 09 de 17h 30 (réseautage) 18 h 00 à 19 h15 Conférence

OÙ
La Salle des boiseries de l’UQAM, local J-2805 au 2e étage du pavillon Judith-Jasmin (J) situé au 405, rue Sainte-Catherine Est. Sous le clocher de la rue Saint-Denis. On y accède depuis la Grande Place.