Yoan Blanc’s weblog

Another lost swiss guy

March 2009

Working team

Yoan BlancMon 30 March 2009, , , ,

Here is something I wrote at my previous workplace and that I think might be worth sharing nowadays.

The team I joined last automn grew quite a bit during the last year and continues to grow; is spread across three office and work on a lot of different things at the same time. At some point of some kind of reorganization I tried to give my point of view that has been influenced a lot by my previous work experiences and the books or articles I’ve read recently.

Scrum (or agile) people like to call the stage before that agile methodology saved their company, the chaos. It’s often described as world full of cow-boys and you can even hear an Egnio Moriconne theme in the background. There is no such things in reality, I haven’t seen them. It’s usually a place with a lot of individual skills, promising projects, great ideas and where people are working hard. But it misses the corner stone, a common understandings of “what are we doing?” or I prefer “To where are we heading?”.

Without that, it is so easy to see misunderstandings coming in; people redoing things over and over, solving the same old issues; people no able to say no because they have the feeling to accept something that is small or maybe because they aren’t the correct person to take that decision.

It often misses some glue between people, between things. A glue that helps keeping workers together focusing on the same common goals and having a lot of fun at it. The glue isn’t any kind of bureaucracy. At least, it shouldn’t be, I don’t see how it can work better with more paper work, guidelines to follow. It can be done with more visibility. The golden rule of UCD is make things visible.

More visibility can provide easy answer to that kind of questions: Who’s working on that project? When do we expect a new release, that particular new feature or this bug fix? Is the team happy? Is the customer happy? …

Before diving into the main dish, I tried to give a definition to some terms:

  • a product is the result of things you do, a product can be in development (not yet release), live (release and used with bug fixing and/or active development) or dead (removed or deprecated or not officially supported.
  • a project is something in the time; it starts, lives and ends. The goal of a project is to create, improve, adapt, etc. a set of products.
  • a product owner is responsible for a product, to define it, to gather the feedbacks and to define the life of a product. He deals directly with the customer and no one else does.
  • a project manager is responsible for a project, focusing on what has to be delivered, what needs to be done in priority and that the project member can work, communicate together efficiently.
  • a team manager is responsible for a team, focusing on the people, what they need to work correctly, to make sure they are happy in their project(s) and that they share the same knowledge.

From that, I tried to explain what I wanted to see, what I still would like to see in a future working environment.

Knowing yourself

The bigger you are the more likely you’ll need a products dashboard. Such dashboard can have information about the state of the products. Is it alive? Who’s responsible for it? Who’s working on it? When do we expect a future release? Any major known bugs? List everything, the future products like the old and dead ones.

You can also create a list of the teams, which is a view based on the people and not on the products.

Transparence matters.

Knowing your peers

Never work alone! The golden rule of agile is to be together as much as you can. It doesn’t make any sense to do team building sessions if the people aren’t working together in a daily basis.

Being transparent, communicate a lot about what you’re doing, how you’re doing it. Trying to solve problems together is a path to follow. Asking for help shouldn’t mean that you’re not responsible for the solution taken. You have the final cut.

People matters.

You’re the expert

As a developer/qa/designer/whatever, you’re the expert in your field and are responsible for doing it right. You should expect to be respected and trusted in the way you are working.

If you don’t feel that you’re good enough, ask your team manager about it and he has to get you to that level.

Quality matters.

Being involved

You should as possible be involved from the beginning of a project. Everyone that will work on a particular project one day as to be part of every communication, meeting, etc. that happen regarding that project. Take the time to do some retrospective, to get to know how things are doing for everyone.

Communication matters.

Being happy

Everything that goes well, or bad as to be said, to be heard, to be written down. Good or bad news are just news and every news are important to the team to get better as a team and for the individuals too.

You matters.

I don’t want to show rules or a way of doing things, the only goal is to show different facets, a maybe different point of view. To look at the small, the individual to see if he’s happy; to look at a project and seeing that things are doing well and to look at them from the outside where you can see similarities, obvious mistakes, redundancies. I don’t believe I can do the three of those at the same time, but it’s good to stop the clock for 5 minutes and start inspecting our environment.

The perfection doesn’t exist because there is always something to improve, don’t focus on the perfection but take that little something you can improve, and improve it. It leads to the perfection.

Voici un plutôt long essai, texte initialement écrit alors que je travaillais encore en terres Norvégiennes. L’entreprise étant jeune, grandissante; l’équipe dans laquelle je me trouvais souffrait des mêmes symptômes réjouissant d’un point de vue purement capitaliste. Cette dernière a atteint les limites dans ce qu’elle est capable de réaliser tant concrètement que moralement.

Dans les discussions, riches en vives argumentations, qui eurent lieu autour d’un comment pouvons-nous améliorer les choses, j’ai tenté d’amener les choses qui m’ont plûes dans mes expériences passées et dans ce dont j’ai pu m’instruire çà et là au détour d’un bouquin ou d’articles. Venant d’Hortis et de leurs mardi gras, c’est évidemment tout l’environnement dit agile qui a été abordé. J’ai pu le mettre en pratique lors de mon séjour parisien. Et à force d’entendre « allez, maintenant, assez causé, “getting real” maintenant » je me suis résolu à en faire la lecture donc il y a eu un peu de cela aussi. Puis plus récemment, c’est le monde du lean qui a le vent en poupe. In fine, c’est tout de même la question « est-ce que j’ai du plaisir à faire ceci de cette manière là ou non » qui l’emporte sur toutes méthodologies ou concepts. Pour faire plaisir aux détracteurs de tout système pouvant paraître comme un dogme devant être suivi avec littérature et cours à la clef. C’est devenu un business mais n’en était pas un au départ, me semble-t-il.

Je pense que si l’on me demandais de choisir mon église parmi toutes ses religions, pratiques, j’irai pour ce qu’on appelle, la do-ocracy, rapidement traduit en la démocratie du faire (to do). Celui qui fait, qui a fait, a décidé et celui qui n’est pas d’accord va devoir refaire, faire autrement, améliorer pour montrer son désaccord ou sa vision propre. Entre deux (ou plus) personnes intelligentes, il me semble possible de toujours tenter d’améliorer le travail de l’autre, de le mener vers un mieux en y apportant sa touche personnelle plutôt que sa critique. Celui qui fait décide. Je n’ai jamais produit pire résultats que lorsque je faisais quelque chose à contre-cœur. Cette idée tombe bien dans un contexte de collaboration, de donnant-donnant mais va alors poser problème si le contexte est différent comment maître-apprenti ou c’est sensé être plus donnant-recevant. J’ai un problème particulier avec une relation purement maître-apprenti, pour ceux qui m’ont côtoyé tant dans un milieu scolaire que professionnel.

Pour revenir dans le sujet initial, un des pires problèmes que j’ai pu rencontré est la bien connue tour d’ivoire, ou silo et peut-être plus compréhensible entreprise dans l’entreprise, état dans l’état. Une personne ou un groupe de personne qui se sépare volontairement, ou pas, du reste pour avoir plus de liberté individuelle d’une part et plus de pouvoir d’une autre. Il est extrêmement dangereux de centraliser des connaissances, du pouvoir sur une personne seule. Le problème qui survient est que la communication n’est pas suffisante car la-dite personne ou le-dit groupe n’a pas d’obligation pratique de communiquer ce qui se passe dans son giron. Pas assez de communication signifie que tôt ou tard les points de vu vont diverger, des même problèmes vont être re-résolu et la vision globale sera perdue.

La clef de voûte du design centré sur l’utilisateur (UCD en anglais) est rendre les choses visibles. En d’autres termes ne pas cacher les choses mais les communiquer. Rendre clair que ceci sert à cela, sans ambiguïté.

Donc, agile ou pas, scrum ou non, si j’essaie d’imaginer un environnement qui me serait favorable, sans pour autant le considérer comme idéal, j’imagine un groupe ou tout est partagé, de la vision aux connaissances, des joies aux peurs, des risques comme des bénéfices, tous types de nouvelles. Et ce qui est partagé en interne dans l’immédiat le sera à l’externe à moyen terme. En attendant, il est venu pour moi le temps de mettre en place ceci d’une manière où je m’y retrouve et puisse prendre mon pied.

About

meYoan Blanc is a web developer that lives in Norway (Markveien 24, 0554 Oslo) works for Opera and comes from La Chaux-de-Fonds. This web site is for this weblog, a playground for random stuffs and can help keeping me connected with some friends out there.

Get my vCard or contact me by phone (skype:yoan.blanc) or email ().

Misc

RSS, list.blogug.ch

This site reflects only my opinion and is not affiliated with anyone else.

copyright 2006-2009 — doSimple.ch