Pyxis

Any questions?

Scrum n’imposant rien sur le plan technique, une dérive couramment constatée est un manque de rigueur par rapport aux pratiques d’ingénieries utilisées par les équipes de développement.  Par exemple, l’omission de tests automatisés lors de l’évolution de projets informatiques rend généralement de plus en plus difficile l’atteinte de l’objectif de livraison de qualité “production” au fil des itérations. Martin Fowler a nommé ce phénomène le Scrum Flasque.

Le cours “Professional Scrum Developer” offert à Pyxis vise à contrer ce problème en replaçant l’emphase sur les bonnes pratiques de développement essentielles à l’atteinte des objectifs de Scrum.

Le développement piloté par les tests (TDD)

Nous avons pu mettre en pratique le TDD dans toutes les facettes de l’application, aussi bien pour le développement en tests unitaires qu’en tests clients (bout en bout).  Ceci nous a permis de nous rendre compte qu’il est possible de couvrir la quasi totalité du code par des tests automatisés.  En conséquence, le code obtenu est robuste, explicite et diminue le stress du développeur qui sait que ses changements seront plus faciles à implémenter dans le futur.

Choix technologiques

Certains choix technologiques peuvent rendre difficile, voir impossible l’application des bonnes pratiques et donc l’objectif de Scrum Robuste: la livraison itérative de logiciel de qualité.  Il est par conséquent essentiel de choisir un ensemble d’outils (langages, cadres d’applications, environnements de développement) qui supporte convenablement ces pratiques.  Un exemple parmi tant d’autres, le cas d’utilisation étudié durant la formation utilisait une librairie de rendu visuel légère et testable.  Ceci nous a permis de facilement tester les vues de manières unitaires, ce qui est malheureusement rarement possible…

Elimination des mauvaises odeurs de code

Les mauvaises odeurs de code (aka Code Smells), comme par exemple les duplications ou les classes géantes, sont des causes fréquentes de difficulté à maintenir une base de code et d’une réduction de la vélocité des équipes.  Le cours nous a permis dans le cadre de la pratique du TDD, de veiller à enrayer en continu, par le “refactoring”, ces mauvaises odeurs.

En conclusion, il faut garder à l’esprit que Scrum ne suffit pas en soit à livrer du logiciel de qualité.  Scrum doit nécessairement être entouré de bonnes pratiques de développement, telles que celles enseignées durant la formation pour éviter de sombrer dans la flaccidité.

Allez-y, soyez robustes du Scrum!

Marc-André Thibodeau et Gaël Luisier

This week, the first dry-run of the Professional Scrum Developer for Java course was given at Pyxis. For this occasion, 6 Pyxissians were on-site for 5 training days. Here is a sample of the many things we have learned.

One of the fundamental aspects that was covered was producing a proper “definition of done”(D.O.D).

For most of us, even with our extensive Scrum background, this was actually harder than we had originally expected. The training course consisted of 4 sprints spread over a 4 day period. At the end of each sprint, we had to demonstrate our accomplishments to the Product Owner.

At the end of the fourth sprint, we had to put our software into production.

Like most teams, we started out with a D.O.D that was too ambitious and wasn’t clear enough. For example :

• We had planned for 100% test coverage for all of our tests, yet it was impossible to demonstrate since we were unable to calculate code coverage for view tests. Even worse, there was simply no available tools to calculate our test coverage for these.
• We also had ambiguous elements, like following the code standard, without stating which one.

After achieving first sprint, we did what we thought were the proper modicifications to our done definition. As you can guess, we failed our second sprint. Our done definition was being seriously violated. We committed to too many tasks and did not take the time to truly understand all the work involved in achieving our done definition. We adjusted for the following sprints. Inspect and adapt as always.

However, when came the time to release the product, we realized that our done definition was seriously lacking. We had no confidence in being able to ship our product to the customer. The Product Owner was disappointed in learning this. We then had to modify our done definition to finally be able to deliver. Unfortunately, we had skipped some important steps in the previous sprints which accumulated up until the last day.

Here are few key points that were missing :

• Exploratory testing
• User Experience testing
• Proper production deployment procedure

This really helped us see how important it is to have a true definition of done and to follow it through sprint after aprint. After all, we had accumulated debts after only 4 days of sprinting. Imagine if we had been sprinting for weeks !

-Nicolas Henin and Nicholas Lemay

Now that the vacations are over and that the 2010 Agile conference has come and gone, Team Urban Turtle is back to work, cooking up another promising release 3.4.

With the release of the Scrum template from Microsoft came a Removed state, making it necessary to propose a recycle bin feature to our users. The next version of Urban Turtle will therefore include a recycle bin icon at the top of the iterations and areas panel. Users will be able to drag and drop items onto it to set the state of selected items to a configured deleted state. It will also be possible to view deleted work items by clicking on the icon.

The team is also working on a select / unselect all option to flag or unflag all iterations and areas as favorites in one click.

We have several more interesting features in our backlog, some of them coming from customers who voiced their opinions and proposed suggestions on our community-powered support site. Thank you all for your support and keep those suggestions coming!

} Dom

Tweet This Post

I went to my first Agile Conference!  I guess I’m always a bit uneasy when I’m surrounded by people who more or less think the same way I do. On the other hand, it feels great! It’s a stark contrast from what I’m used to – you know, being surrounded by Architects, DBAs, PMOs and project managers who a waiting in the wings to save the day when this “Scrum thing” fails.

So for five days, I dove in the pleasant warmth of my fellow agilists and shared ideas, laughs and a few drinks.  Attending the wide variety of sessions was my preferred activity and a great opportunity to listen, participate and learn.

Enough chit chat, let’s get right into it…

My first session was “Leader’s Workshop: Making Change Happen and Making it Stick” with Mary Poppendieck.  I won’t go into details so here are a few points…

Mary states that to encourage change, one needs to provide:

1-      The proper kind of motivation

2-       A clear direction

3-      A supportive environment

So what motivates people?

Mary references books such as Switch, Drive and that great video by RSAnimate

A very interesting point is to manage employees as if they were volunteers.  With money being out of the equation, what needs to put in place and maintained to keep motivation at a high level?  What  keeps a volunteer motivated?

1. A  clear purpose
2. Structure and guidance
3. Successful project
4. Ownership
5. Autonomy
6. Bragging rights
7. Mastery
8. Constructive dissonance

What I take back from this session

You can throw all the cash you want at your problems and they still won’t go away.  If you want successful projects, hire smart people, offer them a clear direction, a few rules, and get out of their way.  Smart people will find a way to make it work.

Scrum est un outil de visibilité. On ne le dira jamais assez. Et sans doute faut-il trouver des formulations alternatives pour pouvoir être compris par des gens différents, avec des cultures et des expériences qui modifient la façon dont ils interprètent cette phrase. Et parfois, un dessin suffit, un graphique suffit.

Aujourd’hui j’ai passé une bonne heure avec un gestionnaire de projet traditionnel qui souhaitait savoir comment faire un suivi budgétaire “avec Scrum”, selon sa formulation. Nous nous concentrons donc sur cette idée de “suivi budgétaire”. Une chance pour moi, il est très ouvert et me dit simplement “comment fais-tu toi ?”. Magnifique non ?

Simple : la clef dans son cas c’est la définition de Done. En effet, nous plaçons un curseur dans la définition de Done. Ce curseur sépare ce que livre l’équipe à chaque itération et le reste des activités qu’il faudra faire pour avoir un Working Software, soit un logiciel en production utilisé par quelqu’un.

D’un seul coup, la définition de Done devient un outil concret pour lui. Voici ci-dessous une version simplifiée de ce à quoi nous sommes arrivés. Il lui apparaît très naturellement que les activités concrètes de mise en production sont liées au Done et que le voir exprimé ainsi lui fait réaliser tous les éléments que l’ensemble de l’équipe avait jusque là oublié.

Combinés aux Release burndown chart et au Value burnup chart, ce budget plan complète la vision 360° qu’il a du nouveau jeu dans lequel il joue.

Selon les prévisions que vous ferrez, vous pourrez utilisez ces graphiques pour amener une discussion autour de la vision partagée que vous avez des prochaines itérations. Par exemple aujourd’hui, les graphiques étaient sensiblement semblables à ceux-ci et la réflexion principale de mon interlocuteur a été de dire que le budget serait consommé avant que la courbe de valeur ait commencée à s’infléchir, ce qui lui a donné envie de trouver plus de budget.

Attention néanmoins à ce que l’on fait dire aux chiffres. Même dans ce cas d’un petit nombre d’itération, la courbe de valeur qui ne décroit pas pourrait nous mettre la puce à l’oreille et nous parler de la piètre qualité des estimations de valeur. Il se pourrait que l’on ait affaire à des priorités et non à des estimations relatives de valeur ajoutée. Mais ceci est une autre histoire

It dawned on me recently that organizations are lead and managed by accountants. Accountants come in many shapes and forms and not every accountant wears brown socks.

I suspect you will disagree with my statement arguing that your CEO isn’t a former accountant or that your CTO didn’t even take a single accounting class in his life and I would agree with you. Not all accountants carry a pocket size calculator.

I personally don’t have many complaints about accounting itself, after all there is value in knowing how much money enters your coffers and how much you had to spend to generate the associated revenue. That makes perfect sense to me. Where I have a problem is when common sense leaves the building to make place for accountant-based logic and the need to book everything against the right account and the use of money within certain time intervals.

Confused? Let me explain.

Let’s take project management [Ah, now you are starting to see a link between accountants and Agile projects]. In many of the organizations I had the pleasure to work with, compliance to project plans was more important than delivering real value to customers. Nobody asked if it made sense to add new features or change the sequence of activities in an attempt to deliver business value to customers faster. People are concerned with compliance to the plan. And where does this need for compliance come from you ask? Accountants.

Before the debit-credit masters come running after me with their red pen, I will confess I used to be one of them (sorry!). I understand the mindset, their perspective of the world and most of all, the need to put things in neatly defined categories – some can be amortized while others can’t – but I digress.

The project timelines are derived from the accounting cycles – the money is allocated for a certain budgeting period instead of true market needs. The phasing and allocation of the resources is driven by the departmental allocated budgets. The profile of the resources assigned to a project is driven by who has the money as opposed to who has the skill set.

Does any of this make sense in a context of business excellence? That’s one of the reasons why I like Scrum with its focus on delivering the highest business value sooner. Scrum isn’t perfect, I know but it forces people to make decision based on business value, not accounting rules.

Scrum is also great a giving visibility the what is really going on within a project as opposed to estimated project completion for cost computation. In heuristic tasks such as software development is it really critical to know that task ABC costed $357? Chances are, you are unlikely to do anything useful with that information. Why wouldn’t you rather determine the cost of an iteration (or a sprint) so you can compare it to the business value delivered. As I stated earlier, there is value in accounting but when everybody starts to behave like an accountant, it is a sure sign that common sense is gone and that the organization is ripe for an Agile makeover.

You might be interested in these related posts:

1. You are not doing SCRUM if you don't have a ScrumMaster
2. Who benefits from the traditional consulting approach?
3. Top People in the Agile Business Intelligence and Agile Data Warehousing World

Two weeks ago, Urban Turtle announced its brand new partnership program. The partners are a select group of consulting firms who mastered the ins and outs of Scrum and are friends of the “Turtle”.

To provide more details on each of our partners, I follow the series of blog posts with the firm Readify.

Founded in 1999, Readify has established itself as certified experts on the .NET Application Development Platform within Australia.  They have office in Melbourne and Sydney and provide expertise around system architecture, application lifecycle management and user experience design using the latest Microsoft platform technologies.

In 2009 Readify introduced its projects offering known as DevPods. DevPods are based on a team-orientated project delivery capability which combines a high performance development team using an agile methodology (specifically Scrum) and focuses on close customer involvement to successfully deliver projects.

Readify is one of Australia’s young and savvy IT business success stories. This year they received the Australia’s 2010 ‘Best Places to Work’ award.

Mitch Denny, Chief Technology Officer at Readify explains why they appreciate Urban Turtle:

“If you plan to use Scrum with TFS, we recommend Urban Turtle instead of Excel-based planning workbooks”

You can learn about their offerings relating to Application Lifecycle Management (ALM) here. Do not hesitate to consult their website.

Tweet This Post

The Urban Turtle is at Agile 2010 with its fourth release in four months since the Visual Studio 2010 release in April.

During the opening night, the turtle spent some time flying!

We are also kicking off a fun contest to win an Xbox with the Kinect module.

If you are in Orlando, come by the booth to get a sticker, stick it on an unusual place and upload it to the contest page. If you are not in Orlando you can also participate. Download a sticker here. Do not hesitate to vote for the photo you prefer at Urban Turtle fan page.

Tweet This Post

Some members of the Urban Turtle team (Francois, Dominic and Mario) are at the Agile 2010 conference this week.  If you attend the conference, please come see us Wednesday or Thursday at booth 128 in the exhibit area.  We will be more than happy to discuss and to demonstrate the latest cool features of Urban Turtle such as the real-time burndown chart.

Tweet This Post