Basic tech debt strategy to clean up my Facebook wall

The Wailing Wall

18 month ago my facebook was a mess. I disliked it, most posts were from people I had no recall, and too many times the posts were troll, people whining about the world, if not purely xenophobe. Every 5 minutes there was 30 new posts, so I couldn’t catch up with anything.

As thousands of friends were stacked from my past involvement in Rotaract (a worldwide humanitarian organization related to Rotary) a big spring clean up was just too big to be done at once -been there, failed several times. When browsing my contact list it’s hard to find who’s been posting what. Some I didn’t recall and some I’m happy to keep as “maybe” contacts when I recall them. Reviewing each FB friend takes 30s to 1minute… I’m set for dozens of hours.

I was about to give up Facebook at all (I barely checked it every 3 month already), until I decided to go backpacking for a few months in South Asia.

Then I had to use FB again. Many travelers use it as a go-to communication platform, it’s a cheap and easy way to send news to family and friends. Then there’s the ton of pictures you want saved on the cloud before your phone get wasted in sea water (been there). I had to.

Split second filter

As a last resort I went for another approach : to forget the past, then to focus on practical issues only as they appear. As for Facebook it came down to one simple rule :

if I strongly dislike your post, I unfollow you.

Literally 1 second.

In less than 2 days, a Pareto law of annoyance was revealed before my eyes : 80% of the annoying posts are generated by 20% of your Facebook contacts. Actually more like 90%/10%.

Suddenly my wall became a place I had pleasure to go to again.

Unexpected discoveries

Originally I learned that approach in dealing with technical debt in software development : you give up solving the whole mess proactively and just start reacting to bugs as they are discovered or rediscovered. Here I had a  few more learnings.

1) Only afterward did I discover what I was looking for

  • the positive and appreciative people
  • the proactive and socially progressists
  • sharp humour
  • Internet / music curation of my liking
  • news of people I care about
  • news of parts of the world they care about

Those who annoyed me were

  • the ones whining about anything
  • the pessimistics and cynics turning anything negatively
  • the lecturers (“Do a detox diet coz you suck at eating, all right?”)
  • the Facebook frenzies (one post every 10 minutes)
  • the boring (“hey my bus is late”)

2) My biggest assumption about the need of a big cleanup appears wrong

my forgotten friends are mostly silent. Some become active sometimes and are actually nice contributors to my wall.

3) Friends can be a very efficient source of world and local news

This comes with a clear filtering bias but this bias is more obvious to spot than bias in conventional media (or my own choice of news media)


Not fun conclusion : in the wake of the Paris attack 3 month later I was away in Hong Kong. My Facebook became my primary point of communication and news. I’m glad I had this place to be surrounded by these good people and read their fine words.

Posted in Non classé, Quality | Leave a comment

Avoiding confusion about what iterations means

In agile, we call Iteration a fixed time period. In Scrum (one of the agile methods), an iteration is called a Sprint. By that we mean a fixed cadence of work.

I witnessed several trainings struggling on the same topic, trainers and attenders alike. I heard many people I coached mixing notions right out of a Scrum training.

So let’s see if we can spell out this confusion for the future.

Overusing the Sprint / Iteration words

Many times I hear the word sprint used for “a fragment of the product” or “an amount of work to do”. I guess it’s originally a shortcut from “fragment of product done in the time of a Sprint”, or “amount of work planned for the time of the next Sprint”.

However, for someone not used to agile, it’s confusing. Trainer said it’s a fixed time period. Then trainer seems to say it’s an amount of work. There’s something that magically make an amount of work fit in a fixed time frame. Coz for someone discovering agile it’s painted with mystery.

In a recent training our attenders where from waterfall world (where you plan according to effort), and started ask questions mixing notions of effort and time. The other trainer and I have been paddling for 20 minutes not knowing why our trainees kept mixing notions despite our explanations… until I realized we abused the meaning of iteration. So much for clarity.

The trainees didn’t see that in Agile we are now planning in term of time box, giving a pace of work where the amount of result is variable. In their previous world you start planning from effort that will span in phases of variable durations.

Classic check that you failed to lead to cadence thinking

If you don’t sort this early, later on the project they will be surprised when through the course of a sprint (again, a fixed time cadence) throughput don’t go as planned. They weren’t prepared for that since they weren’t driven away from there previous “effort” frame of reference. Again, they’re confused.

Usually I let it go since after a few sprint they will get it, but in the meantime they struggle and they are unable to explain it to other project partners and stakeholders that are not used to agile projects.

Well, they get it… actually I’ve seen Product Owners and even Scrum Masters still mixing notions after a year. I also saw agile veteran projects, year longed, intoxified by the notion of planned throughput.

A few classic tense to avoid

Guess what ? I saw coach and trainers also not being able to precisely sort the notion. (yes, me angry here)

Here’s a few quotes I heard from trainers that led trainees into mixing the two notions

  • “you did all the Sprint”, “you didn’t do all your Sprint”. Of course they did. How could you fail or succeed 2 weeks?

    Instead, you can say you achieved in the course of the spring less than you predicted, or more.

  • “let’s plan your releases into iterations”. You just can’t decide that.

    Instead, you can say (after the project has acquired its rhythm), “let’s try to predict what will be done at each iteration”.

  • “we will report the sprint on the next sprint”. Again, it may be just that you are shortcutting words, but for those discovering agile, it’s confusing. Instead you can say “During the next sprint we will work on the user stories that aren’t Done”

Avoiding the big trap of the initial project -planning-

After starting to spot the confusion, I realized it came mostly during the first initial roadmap creation, and can be avoided there.

Today I pay great attention to not use the notion of time when doing the first story map and roadmap definition (inventorying the project features scope and setting it into successive interesting releases).

By extension I don’t use the word iteration or sprint either.

I carefully choose my words since it may be that my coachees has been misled during a previous training (more on that later).

So far, it works, I have very little questions that mixes the nations. So the confusion went from me.

Practically :

when I do a roadmap, I ask the product owner to prioritize items typically by one of these two strategies :

  • “Buy a feature” exercise

    “If you could have 3 of these features in short term (or Epic, or macro-story whichever terminology you use), which one would you like to see done and working ? Then which ones would you pick next ? etc”. See ? Sequence thinking, but no notion of time.

  • Dichotomic prioritization

    “here’s a line, this is your mid-project. What would you see first ? What would you see next ?” (you can also use “must have / should have / why not, or any criteria to make prioritization happen)

    Then I draw another line in the middle of the first and second quadrant. (interesting variant : I draw 4 lines and ask for 4 releases directly ; let’s not digress)

    At this time, I never introduced the notion of When things are going to get done. Only what should comes first.

The notion of time will only be introduced on a next estimates workshop. Then I will follow the advice of J.Rothman and only use the words predictions.

Erm, Scrum industry, wtf ?

You mind if I end with a rant ? Gotta unload my heart. It was my first impulsion into writing this.

Scrum industry, you’re a powerful machine, you help popularizing agile and raise new generations of Agile Trainers and coach by the hundreds. But when you fuck up such detail we coach in the field have a hard time cleaning up the mess.

And no, don’t look away, the mistake can’t be made in flow-style Agile (Kanban and such) since we just speak about cadence and don’t even talk about iterations planning. I spotted that constantly will people coming out from various Scrum trainings.

So to my beloved pairs teaching Scrum : can you check that the confusion of iteration = time is not engraved in your training slide ? Thank you very much

Bisous bisous

Posted in Non classé | Leave a comment

Total blog overhaul (in progress)

After a year on a break, the web site is on massive overhaul, reboot-style. It comes out of both a need and an accident

A camp base for the new international me, integral view

While looking for work outside France, I realized I had like zero trail in english on Google. After trying a first batch of English articles last year, I’m now turning the whole blog to English.

Many readers also tells me they read both my blogs since they see connections between both topics, and they expect that from me. They’re right, my thoughts have always integrated Agile and personal topics, and so my life. So I’m merging both blogs, it will be easier for everyone.

Actually, over years I professionally lack a single place where to show pieces and bits of my various commitments and inspirations (blog post, agile material, sessions, professional reference, etc). I’ll try a different writing process on this new version.

So I needed a new name, right ?

My genius friend Emilie Esposito came up with the bold domain name of It kicks me in the butt. I want to live up to this statement.

Thank you hackers, now I have a blank slate

Just as I was thinking of changing my blog step by step, my domain has been hacked several times. 10 days down in April, some technical changes to enforce its maintenance. Hello Broken links, missing illustrations, and SEO rank zero.

I took that as a sign : let’s restart from a blank slate. I gave up any attempt of continuity, template is black on white and some illustrations has to be fixed. But now I’m free to move fast.

Posted in About ze blog | 1 Comment

How to defeat the Plouf : genesis

In 2008 I talked in french about the Plouf at the early USI conference (title : “Vaincre le Plouf”).The Plouf is a hidden force that prevent us from taking action when we have decided of something.A few month ago I came back at it at the XP Days 2014 conference (then in english, “Howto Defeat The Plouf“). I wanted to share my behind the scene story, how I became inspired to raise attention on the Plouf in the first place, and why i felt an urge to come back at it.

Battez le Plouf !

2008 : Fight the Plouf ! @USI

Continue reading

Posted in Vaincre le Plouf | Tagged , , , , , | Leave a comment

Encouraging team’s freedom : how much is enough ?

When talking with directors about how to enable collective intelligence and co-responsability in their teams, they usually find me too strict regarding their own behavior.
« Yes, last week I’ve been keeping someone’s action on hold -it was over a detail, but I didn’t understood her decision, you know. And the next day I stepped in and took direct control of à team’s action plan, telling people what to do.
But what’s the deal, that’s just two times, right ? On average, I let them go on their own if it’s good for the business. They know I expect them to decide and act without waiting for validation on details, right ? »

My point is : no, they probably don’t.

To explain why, I’ll use a reverse example.

Reverse proposition: dictatorship

Imagine a dictator of a 150 people village. How many people does he have to punish to remove any attempt of free-thinking and free initiative ?
My bet : 2 are enough.
It’s not about controlling all of the free-thinking leaders, it’s about making an example, telling a message. Once people got the message, they’ll stay away from displeasing you. The first punishment makes an example, the second one set a pattern. Then the word spread. Self-restraining behavior will soon appear.

Now let’s say the dictator changes his mind.
How many people does he need to reward to remove the former message, to say « good you take that initiative on your own. It helps ! » ? 10, 20 rewards at least, right ? While restraining from any censorship

Back in our management situation.
Control messages are far more powerful because they’re calling our inner surviving sense. « Don’t get into bad situation » comes before « Thrive in your life ». No balance is possible because these are not competing on the same level : safety wins.

You’re the boss, boss

As a CTO/CEO, you have a lot of power and influence on the people that works for you, probably more than you think.
So when you’re a manager, a CTO, a CEO, and you forget yourself 1 or 2 times per week by being over-controlling, censoring someone who takes an initiative you didn’t understood (in other words : you freaked out), you don’t get an « average » message at the end of the week. You drawn a powerful pattern that you’ll have a hard time to remove.
That’s why, even if I’m being tolerant as a coach, I stay relentless about the behavior required to set a proper messages.

Now, if you’re asking yourself « Am I doing enough to get my teams confident about their freedom to think and act by themselves ? », I would use two reverse questions instead :
1) how many censoring actions are needed to kill people’s investment in your project ?
2) how far are you from that number ?

Posted in Agile, Change, Control, Management, Trust | Tagged , , | Leave a comment

Meet in circle for circularity

Your coworker, what a jerk, right, interrupting people like that ? You can’t event figure how to raise a word in these damned monthly meeting. So when it’s your turn, you use it as much as you can. And… you keep it a bit too much, maybe. Think about a vicious circle, right ?

There’s a basic trick to prevent people -yourself included- from interrupting each others during meetings : have the chairs set in a close circle, 2 or 3 meters wide.

We’re all bullying from time to time, let’s be honest. But when you can see everyone at once, feel them close, you know who’s talking and who’s about to. There’s also a pressure to take others in count before bullying around. So consider this trick a good way to stop yourself from being harsh. Suggest it to your coworkers for yourself.

I see a few cases when this no-brainer of meeting facilitation is forgotten

Presentation followed by a question / answers session

After a coworker ended her classy powerpoint, ask 30 seconds before the talking to move the chairs as to have everyone in circle, in each other’s sight. Yes, in conferences too, as much as you can, have people move their chairs or themselves before the Q/A.

Tables are set in U shape

or anything too large, dismantle them form each other. Have people sitting closer, 2 or 3m max. If you like, remove the table, best trick ever for honest conversation.

When there’s this big one-piece of un-removable presidential table

I’ve seen that. A large table set up as a triangle, proudly riveted to the ground. It set people apart in 3 factions at every meeting, 5 meters away, with people at the corners feeling unengaged, and people in the middle of the sides feeling exposed.
Well, get rid of that table. It deserves all you can. Talk to the boss. There’s important things running in this meeting room, right ? otherwise nobody would have put such a proud piece of furniture there. Get. Rid. Of. It. Replace it with simple tables on wheels so you can easily rearrange the room whenever you want.

You’ll thank me.

… now, I do know it may take some months. Until then, try to set up a circle of chairs beside the table. You’ll prove how much more efficient and healthy meetings are. Now, go get the chainsaw.

Posted in Agile, Facilitation | Tagged , | Leave a comment

Work with old kingdoms to establish new republics

Everyday, agile changers face the same challenge : how to create a system with shared responsibility and collective decisions when there’s a hierarchical organization in place ?

In 2005 I travelled to Cape Town, South Africa. I was impressed by one particular event faced by this 400 years old country. The apartheid was ended by white people. Exclusive owners of the voting right, they voted a new constitution to share that right with everyone, no matter their skin color (note : they were more than one step leading to this, refer to wikipedia if interested).
13 years after the events, I was amazed when visiting Cap Town at how much a country with such a heavy burden was able to move forward so fast. They already had gay mariage.

Last month Alexandre Boutin told me another related experience he had when coaching a Korean company. His attempt to promote collective creativity was stuck. He was informed after a few hours that what he promoted was in contradiction with local manners : you don’t challenge in public someone else’s idea. A brainstorm, based on that precise principle, was impossible. After this social trait had been made explicit, they worked a way to circumvent this social convention in brainstorms.
But who did explain this cultural trait to him? The big boss. Who proposed and allowed criticizing ideas inside the group? The big boss.
The power in place allowed another distribution of power. It was peaceful and with immediate effect.

For change makers like me, there’s a lesson here. To change an organisation, the most efficient course of action is to have the current one doing it. So work through the system, not apart from it, not against it.

This led me to a few recipe when spreading agile in a hierarchical organization (with a tendency for command and control) :

Look for the person with a crown

Working from the ground level, doing more agile rituals, more « let’s prove them … », more « let’s have them understand that … », that’s not working. If you want your agile zone to spread, go up the power ladder and start where the power lies.
(How up the ladder ? enough to rule the whole organizational zone you want your new organization to reside in)

Deal with local lords

Unless you have a feature-oriented organization like Spotify, an efficient agile team usually unite skills from different divisions (business, IT, etc.). There’s as many managers to convince. Learn to sell them the change, let them deal with their current restraining forces (local power, budgets as a social status, etc), mobilize them.
Usually, these guys will introduce you the queen is she’s hard to talk to.

but all this requires to

Respect them, learn their etiquette

Understand their constraints, their social codes, their decision ecosystem, what subject triggers their interest. Just ask them, if you respect them some will teach you, even offer their help. They will tell you what is needed for this change to happen.

Is that encouraging the current system ? I don’t think so. Going along with the rules is not giving up. It just means you need to respect the system in place if you ambition to change it.

Posted in Agile, Agile Coaching, Change, Management | Tagged , , , , , , , | Leave a comment

Agile explained in 3 paragraphs

I said earlier (in french) that being able to explain agile in any time frame from 1 minute to 2 hours is a key to agile adoption. Sometimes it’s also in a written manner. As years goes by I have stacked some short descriptions of agile I use here and there or rewrite.
Here’s a 3 paragraph explanation I wrote for a client’s HR division, whose people had no knowledge in software development. Feel free to reuse / modify / share.

Iterative implementation
In a classic waterfall development process, the software is exhaustively described, then developed at once, then validated.
Every evolution during the project disrupt the schedule. In agile development, features are added little by little up to the wished goal, refining requirements and validating as implementation goes on. This approach enable innovating during the project, and shortens the time between idea and implementation.
For agile mode to work, the implementation organisation must remain stable : a dedicated team, stable over time ; fixed-duration iterations (one or two weeks) ; and a regular work rhythm.

The agile team
Maximum proximity of all contributors is seeked as to benefit from face-to-face communication and the best emulation possible. Through specific meeting rules and visual management, shared responsibility and self-organisation are encouraged : success is everyone’s business, and the team operates day-to-day the way that seems relevant to it.
3 roles are distinguished in agile :
– the product owner (*) defines thinly the functionalities and their relative priority of implementation
– developers are in charge of end-to-end implementation
– the facilitator run the meetings and watch after the team dynamic. This role is endorsed by either a developer or the technical manager (**).

Handling risks and work pace
Progress indicators and risk indicators are evaluated by the contributors of the project themselves. With ground people driving the project, incident and delays are detected earlier, enabling structural decision to be taken by the top management soon enough, thus reducing further rush hours. (***)

(*) I used in fact « responsable produit », french translation of « product manager », a term more suited to the client’s usual terminology. The intended receivers weren’t about to run projects themselves so I choose not parasite their understanding with our agile-specific metaphor
(**) This organisation used to put apart technical people from business one. Coaching some of the technical managers into becoming agile facilitators of their team, aka Scrum Masters, was a choice we had made in this particular organisation.
(***) … Which was a way to tell the HR that a more efficient project management, i.e. Agile, enabled a healthier way of working

Posted in Agile, Agile Coaching, Agile Rituals, Management, Product Ownership, Scrum Master, Steering, Team, Trust, Validation | Tagged , , , | Leave a comment

My meeting attender manifesto : be useful or don’t be

Proclaiming that meetings are evil is common these days. I’m rather part of the people who proclaim that meetings are useful and precious but expensive. Meaningless and inefficient meetings are evil. There are plenty of advice around on how to run efficient meetings, like setting up agendas, protocols and decision report. After trying to bring these practices to various clients, I find this group approach too slow, it does not spread fast enough.

Why not starting by working on our own individual behavior ? More precisely : our will to be useful in meetings. Not having meetings useful for us, no, the other way around. As to support this statement you could for example

  • decline the invitation if you don’t expect to be useful
  • get out if you think you are not useful
  • when in doubt, ask if you will be, otherwise leave
  • leave in the middle of the meeting if need be
  • ask to bring the items you’re useful for on top of the agenda
  • delegate if you are not available

It doesn’t mean you will go to less meetings. You can go there differently, learn to improve your usefulness, even if your involvement to the subject is low. Like

  • ask for a wrap up of the further discussion if you’ve lost the point, offer your wrap up if no one answers
  • ask candid question
  • ask quiet attenders for their opinion when a conversation gets stuck
  • bring out new perspective through suggestion
  • propose various way of deciding
  • start making a drawing or give a pen to someone
  • follow the time and make time announcement
  • ask for the agenda and purpose of the meeting if unclear
  • go write key points and decisions on a paperboard
  • show a good mood and a comforting smile

You can also ask yourself if you are still useful if

  • you will bring no difference in opinion, position, perspective, culture from the other attendees, at least regarding the agenda
  • you just want to be kept informed
  • you need to see someone you know will be there
  • you will hide your disagreement
  • you chit-chat and whisper with your neighbors
  • you will check your emails

A set of tricky questions

  • What if I’m not concerned at all ? Facilitators and role models are useful. Ask if one is needed. Otherwise decline.
  • What if I just care and want to bring my support ? This is a wonderful motivation. Now show your support even more by trying to be useful.
  • Who cares if I’m not useful ? Your silent presence distracts others from feeling committed to the usefulness of the meeting. By the way, don’t you have anything else to do ?

Now the last question will draw the conclusion. What about the others ? What can I do to have the others follow the same path ? I don’t want to be alone driving things forward.

Don’t distract yourself teaching others. Focus on yourself. Your own attention to be useful (or moving out of the way) will inspire others.

Posted in Agile, Agile Rituals, Facilitation | Tagged , , | Leave a comment

Kanban, because you’re worth it

A manager working for the media industry asked me a few month ago whether his teams should use Scrum or Kanban. He had sponsored agile teams I coached for 2 years. We worked together but didn’t get into the details of methodology, so we knew each other (explains my familiar tone). Here’s my answer.
Hi O.

TL;DR : since I’ve been working at France Televisions Editions Numériques I’ve already been coaching your teams to Kanban, so you’re not going to get lost. You’re already doing flow development, like M. Jourdain speaking prose.

WTF are Scrum & Kanban ?

  • two variations of Agile methods = two subset of practices, not necessarily exclusive
  • Kanban (also labelled Lean IT or Lean Software) is a software development flow = you pop functionalities from a backlog and you check the counter every iteration
  • Scrum follows the same principle but with strongly imprinted iterations, more protocol and meetings, in particular iteration planning, detailed task decomposition, estimation and a « commitment to deliver » at the beginning of the iteration. That’s not far from being a mini-waterfall cycle.

These methods are just starting points. While continuously improving teams will perfect them. Over the course of the project new practices will be integrated, modified or removed in regard of the time and context.

Kanban, because you’re worth it

My reasons for recommending you a development flow are

  • it encourages better coding practices : baby step development, systematizing development and quality processes, emerging and minimalistic design
  • Scrum do recommend good coding practices but enforces nothing and it’s a lack. I find that teams doing Scrum usually do not care enough about their coding practices, or too late in their product development.
  • In a flow you’re more reactive, you can introduce minor evolutions on the fly (just in time), let an ambulance pass through the traffic, which is more adapted to your activity [my client was working in the web / news media]. It’s never a 0 cost operation but it’s never a problem of methodology. With Scrum, adding a feature inside an iteration is seen as a disturbance (translation : violating the dogma)
  • Kanban is just more efficient, drier : less chit-chat, less fuzz, simpler to deconstruct and to adapt to each context. Scrum needs half a day of ritual meetings per week of iteration, with Kanban you get down to 2 hour.

This evolution is where, by dint of continuous improvement, long journey team goes (after more than 50 iterations), or projects with high stakes or high risks, or mini-projects (having an implicit risk level due to their size).
It’s been 3-4 years I’m asking myself « what if we start by the best of ? » and it does work : young teams reach in a short time the maturity of long journey teams.

What duration for iteration ?

Apart from questioning the coding practices, the underlying question is the duration of the iterations : Scrum is more 2-week suited, but become too burdensome on a shorter pace (cf half a day of ritual).
Today I always recommend 1 week long iteration when a team starts : twice more learning because twice more retrospectives, short-term adjustment to their functioning, etc. I’ve let the [XXX] team start with 2-weeks iteration and we kicked ourselves (waiting 14 days to see if problems get resolved was unsustainable as the project start).

On the contrary, a seasoned team can be caught in the day-to-day (which is the point at early steps) and lack vigilance on long term planning. Some teams do like 2 week-long iteration to bring tempo within a long journey without specific deadline (like 4 month of development without a planned public release). That’s what the [YYY] team has chosen for example.
I think it can be meaningful to go on 2 weeks pace to a far away release for any team older than 10+ iterations, that already masters its flow with 1 week rhythm.

Like I usually tell the teams I coach,

I could have you do Scrum, but you’re better than that.

Posted in Agile, Agile Rituals, Management, Process, Steering, Team | Tagged , , , , , , , | Leave a comment