septembre 2010Monthly :

in Agile, Développement logiciel

The Interface is the Program, and it ain’t Agile

I came across this rather old article on Usability from Jim Coplien (One of the guys behind Data Context Interaction). It is definitely worth reading, and here is a striking quote from it :

My points were that:

1. Test-driven development without architecture emphasizes a procedural architecture rather than the kind of good object-oriented architecture than supports the direct manipulation metaphor, which in turn is one foundation of a good user interface;

and 2. That the Agile Manifesto leaves usability at the side of the road

in Agile

RELEASE 3.4 – 5 Releases in 5 Months

The turtle ride continues, 5 releases in 5 months !

Release 3.0 : Support for Visual Studio Team System 2010

Release 3.1 : Support for Areas, Ranking across multiple pages, Reduced installation footprint

Release 3.2 : Support for Visual Studio Scrum 1.0, Favorite iterations and areas

Release 3.3 : Real-time Hour Burndown Chart with support for TFS Basic, Filtering based on Work Item Types

And we’re now introducing the Recycle Bin in Release 3.4.

In this release, the team is proud to present a new feature to help Scrum teams focus on the right things. The new recycle bin will allow teams to clean their backlog and concentrate on the more important stories and tasks.

The team also made it possible to quickly flag and unflag all iterations and areas as favorites. Various bug fixes and optimizations have also found their way into this release. For instance, the stack rank or backlog priority field does not get updated anymore when accessing the planning or task board. This should improve performance when displaying pages and reduce the number of meaningless entries found in work item history.

Again thanks for your support and be ready for the next release… 6th one in 6 months, maybe? :)

in Vie @ Pyxis

Let’s make Job Offers not suck

As you may have realized by reading my previous posts, when it comes to managing software projects, my ideas are largely inspired from the Open Source movement, especially if we are talking of big, distributed projects involving many developers. When it comes to managing companies, my inspiration comes from incubators.

Now, if we are talking of hiring developers, I seem to forge my opinion based on what happens in the startup world.

Here are a few interesting pointers on hiring developers that I find inspiring :

And of course, salary is an important aspect of hiring. Did you know that the old proverb “money does not make happiness” has been proven wrong by researchers ?

in Agile

Removing Agile Team Capacity And Velocity Confusion

A long time ago, we introduced a Velocity feature to ProjectCards. We got it wrong.  And since we figured a lot of other people get it wrong, here’s a small article on how to handle your teams’ capacity and your teams’ velocity. This is our mea culpa.

First let’s define velocity. Your team’s velocity is, at the simplest, the rate at which the team has delivered product backlog items in past iterations. This is thus tangible, historical data.

Your team’s future capacity however, is uncertain. People get sick. New people get inserted into your team or leave it and it disrupts your team’s cohesiveness.  Your team’s capacity for a given future sprint can only be speculated.

A common mistake and one we made ourselves is to mix capacity and velocity. How often have we heard “What is our teams velocity for this sprint ?”. This is wrong. Our velocity is established by our past actions.

When doing your sprint planning for the upcoming iteration, we should focus on capacity. What is our capacity to deliver this sprint ? Is anybody taking days off ? Is anybody joining or leaving the team ? Is anybody on vacation ? After these questions are answered, you can then use the velocity as one of the many parameters to ESTIMATE your capacity to deliver for the next sprint. Remember that this will only be an estimate.

With that in mind, as of release 2.4.0 we will be introducing a capacity feature. This way, you will be able to manually set your team’s predicted capacity based on your estimates. You will also be able to enter a comment every time you change your team’s predicted capacity. This way, you can track fluctuations in you capacity to deliver based on facts( sickness, vacations, arrivals and departures). Your capacity change history will be available all the time.

-Nicholas Lemay

in Agile, Management

Are we coaches or do we offer coaching?

 

 

As I was heading back home, I wondered – is coaching something we do or the way we are? So once I got home, I looked up the definition for both words (coach & coaching) and came across Visual Thesaurus (image below).

The reason I was wondering is that when I meet people who “do coaching”, they always say “I’m a coach”. I’m not actually disputing that they are (or aren’t) coaches, it’s just that I wonder if they have assimilated the coaching role so much as to BECOME coaches. Maybe it’s simply like someone who defines himself as being an accountant, an engineer or a clown when in reality it is because their day-job is accounting, engineering or clowning.

This leads me to wonder, if accountants stop doing accounting after 5 pm, does it mean coaches stop coaching after work hours? It seems to me, based on the many coaches I personally know that very few actually stop coaching – that’s almost a way of being – coaching the kids, sometime the spouse, some of the friends and so on.

Should we call ourselves coaches only when we are on duty or is there a better name to describe bipeds who provide coaching to people around them?

Personally, I have decided a while back that I do not define myself as a coach. Coaching is simply a tool for me – a very effective one, I would add – that I use to help people accomplish their objectives.

Share

You might be interested in these related posts:

  1. The world would be a better place without accountants
  2. On my way to coaching certification
  3. What Is Coaching? And Other Relevant Questions
in Agile, Développement logiciel, Nouvelles et événements

Le développement Agile selon Pyxis dans le magazine Programmez

Deux Pyxissiens sont publiés ce mois-ci dans le magazine Programmez, lisez-les! :

Le développeur au centre de l’Agilité par Mathieu Szablowski
Entre un contexte économique de plus en plus contraignant, imposant des délais plus courts avec toujours plus d’exigences , et une course à l’innovation introduisant de plus en plus vite de nouvelles technologies (mobilité, cloud computing, Green IT, …), les équipes de développement adoptent de plus en plus des pratiques Agiles dont les plus connues sont celles issues de XP et Scrum.

Le développement Agile Java : vive Scrum ! par Éric Mignot
Le développement Agile vise à offrir une alternative aux cycles de développement traditionnels dits « en cascade » ou « en V ». Les principes en sont assez simples, mais leur mise en place représente souvent de véritables défis pour les équipes.

in Nouvelles et événements

Retro

In September 2009, I decided that for the next year, I would concentrate on three goals:

  • Reading (12 books)
  • Blogging (40 posts)
  • Coding (4 projects)

What did I learn about setting objectives? What do I need to improve? These questions will be answered in a few moments… and if you care you might even hear how I fared.

The results (drum roll)

Overall I’m happy with what I accomplished. I read more books than what I planned (16 books that I remember plus tons of blogs), and I blogged as planned (*exactly* as planned if I include this post and another I posted only on the Pyxis blog). However I wanted to code a lot more than I did. I’m still pleased with the small projects that I worked on but I envisioned something bigger. I mostly did prototypes, katas and experimentation with Rails. No big projects, nothing on github (yet).

I did learn a lot about setting objectives for the future:

Lesson #1 : Never write about goals other people set for you

My wife convinced me to put something about losing a bit of weight. Fail. It wasn’t my goal, it should never have made the list

Lesson # 2 : Keep your objectives focused

For me, three goals was one too much. Very early on I could see that it was easier for me to write blogs or read books than it was to code – books were feeding me for blogs, blogs were giving me questions to read about. Coding felt lonely. Next time I’m going to go with two goals max to start with – and coding is going to be one of them.

Lesson # 3 : Do it gradually

Setting goals is definitely something that allowed me to improve. When I did it in the past, I usually started with a big goal in mind. I suggest you try it with small objectives at first and grow more ambitious as you go. Get started, have habits in place. Then think big.

Lesson #4 : Think about your next goals in advance

Especially if you plan on blogging about it on time. Shame on me.

I have a few ideas but I’m not fixed yet, so I’ll set a few very short term goals for now.