avril 2010Monthly :

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -Robert A. Heinlein

Specialization is for insects. Image source: flickr.

Like most children, Tony had to pick a sport. Not being the athletic type he decided to pick up baseball just like most kids in the neighborhood. It was his one and only passion. He daydreamed about playing baseball in school and practice all winter while waiting for the next spring camp. When the local professional team moved away, most kids quit playing baseball and went back to either playing soccer or hockey.

Tony kept on playing for a season or two, then quit playing sports altogether having a hard time finding a league for players his age.

When it came to his professional life, Tony had the same attitude. When doing an internship in college, the quality bug bit him and he decided to become a full-fledged tester. Having secured a job in the country’s number one employer, he now saw it as a personal challenge to be the best tester on every team he ever dealt with. He most often was.

When projects started shifting to object oriented design, he started feeling a bit behind the curve. When the teams shifted to web design, he was really lost, but still kept helping the teams by finding bugs manually.

When the teams started switching to Agile, developers started taking quality more seriously and started writing their own tests. Tony felt terrible. Sure he was still finding bugs here and there, but the quality was really getting better and he felt more and more useless. He then had a talk with Maxim, the ScrumMaster who was leading the Agile initiative.

Maxim explained to him that instead of being threatened by change, he should embrace it. After all, he was the one championing for better quality all these year when nobody else cared. Now that everybody cared about it, maybe he could have a leadership role within this new team.

Tony decided to give it a try. He talked to the programmers about learning about testing and developing using those new web frameworks. After a couple of weeks of pair-programming, Tony was actually the one driving the developers about not skipping tests and doing rigid TDD.

Even more so, with his years of experience doing testing, he was always the one thinking about corner cases during the planning sessions and in his pair-programming sessions. Without him knowing, he was one his team’s biggest asset. Tony wasn’t just a one trick pony after all.

Nicholas Lemay

Most successful Agile/Scrum teams use a multi-level planning approach. There are a couple of quotes that I like and always mention in my Scrum training:

“Planning is everything. Plans are nothing.” – Winston Churchill

“No plan survives contact with the enemy.” – Helmuth von Moltke the Elder

I think they are good guiding principles.

Lets have a look at how Urban Turtle supports teams that use multi-level planning. Here we will use an example with releases and sprints but note that you can use as many levels as you want. However, if you decide to add more levels as a team, make sure they are truly needed and they are not just inducing extra complexity.

In this blog, I will use the user story and sprint terms because they are very common. Note that terms may vary depending on the process template you are using. Urban Turtle ships with mapping files for some popular Agile/Scrum process templates. It is very easy to create a simple XML mapping file to use Urban Turtle with almost any process template. For those who have their own customized process template, we will shortly write a blog entry that will explain how to easily create the mapping file.

During early project planning, the team will create some user stories and use Urban Turtle’s drag and drop capabilities to prioritize their product backlog.

When the team is ready for release planning, it is time to add the next release and some sprints. Here I have a sample release with three sprints.

Note that it may be tempting to try and schedule up-front every story in specific sprints, but our experience shows us that it is better to defer the decisions and let the team inspect and adapt as it achieves some sprints. By deferring the commitment as much as possible, the team takes ownership of their backlog and their planning activities. In other words, have the team evaluate their capacity for the release based on past velocity and commit user stories in the release according to this.

Note that because Urban Turtle computes all the statistic roll-ups, if the team is sure that a story needs to be done in a particular sprint, they can simply commit it to a sprint via drag and drop. In doing so, the release view will not be affected. When the team will get to the sprint planning for this particular sprint they will see an that the user story is already committed.

During the first part of a sprint planning activity, the team identifies its commitment for the next sprint. The team goes to the current release and checks the option to display only user stories that are not yet committed in a sprint. Then they drag and drop the stories they want to plan in the sprint until they feel they have reached their capacity.

Note again that Urban Turtle does all of the roll-ups for the user, allowing to have the statistics for your releases and sprints at a glance.

During the second part of sprint planning, the team creates the tasks that constitute their sprint backlog.

I hope that this blog gave you a good idea how Urban Turtle supports teams in their various planning activities while keeping the flexibility of not dogmatically following the suggested process.

Happy planning.

~francois

Le modèle de Kano est un outil permettant la priorisation des éléments d’un projet en projetant la disponibilité d’une fonctionnalité sur la satisfaction que celle ci apporte. La grande force de ce modèle tient dans son postulat de base : La satisfaction ou l’insatisfaction d’un utilisateur pour un même point n’est pas une notion diamétralement opposée : «Ce n’est pas parce qu’une fonctionnalité livrée augmente la satisfaction de l’utilisateur que l’absence de cette même fonctionnalité aurait eu un impact négatif vis à vis de la satisfaction utilisateur».

De ce postulat, le modèle propose de sonder les utilisateurs en mesurant leur satisfaction du produit final dans le cas de la mise à disposition et dans le cas de l’absence de chacune des fonctionnalités.

Je vous laisse faire quelques recherches pour explorer plus en avant ce modèle car dans ce billet, j’aimerais m’attarder sur un point particulier, à savoir le recensement et la livraison des fonctionnalités de base.

Les fonctionnalités de base (basic needs) sont des points cruciaux pour la réussite de votre projet mais celles ci sont fourbes, elles ne sont pas clairement exprimées, on dit qu’elles sont implicites. Obligatoires et implicites, vous voyez ou je veux en venir… 

Dans nos processus de développement agiles, la sollicitation des utilisateurs dans la définition des fonctionnalités est point essentiel. On tente ainsi de remédier à la dérive fonctionnelle des projets dont les spécifications ont été rédigés par des informaticiens. 

Chaque fonctionnalité apportera un service, de la valeur ajoutée à l’utilisateur.

GOOD ENOUGH SOFTWARE

Dans un extrême caricatural, des équipes se laissent ainsi guider par des carnets de produits entièrement rédigé par un utilisateur. Ils vont forcement atteindre le GOOD ENOUGH SOFTWARE, pas de fioritures, pas de gadgets, jusque ce qu’il lui faut. Prétextant une volonté de ne pas vouloir influencer leur gestionnaire de produit, certaines équipes se refusent même à évoquer certaines fonctionnalités qu’elle trouve intéressantes.

Il faut pourtant se rendre à l’évidence, nos gestionnaires de produits ont rarement l’expérience ou les connaissances techniques qui leur permettent de déduire des fonctionnalités de base ou de mesurer l’impact de l’absence de certains points fonctionnels.

Comme toujours la solution réside dans la collaboration entre les membres de l’équipe et son gestionnaire de produit et le modèle de Kano offre ici un cadre de collaboration explicite : 

L’équipe détecte une fonctionnalité basique, décrit la valeur ajoutée.

Le gestionnaire de produit mesure la satisfaction apportée par la livraison ou l’absence de cette fonctionnalité dans le produit final.

La fonctionnalité rentre dans le carnet de produit, ou pas!

C’est simple et ça devrait facilement pouvoir s’intégrer dans une maintenance de carnet (backlog maintenance). 

After a few months of Agile coaching things were starting to look brighter over at FreeFall inc. The Agile process was slowly but surely setting itself into place. Problem was, even though the team was pumping out an all out effort, their capacity to deliver was shameful. Tim had managed to convince FreeFall to hire Andrew, an Agile developer to give more technical coaching to the team.

“Man, I can’t believe this. The build machine is dying on me again !” Shouted Andrew
“Again!? What did you do ? ”
“I’m running the analyzer on our code. The code is so bad that ALL the code analyzers are dying on me”
“You’re running this on a 486 with floppies or what?” Asked Tim.
“If only I was. This machine is state of the art. Cost them a fortune. Man, it really looks like we have a serious case of skunk code here.” said Andrew

“Skunk code ? What’s that?” asked Tim
“Well you know some animals have defense mechanisms more evolved than others. The skunk for one, well, it just plain stinks. Most of it’s defense comes from just plain stinking so bad you won’t dare approach it.”

“I see. How does it relate to code ? ”
“Well you see, code usually starts with the best intentions. Then people introduce small flaws here and there.”
“Ever heard of the broken window principle ?”
“Can’t say I have.” said Tim perplex
“Well it’s a pretty simple theory. You break the window of a building and don’t fix it. For some reason, people who come next will notice it and take less care of the rest of the building. Within a year the place might actually start to fall apart.”

“Interesting, looks like what we have here. How does that relate to my skunk smelling code though ? ”
“Well you see, at some point the code base will contain so many code smells, people will be so repressed by it that nobody will dare touch it to fix it.”
“It thus becomes protected from ever being touched. Just like a skunk.”

“I see. What should we recommend to the client ?”
“Well for one they could stop adding more smells to this mess.”
“Any new code has very little reason to be messy.”
“How could they prevent that ?” – Asked Tim
“Behaviour Driven development or Test Driven Development properly applied should help a lot.”
“Take Cucumber, GreenPepper, xUnit, Rspec or whatever else you can think of and learn how to use it and why.”
“Pair programming should also be mandatory on most if not all coding activities. Try it out. Most people can’t go back to their old ways once they try it”
“Running the analyzers on the code can also give a hand, although it cannot replace the above two practices. Give a look at Sonar and the likes and find out what can help you or not.”

“That’s nice. How about the existing code ?”
“Well that’s gonna have to wait till I get my build machine running properly.”

Nicholas Lemay