Agile Development (Theory in practice) : James Shore and Shane Warden

During a trip, I’ve read this book.  I think it’s a very good book to start with when you plan to implement agility in your team. Both as a developer or a Product.

Was chatting with a friend of mine some days ago, on the ‘where to start’. Indeed it’s difficult. You may be frighten to introduced agility as a whole, but it’s the best solution. Remove all your usages, challenge your team.  But this required both a hightly motivated team, and a good Agile/Scrum practitioner to ask for help on a regular basis.

So, I’ll try why I love the book :

• Reminder of the agile manifesto … most of the team who plan to move to agile, have read it one day … but it’s a good reminder
• The book addressed different aspect of agility : developers, scrum master (scrum method), product, client ….  I’ve seen several team forgetting to quickly that one of the objectives of Agility is to make product and end-user happy. It’s not only about making developers happy.

Among the key tips & trap i’d like to read again in the book :

• Stories : Ensure the team share the product vision, challenge your stories by asking : what’s the value for the customer … I especially love the challenge card game. One card, one idea challenge the feature….  Product should define MMF (minimal marketable feature). During TShirt sizing, product and developers should challenge each other, if product requires a feature complex to implement, sometime he will be happy with an ersatz of the feature, but easy to do. The product should also define, how to test the feature.
• Sprint planning :  the team (or a team member) should have prepare the sprint planning, he should have understand what the product want, and anticipate most of the technical issues. Define the success criteria of your sprint.
• Estimate : time give you idea on how you did mistake on estimation … a team will all the time estimate the same way… (same X% error)
• Sprint :  remove task as soon as possible (if you have some delay), it will help team working on the most priority one, and will involve product on definition of the new priorities.
• Demo : don’t lie … if your demo don’t work, be honest .. don’t hide something … elsewhere next sprint, or the “Go live” will be a disaster …

Release process:

• Each release made by a different person, should be part of the sprint, as at the end of the sprint you should be able to go live …

Pair programming , the magic solution ?

After several year of watching/reviewing agile project, I’m wondering what make a project a success or a massive failure.
First, to clarify my definition of success is : the team has delivered what the product and/or the end user was expected in a timely way. With this definition, i removed the aspect of a product team not delivering what the end user expect that’s occur … sometime … often …
So, assuming you have a group of 7-10 engineers, what make a project a success or a failure :

Success key :

• team spirit : everyone is happy to help each team members
• task sharing : everyone in the team can take every task
• release : everyone can release the project
• bugs : everyone works on bugs
• refactoring : everyone re-factor the code, enhance it
• Code quality is the first priority of the eng. team
• Delivering backlog item is the second one.

Failure Keys :

• each task can be take by only one or two guys
• Delivering poor quality backlog item, requiring post sprint refactoring … never done in the real life … so increasing the technical debt.
• Having several backlog : one for the product team, one for the technical stuff … We are delivering software, so technical issue is part of the product.
• Team changing often … introducing a new person is the team, is not so easy, as the team is working as one guy, it’s may be difficult to be part of it.

That still a list under progress, but from my experience, the two keys for success are :

• Good communication among engineer and product team
• Good team work, and in this context, pair programming seems to me the best way to achieve most of the engineering requirement with one practice.

Indeed, by doing extreme pair programing, even team programming is a easy way to achieve all the success point.
Let me explain a bit. What i call extreme pair programming is a pair programing practice were :

• you change the pair often (at least once a day)
• as soon as you need an expert point of view, change the pair, to get the help you need
• as soon as you are block, change the pair, explaining your problem to a new comer, often unblock you.
• when you need to define a new team practice, take a projector, all the team looking at the screen, only one keyboard … and do an time boxes open discussion to present the benefits of the practice …
• change keyboard often … may be one developer write the test, and the other one write the code ….
• you wrote faster code : development is not writing text in a code source file … you have to think, analyze, design, test … So, two brain for one keyboard is not a waste of time
• Do not interrupt the code writer too often, you have to think about design issue, code enhancement … you don’t have time to focus on typos.

So as a conclusion, may be one of the first development practices to put in place is pair programming for the success of your project.

Writer (open office) pour les novices

Après Impress, voici writer …

Writer pour les débutants

Attention : pour le moment le document n’est qu’a l’état de brouillon.

Impress 2009 – Comment ca marche ?

Petit exercice de style, faire une présentation pour présenter l’utilisation d’Impress 2009 à un jeune public.
La présentation en PDF est disponible en cliquant sur le lien précédant

Tous les commentaires sont les bienvenus.

L’achimiste Agile est de retour

Après avoir vécu dans la peau d’un elfe au cours d’une soirée, j’ai voulu à mon tour faire partager l’aventure a mes petits camarades.
Première erreur, faire ça un lundi matin …. J’avais pourtant été prévoyant, et n’avais mis l’atelier qu’a 9h30 …. mais 2 pannes d’oreiller, un enfant malade, et un oubli ou eu raison de 4 lutins…..
Du coup, j’ai un peu adapté les groupes

L’achimiste Agile est de retour

Après avoir vécu dans la peau d’un elfe au cours d’une soirée, j’ai voulu à mon tour faire partager l’aventure a mes petits camarades.
Première erreur, faire ça un lundi matin …. J’avais pourtant été prévoyant, et n’avais mis l’atelier qu’a 9h30 …. mais 2 pannes d’oreiller, un enfant malade, et un oubli ou eu raison de 4 lutins…..
Du coup, j’ai un peu adapté les groupes et leur taille.
Résultat : que du bonheur.
J’ai profité de la séance pour tester une idée : sous traité à un animateur des activités genre ‘gestion de la timeline’, ‘du vote’, ‘recherche de la cause, avec la méthode des 5 pourquoi’.
Cela principalement pour laisser un peu de temps au scrum master, le temps de reprendre un peu “son souffle” et d’observer le groupe d’un peu plus loin. Effet secondaire intéressant, une implication plus active du groupe.
Conclusion : que du bonheur …

L’alchimiste Agile

Des envies de Noël ? Vous avez envis de vous prendre pour un Père Noël, un elfe, un renne , …..

je vous encourage a lire, essayer, expérimenter l’alchimiste Agile.

Hier, (grâce à l’absence d’Alex … ), j’ai eu l’occasion, au sein du CARA , de pratiquer les rétrospectives sous un angle nouveau.

Déguisé en père Noël, Emmanuel nous à fait réfléchir à comment améliorer notre ligne de fabrication de jouets …. Sans vouloir tout décrire, je vous encourage à lire le blog de nos amis suisses, ainsi que d’approfondir la méthode des 5 pourquoi, qui permet, a mon humble avis, de se rapprocher de la cause du problème.

Code review checklist

Starting a new code review process, trying to make it simple. After searching the web among my old links (No More Hacks), I’m sumarizing here my conclusion.

Review/Checklist guidelines (for short review, focused on one topic):

• specific to the review : avoid having a generic checklist to long
• Measurable point : ensure the decision is black or white, avoiding conflicting decision
• Agreed among the team : ensure guidelines/checklist have team agreement
• time box approach : avoid endless meeting, do them short/focused, we’ll try a 30minutes approach per topic.
• No more than 6  items : 30 minutes is short … to many item is not realistic
• Nothing automated : everything that can be automated, must be automated. To use human brain for that.
• updated on a regular basis : review, team skill, application issues, change over time, so review and update your checklist to match team priority.

Having that in minds, a quick meeting among the team help us to define 3 checklist : Java, Unit test, static code analysis.

Java :

• Documentation : does the reviewer can easily understand the code
• Correct handling of try/catch code
• justify visibility of method (private/public/….)
• Test policy of the code described

Unit test :

• does all bugs fixed are illustrated by a unit test ?
• does mock objects are used
• does tests are deterministic and don’t required external dependencies

Static code analysis tool

• Focus on top priority issues : memory leak and JDBC connection management
• For each fix, ensure a test exist to ensure behavior is kept. If you change behavior ensure impact at application level (add functional tests)
• Investigate to ensure it’s not a false/positive, if you decide it’s a false positive, make it reviewed by someone else.

How to write a new authoring tool in Agile

or how to avoid to have wordpad for the price of word, or how to avoid to have word when you want a tool to edit math over the web

If I have to do such stuff (wonder how such idea come to me ? ), I’ll in the following order :

1. Look for standard dealing with the subject and I’ll find MathML . (Don’t want to make the wheel again to store my Data)
2. Understand than an authoring storage format differ of the display format (DOC/PDF, …) indeed, all authoring tool need to store meta data (author, revision, pagination, …, revision, …)
3. Try to find the need of my user (print the page, copy/paste in/from word/office/firefox/IE/…)
4. Try to cleary define what i want

So, my first backlog (list of tasks, will look like ) :

1. Setup My continuous integration env
2. provide a simple GUI with ‘/’/division nice display
3. provide print function
4. provide copy/paste function from word

I think quite quickly, I’ll have to add matrix/vector/square/root fonction display,

but what about spell checker ? pagination ? indeed, for my user, what’s the most important ? currently no clue of it, and I’ll say, don’t think to much at the question before the first proto. Human are so strange, than the need can come from nowhere …..

May be, import text from forum, internet, or paste to forum will be the key requirement.

After, from a technical point of view, as I know i’ll need to include most of a standard authoring tools fonctionnality, will I make the wheel again, or will I extend a standard tools ? (word/office),  extend a wiki like tool ? extend a forum tool ? use the remote publication mode of word/office/wiki ?  Will I force my user to be online to edit content, of will I allow offline authoring ? ……

Lot of question/answers I’ll have after the first prototype….

So, as a first conclusion, doing a quick/rapid prototype seems to be a key success factor in this area.

Agility will help me to focus on the most valuable features to my end user, and to deliver on a regular basis working prototypes.

Code quality

I’ve not post for some time, i was quite bust to set up some CI / metrics tools on a new project.

This raise me some questions / comments.

1) Complexity of the tools

When you read (even in my posts) it’s simple …  I’ve forget a bit the ‘open community’ and in its bad aspects.

Let me illustrate a bit. I am working in a team using mainly Java / Php.

So, using standard tools :

• Source revision control : svn
• IDE : eclipse
• Build : Maven
• CI : hudson

So, up to now, everything looks fine. I used to use some static code anlysis, in order to know the code quality :

Jdepend, PMD, findbugs, Javancss, cobertura, sonar, Coverity, …

So, nothing really exotic/fancy and most of them are ‘classical’ static code analysis tools.

So,  doing  my ‘Yoda’ show, i’ve encourage the team to use them as soon as possible in their development process so in the IDE.

I’ve plug them in their pom file (maven configuration file), update my hudson installation to have the trend, ….

AND … you know what …. 6 tools,  16 versions needed, because of incompatibility in maven, hudson,  pmd, ….

1 tool , 4 plugin needed …. most of the time just to parse an XML file, or to draw a simple curve with linear data …..

What’s a mess ! where is simplicity ? easy to use ? why coupling a CI tools with build specific plugin ??? why mixing build tools with Source control tools ???

Why not keeping the principle of less coupling to build/CI/static code analysis tools ????

Doing dcode is important, but application design should not be forget.

2) the second point, is some comments : it’s expensive to fix issues …

How can someone justify that fixing an issues at developing time … 5 .. 10 minutes … is more expensive that discovering the issue in production (something like 1$ a minute ? ) , requiring some dev again, some QA, some deployment …..

Of course, the bug may never be seen in production …. for how long ?  Don’t forget the Murphy law : if you can have a problem, you’ll have it !