5 Books About Data Driven Lean Software Development

In french, we say “Le cordonnier est toujours le plus mal chaussé” which I found an English equivalent in “the shoemaker’s son always goes barefoot”. I believe this is nowhere more true than in the software industry !

“Software is eating the world” they say. Software is now able to do things that only humans used to be. So why the hell are we driving our projects as if we were a horde of amateur hitch hikers ?

What does it mean to be data driven ?

Being data driven would allow us to answer questions such as :

  • How much is the feature we delivered last week contributing to the bottom line ?
  • How much is the feature we are currently developing expected to contribute to the bottom line ?
  • What are the estimated cost and value of increasing our test coverage of 1% ?
  • What are the estimated interests and nominal amounts of our current technical debt ?
  • Which is the most valuable : improving our build system or building this new feature ?

Most projects I’ve worked in have absolutely no clue about the answers to these questions. The decision is left to experts, to the one with most influence, or simply to the developer, who can do how he thinks is best …

The books

Hopefully, some people are thinking differently, they believe it is possible to quantify all this, they even explain how !

Running Lean: Iterate from Plan A to a Plan That Works by Ash Maurya

Details a very practical guide about the lean startup process, which is a very good starting point to any kind of lean software development.

Kanban: Successful Evolutionary Change for Your Technology Business by David J. Anderson

This book explains with real world examples how to use Kanban board to control your work queues and improve your flow of work, a real basic for any lean product development.

The Principles of Product Development Flow: Second Generation Lean Product Development by Donald G. Reinertsen

This book is rather theoretical, but it links all subjects together : lean startup, risk management, Kanban, and economics. I guess it’s a must read on the subject.

How to Measure Anything: Finding the Value of Intangibles in Business by Douglas W. Hubbard

If the flow book gives a big picture view of what you want, this one explains how you can actually measure all the aspects of your product development in $ value.

Waltzing With Bears: Managing Risk on Software Projects by Tom DeMarco and Timothy Lister

Although this book is getting old, and is a bit outdated when compared to agile development practices, it provides real world examples of how scientific measurement can be applied to software product development.

An opportunity

Reading these books was a real eye opener for me. The software development world is plagued with cargo cult and supposed best practices. We follow advises, but most often without verifying if they actually work ! I believe that by applying the techniques in these books, we could create standard ways to measure the values of productivity, technical debt, quality, testing …

I see real opportunities to avoid a lot of useless argument between proponents of A and B, but also to communicate better with all stakeholders and finally, to reduce stress for all of us.

A Lego Office Experiment

Rome wasn’t built in a day, neither will be your Lego Office … This week is Devoxx in Paris, for the occasion, we decided to stream a Lego office experiment that my team did.

What are Lego Offices

I wrote about Lego office in a previous post, as a concept and a set of material that would allow teams to easily configure their workspaces as they wish. At that time, I thought of :

  • laptops
  • extra monitors
  • tables and chairs on wheels
  • movable walls
  • movable white boards
  • movable wall screens
  • a good Wifi

Our experiment

The last floor of our building in Paris has a nice (really) open space area with rolling tables that we could use. We moved all the team there for one week. As we don’t have laptops with Wifi, we simply asked for enough power and network plugs.

The place is large enough to have dedicated rest and meeting space. We managed to create a visio setup using our build monitor. We even had a remote lunch once, which we should repeat more often !

What’s missing

Obviously, this was a quick experiment, nothing like a fully architectured Lego workspace, still it helped us to discover issues and blocking points. It turns out that cables are an issue !

After getting some feedback throughout the company, it turns out that some developers would never trade their high end connected desktop workstation for a Wifi laptop. Our C++ build can be pretty CPU and network intensive … I guess that means that a real Lego office might require one of the following :

  • A technical floor with all the place required to bring any kind of cables to your machine
  • Powerful servers in a data center to do the grunt work for you
  • Single cable machines (Apple’s USB-C is the only one I can think of right now)

Last minute question

Thinking of it … could different remote offices such as your home, or a co-working space be considered as Lego blocks ?

How We Decentralized Our Company’s Training Program

Maybe your company too has a development program you can use to track and organize your training path. That’s already great ! It is often not perfect though. Sometimes, the initiative in itself can feel like an afterthought. Some other times, the process is completely left to the employee and his manager, with varying results, from great to forced upon everyone.

How did we rebuild this program in our team

As you might remember if you read my previous posts, we started a self organization initiative using a delegation board. When we tried to decentralize the end of year evaluation, we started discussing the subjects of personal development. We decided to have a dedicated workshop about this subject

Guiding principles

In our company, the development program allows a manager to assign specific learning goals to his collaborators, and anyone can also create his own goals to justify going to specific trainings. Starting from that, we agreed that the development program should be used to help anyone in the team to improve skills that are interesting for both the company and the employee. If the employee is interested in something completely unrelated to work, then he should obviously tackle that in his own time. If the company needs its employee to acquire some immediate mandatory skills, then that should be part of the daily job and subject to the end of year evaluation.

The idea is to try to find a win-win combinations, were employees are motivated to work their best at a company that they know helps them to full-fill their long term goals.

What did we came us with ?

This workshop was quite effective :

  • First of all, everyone is responsible for his own development, it’s a chance offered by the company. It cannot be forced unto people.
  • It is based on volunteer mentorship : everyone should have regular meetings with his mentor to asses his progress on his long term goal, to try to get feedback and ideas about how to move forward. We started by saying that the team leader is the default mentor, but anyone can find another mentor at any moment.
  • The process starts with the search for a long term goal. Examples are “I want to be an agile coach”, or “I want to be a performance expert”
  • With the help of the mentor if needed, the long term goal should be split in yearly objectives and tracked using OKRs
  • Everyone is free to track his progress has he wishes. Visual tracking makes the discussion with the mentor a lot easier. We have been looking at tools to track OKRs but it was surprisingly difficult to find one that suited our use. Most are enterprisy tools with manager-managee relationships. We just wanted simple personal tracking tools. For my part, I adapted a Trello board I found on the internet.


After doing a few months of this, I can say that this has a positive aspect on motivation, people told me that they felt more in control of their destiny. Something else I noted, is that junior developers need help and guidance. They often don’t really know what they want to do in a few years, so they really need a mentor to help them find out the what and the how. The other side of this is that a team obviously needs senior developers to act as mentor … among other things.

Trello Templates to Boost Your Remote Retrospectives

I already wrote how we started to use Trello to do our remote retrospectives. A while ago, my team mate Bilal Tayara started to collect our activities into trello templates.

New activities

I just imported new activities we have been using in the past months :

  • SMART Goals
  • 5 Whys
  • Circle of Questions
  • Communication
  • Engagement
  • ESVP
  • Fishbone
  • Focus On/Focus Off
  • Force Field Analysis
  • Gifts
  • Glad Sad Mad
  • Health Radar
  • HHH
  • Hot Air Balloon
  • How are you feeling today ?
  • Improvements Brainstorming
  • Learning Matrix
  • Note To Self
  • Plus / Delta
  • Problem –> Action
  • Punctual Paulo
  • Retrospective Planning Game
  • Risk Brainstorming
  • ROTI
  • Sail Boat
  • Satisfaction Histogram
  • Take Away
  • Team
  • Team Radar
  • Warmup Question
  • What happened since last retro ?

How to use these templates

Clone the template to your organization every time you want to use it. There are instructions in the template to explain how to use it. For more detailed instructions, have a look at the original :

One last thing : in order to improve this collection, we’d like to have your feedback on existing activities, or your own new templates for other activities.

How to Deal With the Incentive System in an Agile Team ?

For an organization, there’s something schizophrenic about valuing team work, wanting agility but sticking to individual objectives and assessments.

As highlighted in Build To Last genuine company values must permeate all aspects of the organization. Being agile also means putting teamwork first and that is quite incompatible with typical individual management by objectives and bonuses.

This is nothing new, many have already written about the subject

The problem is you usually don’t have the choice ! Whether your team wants to or not, the chances are that your company already has a mandatory individual bonus scheme in place.

Our delegation initiative

As you might remember if you read my previous articles, our team decided to move to more self organization. After identifying the end of year evaluation as something that could be further delegated, we embarked on brainstorming sessions about how to do it.

We discussed quite some options during our workshops. Things like :

  • What is the goal of the annual evaluation ?
  • Should some people have a central role in the process ?
  • Should we encourage efforts or results ?
  • Should evaluations be public or private ?
  • What’s at stack at the annual evaluation ?
  • Should individual learning plans be part of the evaluation ?

What we came up with

As a guiding principle, we agreed to value efforts rather than results. Sometimes, results are independent of efforts, and through efforts, it is always possible to get the best of any situation, even if the best is not a good result in itself.

Throughout the year

We are all sharing the same team objectives :

  • “the team finishes the prioritized epics” : we do regular epics prioritization sessions with our product owner and add the main epics to everyone’s objectives
  • “work on the same subject as the whole team” : we have an overspecialization matrix that uses correlation to make sure that everyone touches the same parts of the system as the rest of the team

Every 2 months, we are doing 360° feedback sessions, for everyone to give continuous feedback to others.

Optionally, we setup Kudo boxes to give and receive thanks from others.

At the end of the year

When the time of the official end of year evaluation comes, we do 360°, 1 to 1 rating on the following topics.

  • commitment & courage (doing not so fun work, find difficult compromises, say the truth, strive for quality work)
  • helping others (giving a training, providing coaching, help others, do some evangelization)
  • self improvement (taking feedback into account, improve technical skills, work on soft skills)
  • team player (build friendly environment, contribute to team improvement, positive attitude, use a non violent communication)

Grades are signed, and anyone can ask someone else for a discussion about his grades.

Overall, everyone gets an average grade, which we use to suggest a company grade (below, achieved, exceeded) to the HR system. It then gets homogenized with the rest of the company, but this is then out of our control.

One thing that made this possible is also that after taking a close look at the company grade system, we saw that not so much was at stake … Provided we make sure everyone has what it takes to do the job, anyone can get an achieved evaluation by doing enough efforts. Getting an exceeded is like a bonus for a particular good year.

Last word

I’m pretty sure we could make this more simple in an environment with more end to end feedback (start-up or pizza teams) but we feel that our current alternative is a lot better than having the manager deciding everything on his own.

Make Hiring Everyone’s Business

Let me tell you a typical hiring story. A bit more than 10 years ago, I was contractor at a bank on a C++ front office application. The system had initially been well engineer, but it had been stuffed together merged with another system that had a completely different architecture. Ha, and there were no automated tests. As you’d guess, we had quite our dose of bugs, and maintaining this application was not easy.

The manager wanted to hire a C++ programmer to beef up the team. Along with the division’s architect he was conducting interviews to find just that guy. A few weeks later, he found a known C++ & Windows local expert. A few weeks later, the team unanimously declared that we could not work with him because he was both pretentious and incompetent.

I’m pretty sure every developer already witnessed a similar story.

Managers do the hiring

This is the usual practice. The motivation is that managers have more experience so they should be better at it, and also that it alleviates developers from non-programming work. As we saw in the introduction story, there are issues with this approach too :

  • it’s pretty bad for the team ‘fit’ : there is no team building here. You often end up with a collection of individual working at the same place rather than with a real team.
  • during these interviews, the candidate only interacts with a particular type of profiles, who can tell how he’ll be doing with more junior team members for example ?
  • as usual, this administrative work removes some programming from the manager’s time. That’s often not a good bargain
  • it decreases the team sense of control, as it is being ‘forced’ to work with someone they did not choose. This makes it harder for them to take responsibility of what they are trying to achieve.

How we self organized hiring

As I already explained in a previous post we engaged in various self delegation initiative by doing a delegation board. During this meeting, we identified hiring as something that could be self delegated.

In order to fix that, we started a workshop for 1 hour per day with a sub group of the team. We started with a brainstorming, then we voted, and finally presented our proposition to the rest of the team, which actually validated it. The whole thing lasted for one week (5 hours).

What we decided for hiring

Here is the process we have decided to follow to handle hiring team members

  1. First, everyone in the team is responsible to speak up when he thinks we need to hire someone, during our retrospectives for example
  2. To handle new applications, we have prepared an online interview. It contains open questions and online coding exercises, on cyber-dojo, which allows us to track all the candidates iterations
  3. We do a round robin to find out who will follow the candidate through the hiring process. This means taking notes, organizing interviews, keeping the rest of the team up to date.
  4. When a candidate passes the online interview, we will receive him for an technical and general interview with 2 people from the team.
  5. All the team will then meet the candidate for a coffee break, in order to know if he will fit in the team
  6. We’ll then play the Google hiring committee until we reach a consensus
  7. When in doubt, we’ll do extra interviews, and repeat

That’s just what we came up with, if you start this road, you might well come up with a very different process.

One more thing

It’s great to have a selective hiring, but you’ll also need to improve the input of the hiring pipeline, but that’s another story

Scrum Teams Do Not Need a Scrum Master

We don’t have an official scrum master in our team anymore. We now have 7 ! A different team member assumes the full scrum master role at every sprint.

Why did we switch to Scrum Master round robin ?

It all started with our delegation poker (see previous post). We noticed that there were still quite some activities that I (the manager) was the only one to do. We hoped that by sharing these activities throughout the team, we would :

  • increase everyone’s motivation by showing a bigger picture
  • leave me more time for programming
  • learn new skills to everyone

How did we do it ?

Before our delegation board meeting, we had prepared all the activities we are regularly doing. We found quite a few recurrent non programming tasks that traditionally eschewed to the team lead (me in that case). The initial plan was to find ways to delegate these activities to the team during the meeting, but it would have took way too much time.

Having identified all these activities, I individually suggested at everyone in the team to do a round robin scrum master role, which would handle all these activities for a sprint. I was happily surprise by the quasi complete buy-in from all the team. Before I announced it to the team, I did 2 things :

List all the activities of the scrum master.

Here is a subset :

  • attend other teams meetings
  • make sure there are enough workable stories for the next planning session with the product owner
  • prepare and animate a retrospective
  • animate the demo

Make this more fun !

I bought totems for the scrum master. The team chose to keep Yoda in Paris and send Darth Vador in Ahmad suitcase back in Beirut.

What did we get ?

After a few sprints of this, the feedback I got is that people like the increased involvement in the big picture (Daniel Pink told us that already). On my part, it allowed to increase my programming time to nearly 7 uninterrupted days per sprint (10 days). I’m quite happy with this ! As for the third goal, learning new skills, I guess we’ll need a bit more time to figure this out.

Stop Feeling Like a Kid Every Time You Ask a Day Off

Most companies don’t have unlimited vacations. Most likely, if you are an employee, your days off need to be validated by your boss. If you are like me, this feels like pulling teeth … Every time I have to ask for a day off, I feel like a kid asking for an extra candy

That’s not the only issue with how we traditionally deal with vacations :

  • The boss has to make sure that there are always enough people at the office to handle emergencies
  • If the boss is himself away, getting a day off at the last moment becomes difficult

Our Delegation Board

Our team at work is already rather agile : we’re using a blend of XP and Scrumban, we follow solid engineering practices and we are always trying to improve to deliver more value to our users. After reading Management 3.0 and Management Workouts I was convinced that I needed to move the team towards even more self organization.

We started by doing delegation poker, we created a delegation board, and set out to move all cards we could to the right side of the board.

We spotted the following topics that could be more self organized

  • vacations
  • hiring
  • business objectives and end of year evaluations
  • various recurring scrum related activities
  • self development objectives


We decided to tackle vacations first, because it seemed easy. We did a quick brainstorming, and here is what we came up with :

  • We cannot change the company policy, so I’ll still have to officially validate everyone’s vacations in the system but …
  • I’ll validate anything asked !
  • Our internal system allows to check the other team member’s vacations, so everyone in the team is responsible to check that there will always be at least 2 people at work before taking a day off

It’s been 6 months, and it’s been working like a charm. I think it made everything simpler once we had a clear rule about when vacations were OK or not.

Are Most Agile Teams Doing Continuous Improvement the Silly Way ?

A few weeks ago, as I was looking the internet for Lean principles to improve our way of working, I fell upon this book Petit guide de management lean a l’usage des équipes agiles (NB: the book is in French, the title means ‘Little lean management guide at the usage of agile teams’). It made me think and I thought it deserved a blog post.

It explains that agility can be though of as a set of practices and principles, shared through a huge community. This makes it a great production system, where improvement are mostly brought by gut feeling retrospectives and trial of other teams practices. At the contrary, Lean is very light framework for continuous improvement, relying on a more systematic waste elimination.

After this introduction, the bulk of the book is composed of a set of 9 detailed real life stories demonstrating the lean way of bringing improvements. Are is a summary of 3 of these :

Unknown Category at Project Condor

The team maintains a virtual call center of poor quality, resulting in lots of incidents in production. Here is how they deal with the situation :

  1. They start by showing the issues, by categorizing them from the logs, they discover that they are mainly related to training, network, but surprisingly, the majority (30%) cannot be categorized and fall in the ‘unknown’ category.
  2. By improving logging, the unknown category falls to 5% ! Fixing network timeout issues then makes the client a lot happier.
  3. Eventually, they go to client’s site while monitoring the logs at the same time. They discover that remaining issues are explained by

    • some users are using a double click to hack the system and jump ahead of the queue
    • the hang up and hang off buttons being too close, which results in operator misleadingly ending their communication
    • calls to wrong numbers being logged as incidents

The authors conclude that while uncomfortable, going to the clients increased motivation for everyone, fixed issues and made the client happier.

All Guilty !

An author is called to help a team which is working on unifying reimbursement systems after a merge. The project is late and the product is unreliable.

The first step he takes is to visualize a target (next batch in 3 months) and the flow

The flow whiteboard shows that tasks get stuck when in need of clarifications from business analysts. Tension between people is already increasing. They Team decides to visualize this with ‘blocker’ post-its.

After an inquire with the BAs, it turns out that they don’t see the waiting tasks the issue management software.

The final step is to agree all together (developers and BAs) on an uniform way of defining and following blocking issues

Tickets are discussed at the stand-up, and unblocked issues are also visualized. As a result in only 2 weeks, the process fluidifies, and the tensions decrease.

The authors conclude that cross functional teams work better


This story starts in a rather typical way : the client would like the team to go faster.

The team engages into a series of Plan Do Check Act cycles.

Hypothesis 1 : There must be some obvious waste

The team decides to log any waste occurring for 2 weeks. Even with discipline, only 2 hours are spotted during the 60 man.days of the sprint

Hypothesis 2 : Too much refactoring or too much test writing

For a few weeks, the authors keeps a daily log of the team activities during after every stand-up meeting.

It turns out that writing tests accounts for 5,5% of the time, refactoring for only 2% but programming for 40% !

Hypothesis 3 : if there is something to improve, it must be in programming.

For 20 half days, the author embarks on the tedious task of keeping a very detailed log of activities while taking the role of navigator in pair programming sessions.

They clearly understand that most time is taken not in writing tests, doing refactoring or writing complicated code, but in understanding existing code, third-parties and APIs


First, they avoided loosing time on improving the wrong thing The team also agreed on the practice of asking for help at the good person when starting stories. Doing that, they got a nearly 100% speed boost !

The rest of the book

The book highlights a lot of other continuous improvement practices. For example :

  • The ‘problem box’ where team members can log any waste they are going through during their work. This made me think of my Plan For Technical Debt
  • Individual improvement follow up : a single team member is responsible to drive an improvement to its conclusion, in order to make sure that it is not forgotten

I personally found this book to be just great ! It’s short and focused, pragmatic, and a pretty easy read. If you liked Scrum and XP from the trenches I think you should read it. More generally, I think it’s very useful for anyone involved in the development process who would like to push agility a little further.

There’s a catch though, it’s in french ! I guess I could take the time to translate it, tell me if you are interested.

How Long Can Your Inner Drive Last ?

Any software project (job, startup or side project) will require some time before one can get real feedback from real users.

The hard truth

Your inner drive will only last up to some point. Without feedback, your motivation will die, and this will kill your project.

How to deal with it ?

Know it before you start

From my own past experiences, I could find that my inner drive has usually disappeared after 2 years (I don’t want a word about the time I actually wasted to discover this …). You too can try to estimate how long you can keep on without much feedback, go through your previous experiences to get an idea.

Once you have an idea of how long you can keep on without much feedback, you’re in a much better place to decide to embark on a new project.

Don’t drown in the code

I once started a side project partly because I was fed up with the poor technologies I was asked to use at work. My project was some kind of salvation. The drawback of this situation is that I tended to dive into code way too early ! Building a real product takes time, and that’s a sure way to get late feedback.

Use Lean Startup techniques

Lean Startup is all about getting constant user feedback, even before having any user. I especially liked the book UX for Lean Startups that explains all the ways to get feedback from the cheapest (interviews) to the most expensive (HTML mockups) without actually coding anything

Watch out for the Duke Nukem Forever syndrome

Be very careful of endeavors that promise an Eldorado after long hard work that should last months or years. Products need to ship early with as fewest features, not late with many features. If you embark on such project, you’re pretty likely to :

  • burn out before the end
  • deliver something that is already outdated the day it goes live
  • never deliver anything

If you’re already on such a project, I strongly suggest quitting.

End word

Maybe getting real feedback from real users takes time, but getting very early feedback from future users is almost always possible.

Keep going, get some feedback !