Suite au concours Un déjeuner avec Ken Schwaber, nous sommes heureux d’annoncer les 5 personnes qui participeront à ce déjeuner.
- Anthony Dahane
- Christine Lambert
- Bilal Nasar
- Steffan Surdek
- Alfonso Marin
Nous tenons à remercier tous les gens qui ont prit le temps de nous écrire leurs motivations.
Félicitations aux gagnants!
L’équipe commence à être efficace durant la planification de l’itération, j’ai moins à intervenir! En tant que tel, je trouve que c’est une bonne chose. Ca me fait penser que mes interventions précédentes ont porté fruit et que l’équipe devient indépendante. Du moins pour cette cérémonie…
L’efficacité de l’équipe se propage aux autres cérémonies. Cette séance se déroule avec très peu d’interventions de ma part. Les membres de l’équipe discutent entre eux du contenu des stories, posent des questions au PO et s’entendent généralement, en 2 tours de planning poker, sur le pointage à mettre sur une carte. On pourrait penser que s’est une équipe formée depuis longtemps et qu’ils sont tous habitué de travailler ensemble.
Il reste un point qui risque de devenir problématique, le backlog n’est pas très garni. Ce qui fait qu’il n’y a pas de stories, ou même d’epics, d’avance pour les prochaines itérations. L’engagement de l’équipe pour la prochaine itération risque d’être limité par le contenu du backlog. Il y a de la sensibilisation à faire auprès du PO. À suivre…
Une autre review qui va bien! Cette fois, par contre, il n’y a que le patron du PO qui est présent, l’utilisateur n’est pas là. Ca n’empêche pas à l’équipe de recueillir tous les points auxquels elle était engagée. La patron pose quelques questions et semble satisfait. C’est une review express qui se déroule rapidement, mais ca n’empêche pas que tout le monde est content du résultat.
Les membres de l’équipe s’attendaient à la formule des 2 sprints précédents; identifier les points forts et les points à améliorer. Un membre me demande en blague « C’est maintenant qu’on chiale ? ». Je lui réponds avec sourire que non, ce n’est pas aujourd’hui! J’ai autre chose de prévu. J’ai constaté que les membres de l’équipe travaillent beaucoup selon leurs spécialités respectives. Je pense que ca a un impact sur le déroulement des itérations, certains membres sont un goulot au début de l’itération et d’autres vers la fin. C’est un signe! Je questionne l’équipe sur le potentiel de travail de façon multidisciplinaire. Ils semblent s’opposer à ma proposition. Je comprends par leur réaction qu’ils ne sont pas contre, c’est qu’ils ne comprennent pas la même chose que moi. Ils entendent que tous les membres de l’équipe atteignent un même niveau d’expertise dans tous les domaines et que chacun peu faire le même travail au même niveau d’efficacité et de qualité. Ouf, je comprends qu’ils s’opposent. Ce que j’entends est plutôt que chacun peut faire du travail qui relève d’une autre discipline, ceci pour s’assurer que l’itération avance bien lorsque qu’un spécialiste n’est pas disponible (avec la saison des vacances qui approchent, ca va rapidement devenir une réalité!).
L’équipe me trouve dur avec mes questions, ils suivent quand même bien l’exercice de rétro. Il faut un peu d’encouragements de ma part, mais les équipiers finissent pas adopter l’idée de travailler en paire interdisciplinaire pour mieux partager la connaissance. On verra à la prochaine rétro comment ils ont apprécié l’expérience.
Note that the ‘Scrum Team’ refers to the Product Owner, the ScrumMaster and the Team. The Team consists of developers with all the skills to turn the Product Owner’s requirements into a potentially releasable piece of the product by the end of the Sprint.Last week I was discussing with Mathieu and he started to talk to me about a friend who is now Product Owner (previously project manager) on a Scrum project. This person wants to make sure he is doing a good job and wants to continuously improve. I said, this is really awesome! Mathieu, then says that his friend asked him the specific question: if I want to track the time I am investing in creating user stories and prioritizing the product backlog, which work item type and fields should I use to enter actual time spent if I am using the new Scrum process template from Microsoft. My reaction is … Interesting, why don’t you ask your friend how he is going to use this data to effectively improve as a Product Owner? If the Team is producing software that the users consider high value at an ever increasing and sustainable pace, don’t you think that those are great indications that the Scrum Team is doing good work? I believe those are much more interesting metrics to track than the actual effort he is putting in creating and prioritizing the product backlog. Mathieu: Sure, I will suggest him that but I think he also wants to track cost.
Ha! This is getting even more interesting now. Because it leads to the questions of time and cost tracking in Scrum; a question I often get in my scrum classes, especially from participants working in large corporations.
When I started teaching Scrum in 2004, I used to answer in my classes that time tracking is not part of Scrum but if you want to track actuals on sprint backlog items for administrative purposes, you can go ahead.
Observing Scrum Teams doing time tracking on sprint backlog items invariably leads them to questions like:
Cheers,
~françois 
Vince came back home today only to be greeted by firetrucks and the local fire marshal. He was quickly relieved to learn that his brand new condo was not on fire. Unfortunately, for his neighbor Harry, the fire marshal was there expelling him from his own home until he got his mess together.
When Vince found Harry he was in a terrible state of mind. You see, 78 years old Harry had been collecting all the newspapers he could get his hands on ever since his wife had died at 52. 26 years of newspaper stacked up against the walls was too much and a suspicious neighbor made a phone call to the local fire department before Harry would turn his home into the biggest BBQ the city had ever seen. Harry had just lost his entire collection.
All this turmoil shook up Vince inside. When he came back to work Monday, he started thinking about all the mess that was accumulating in his own project.
He made the following list of all that was accumulating around him :
- The backlog had tons of duplicate bugs
- A ton of stories were planned for but not estimated
- The main domain classes of the application were starting to have more responsibilities than the companies C.E.O.
- Some of the controllers were getting bloated
- The code produced by the interns had not been peer reviewed for weeks
- The users documentation was dated by two revisions
….
Vince then went to see his Product Owner and told him about the issue. He was dumbfounded to learn this at first, but after a long discussion, he brought the team together, talked about what was most urgent and how much dealing with each issue would cost.
He then added the elements with the best return on the investment at the top of the backlog and chipped in where he could to help the team address these issues. Within a few months, the situation was very promising and the team was now bringing up issues all the time without the need for them to accumulate.
A year later, most of his fellow Product Owners and their teams were engulfed in crap that had accumulated sprint after sprint. Always planning to fix it later,they never ever did.
Meanwhile this team just glided through the problems at a steady pace and it seemed nothing could stop them in their tracks. For the team members, the project just felt like a train anybody would love to embark on. Their biggest pride, was that it was their own.
-Nicholas Lemay
pip install virtualenv
python virtualenv.py path/to/my_virtual_env
path/to/my_virtual_env/bin/activate
And you'll be using a brand new environment that you can throw away without impacting your other python environment.... Awesome! For more go to virtualenv's page : http://pypi.python.org/pypi/virtualenv
Now if only we do this in ruby... oh wait, it exists : http://github.com/nkryptic/sandbox
I'll try it and see how it goes !
RVM is the way to go for ruby.. I'll post something later on that
<atlassian-plugin key="jira.plugin.minyaa.core" name="Minyaa JIRA Plugin Core" pluginsVersion="1">
<module key="ModuleKey" name="ModuleName" ...>
<resource type="i18n" name="i18n" location="com.myplugin.jira.MyClass" />
</module>
<module key="OtherModuleKey" name="OtherModuleName" ...>
<resource type="i18n" name="i18n" location="com.myplugin.jira.MySecondClass" />
</module>
</atlassian-plugin>
For some modules, the I18n resources were declared using 2 files, in order to reuse existing i18n resource files without having to duplicate translations.
<atlassian-plugin key="jira.plugin.minyaa.core" name="Minyaa JIRA Plugin Core" pluginsVersion="1"> <module key="ModuleKey" name="ModuleName" ...> ... <resource type="i18n" name="i18n" location="com.myplugin.jira.MyClass" /> <resource type="i18n" name="i18n.Other" location="com.myplugin.jira.MyOtherClass" /> ... </module> ... </atlassian-plugin>Without more detailed documentation, when Kaamelot (Minyaa) required to extend existing i18n properties, the technic used was to append a new I18n Location in the extended WebWork Action, by accessing I18nBean object. You can imagine that with 120 modules (components, webwork actions, Report, Portlet, Service, Issue Tab Panel, Project Tab Panel, …), extending i18n properties may be a pleasure … With JIRA 4.0, the Gadgets arrived with new constraints … Minyaa portlets have been migrated into real Gadget (Atlassian Framework 2) only for JIRA 4.1.x. As Minyaa performs many extensions in JIRA components, it was not possible to migrate Minyaa plugins in OSGi Plugin. Only Portlets have been migrated into Gadget in separate Plugin (jira-plugin-minyaa-xxx-gadgets-4.x.x-x.x.jar). Gadgets, as any graphical item, require I18n Properties ! How does it work ? Following Atlassian documentation, it only requires to declare in gadget xml file the supportedLocales macro with a key filter for I18n key. A new component (the I18nResolver) is able to load all I18n resources of all plugins and extend the Gadget definition using the key filter. Ok, lets go ! For Minyaa Core, my first portlet to migrate was Minyaa Fragment Portlet …
<?xml version="1.0" encoding="UTF-8" ?>
<Module>
<ModulePrefs ...>
#supportedLocales("gadget.common,portlet.fragments")
</ModulePrefs>
...
</Module>
<atlassian-plugin key="jira.plugin.minyaa.core" name="Minyaa JIRA Plugin Core" pluginsVersion="1"> <module key="ModuleKey" name="ModuleName" ...> ... <resource type="i18n" name="i18n" location="com.myplugin.jira.MyClass" /> <resource type="i18n" name="i18nOther" location="com.myplugin.jira.MyOtherClass" /> ... </module> <module key="OtherModuleKey" name="OtherModuleName" ...> ... <resource type="i18n" name="i18n" location="com.myplugin.jira.MySecondClass" /> ... </module> ... </atlassian-plugin>Since the migration, each i18n resource has to be unique (per i18n resource file) as follows :
<atlassian-plugin key="jira.plugin.minyaa.core" name="Minyaa JIRA Plugin Core" pluginsVersion="1"> <module key="ModuleKey" name="ModuleName" ...> ... <resource type="i18n" name="i18n" location="com.myplugin.jira.MyClass" /> <resource type="i18n" name="i18nOther" location="com.myplugin.jira.MyOtherClass" /> ... </module> <module key="OtherModuleKey" name="OtherModuleName" ...> ... <resource type="i18n" name="i18nSecond" location="com.myplugin.jira.MySecondClass" /> ... </module> ... </atlassian-plugin>I18n translation is important for all plugins, but you need to be aware that for large and old plugins, this is not a small work !
manage.py startapp myapp
It will create a Python package called myapp, which is great. However, it gives you a models.py, tests.py and views.py (a View in Django is the equivalent of a controller in Rails). If you follow the tutorial from Django's website as the coding standard, you'll end up with all your models from your app in a single file, all your views in single file, etc.
While some pythonistas will argue that if you split your apps properly the size of the models.py (or views.py) will never be a problem, I tend to believe along with a bunch of people that for the sake of readability and maintainability, each model, each controller and each test class should be in its own file. If the language allows multiple class in a file, it doesn't mean you should do it... I mean we don't write application on a single line even though the compiler/interpreter will accept it 'cause that's just retarded...
If you intend to split your models and views, you'll be in for a surprise. Django allows you to do this, but not without extra work (yes, it takes extra work to do things right when a framework steers you in the wrong direction).
You'll want to create a models package along with its __init__.py. In it, you'll need to import EACH AND EVERY model that you'll create. Let's say I have a class called Food in a food.py file, I'll have to write this in my models __init__.py file
from food import Food
Agreed, it's not much work, but a framework should not require you to write more code to separate your business entities.
In December 09, a colleague of ours was a tad bit envious of a great initiative leaded by Laurent Cobos.Laurent, through a collaborative effort with the Pyxis developer community created the Pyxis Developer’s Charter.
Seeing the rallying effect of the Developer’s Charter, we attempted to launch a similar initiative for Agile Coaches, but we had limited success. Coaches being in high demand these days, we had less time to invest in developing a strong and honest charter that other coaches could easily identify to.
We did however identify some conditions of success:
-The language must be business compatible
-Must show that the coach is accountable to the client
-Must show that our client is equally accountable to the coach
-Can included specific practices
-What else?
And through our internal wiki and a couple of meetings, we came up with this:
As an Agile Coach, I commit to the team and its organization to…
What would you add, change or simply remove?
What makes uncomfortable?
Which statement makes you stand-up and cheer?!
What would be your preferred format?
Would you sign this Charter?
J’apprends que le patron du PO a vraiment apprécié de participer à la review de la semaine dernière. Il veut être invité encore à la fin du sprint présent. C’est une bonne nouvelle!
Pour débuter, j’explique à l’équipe qu’à la dernière itération ils ont réussi à réaliser 4 points de story. En principe, ils devraient aussi être capable de réaliser 4 points à cette itération. À la review de l’itération 1, une story a été refusée par le PO. Je me souviens qu’ils étaient convaincus qu’il ne restait que peu de temps à faire pour la compléter. Alors, l’équipe pourrait s’engager à faire 6 points. Aahhhh! Soulagement collectif. Ils n’avaient pas bien compris qu’ils pouvaient s’engager à plus. L’équipe regarde le backlog, est confiante et s’engage à réaliser 10 points. J’aime ça les équipes optimistes!!
Avant de débuter la séance, nous avons une petite discussion à propos d’une situation « particulière ». Le patron du PO ne peut pas être présent pour la review et demande à l’équipe de faire la présentation à un autre moment pour qu’il puisse y assister. Après discussion au sein de l’équipe, les membres proposent d’échanger les séances de planning et de review. Ai-je bien compris ? L’équipe veut s’engager sur le prochain sprint sans connaître le résultat du sprint actuel ? Il semble que j’avais bien compris… L’équipe justifie qu’elle se sent en confiance de réussir l’engagement et qu’il n’y aura pas de problème. Même si l’équipe ne réussi pas, les membres considèrent l’impact mineur. J’ai fait part de mes réserves, l’équipe connait les conséquences potentielles. Je leur laisse maintenant la décision.
Le backlog n’est pas très garni, ça a comme conséquence que peu d’items sont estimés. Nous avons prévu deux séances de backlog maintenance pour cette itération, pour permettre au PO de rédiger d’autres stories. Pour la séance de ce matin, l’équipe a réussi à estimer 4 stories. Ça ne semble pas beaucoup, mais les discussions entourant les stories étaient intéressantes. Elles ont permis de faire diviser une story en deux, afin de réduire la complexité, de clarifier des éléments et faire ressortir des points que le PO doit éclaircir pour la prochaine séance.
Comme au sprint 1, des intervenants ont assisté à la review. Il y a 3 stories à présenter et le résultat d’un spike. Le PO a pris contrôle du clavier dès le début de la séance. Première story à démontrer; le PO commence à faire le tour des écrans pour valider l’information transmises. Il ressort tranquillement qu’il n’est pas prêt pour la review, il cherche un peu quelles données utiliser et où sont certaines informations. Je prends note que je devrai un peu mieux accompagner le PO pour qu’il se prépare pour la review. Les membres de l’équipe semblent aussi l’avoir remarqué. Je ne serai pas seul à en parler au PO…
Pour cette deuxième rétro je préfère rester au niveau des processus. Alors je garde une formule assez traditionnelle de faire ressortir les points forts et points à améliorer. J’oriente par contre la discussion autour des cérémonies de Scrum; planning, backlog maintenance, review, retro et le déroulement général des itérations. Des bons points ressortent sur les différentes cérémonies. À l’opposé, l’équipe trouve que la mêlée quotidienne est inefficace; les membres de l’équipe communiquent beaucoup et se synchronisent près du tableau de tâches à chaque matin avant l’heure de la mêlée, alors ils ont le sentiment de se répéter. Pourtant, à quelques reprises durant la mêlée quotidienne, d’après la réaction de certains autres membres face à la réponse à « Qu’as-tu accompli hier? », j’ai senti que de l’information nouvelle circulait dans le mêlée. Elle n’est peut-être pas efficace, mais elle semble utile!
Scale, speed, and practicality are always the coded arguments for keeping the existing system in place.Scrum is all about changing the existing system. This is why the ScrumMaster primary responsibility is to ensure the Scrum process is followed. He or she uses Scrum as a tool to ask powerful questions to spark off change. The ScrumMaster job is to change the conversation. The ScrumMaster is initiator, facilitator and leader of real discussions. This is a leadership role about creating commitment and accountability, which are the building blocks of self-organization.
To make a difference we must start by naming the way things are, use powerful questions as a tool, and listen, rather than advocate or defend.ScrumMasters, take the time to master the art of orchestrating conversations, for this is what your job is about.