Stop trying to go fast
…And start trying to go efficient.
I am still a young developer — a rookie, you might say — but during my four years of work for my company, I have seen many things regarding development and project management.
But first, let me explain what I thought development was all about when I started my studies.
I started at the Universitary Institute of Technology (I.U.T, in french) of Paris Descartes. I wanted to learn development since I was 14 — and I actually started to learn since I was 14, but I could never properly learn, as I needed both a good environment and to focus on my scholarship. But still, I started to learn with Open Classroom, formerly Le Site du Zéro, and was able to create some (ugly) static websites with PHP, HTML and CSS.
When I finished high school, I then went to the I.U.T of Paris Descartes, ready as ever to finally learn what I liked the most: programing. I learned with passion: algorithm at first, C and C++ then, Java, JavaScript (I was so bad at it then), and a lot of other technical fields such as operating systems and networks.
But what about all the other skills? What about project management? What about a bit of economy? And more importantly: what about what is happening every day in every company? What about the fact that, in 2019, IT projects are still failing? That they will probably continue to fail if we keep doing things the way we do things?
Well, regarding project management, economy, oral expression and other non-technical skills, I had classes with excellent teachers.
But regarding the last two points, I was never prepared to what I was about to see in real life. Even in my engineering school, they never prepared us to that — I mean, how could they? Even during my apprenticeship, I was really far from reality.
When I started to learn programing, I thought it was all about doing what you want, and being technically good.
So foolish of me.
So long for technical skills
[Spoiler alert] Technical skills never were the problem.
Like, really: I am not an expert, but I never really had any problem learning something new when it came to a technical aspect of my work, and as long as I liked it.
During my apprenticeship, I was not a developer: I was a Performance Consultant, and I hated this job. What I wanted to be was a developer. So three months before my apprenticeship came to an end, I started to learn JavaScript with Udacity. Back in my first years of studying, I was really bad at JavaScript. The course was kind of a mess, there was too much to learn and the teacher was not really well organized. Also, as everyone starting to learn JavaScript, I was not understanding it.
Plus, I was generally good at programming, and as a lot of people who never experienced failure in a field, I didn’t know how to handle it (spoiler: it’s petty simple, you have to forget your ego and to accept the fact you are not good before working hard).
So when I started to learn it again (and I mean really learn it), I was positively surprised to see I actually understood it quite well.
After that, I was hired in a really good company AKA IPPON Technologies, where I was able to work both with Java and JavaScript. I started with a project in AngularJS 1.6 and TypeScript. I was a total newbie, and I had to develop from scratch this brand new application. As time passed, people joined the development team, and we ended up as a SCRUM team.
The project lasted 18 months, before I leave it, alongside with other developers.
It was in 2016. Today, as I am writing this article, the project is still not over yet. Do you want to know what happened? We got tired, because we were asked to redo every screen from one sprint to another, as the design constantly changed and there was no one to clearly validate it.
The project started in September 2015. In one year, it had gotten 18 millions euros deficit. If you cannot guess why, maybe you can guess why not: technology and technical skills.
Technical skills never were the problem.
Three month after we left, they chose to redo entirely the project in Qt. It had not helped a bit. Of course, Qt was clearly more adapted to the context — why would you use JavaScript for an embedded app — but they kept having more and more delay.
You might see, at this point, where I am going to.
But you might also not see, so let us continue with another example, shall we?
That one project had failed two times: one with AngularJS, and another time with Qt. After that, I went to another project. This time again, it was a brand new one. Really, attractive: Angular 2+, TypeScript, Docker, ElasticSearch, micro-services, Spring Boot. Looked like my dream project.
I was going to be a fullstack developer, and I was going to learn so much! Doing both front-end development and back-end development was about to get exciting.
I lasted one year and a month on this project. I could have stayed longer, but the truth is I was getting exhausted by one particular aspect: the project management.
Our customers, our clients, are all experiencing fear.
They fear turnover. They fear delay. They fear bad quality. They fear unsatisfactory work. But most of all, they fear money loss. And that one fear, I can assure you it supplants any other fear they can have.
Because of the fear of losing money, our clients tend to take bad decisions. They also tend to lose their trust in us (developers, designers, scrum masters, POs, etc), and they tend to deconstruct the decisions they took in order to reduce delay, bad quality and turnover.
The bad news is: our clients are humans, and we cannot blame them for experiencing that fear.
The good news is: our clients are humans, and so are we, and we can educate them and ourselves, especially regarding the major painpoint in every project: the project management.
The methodology we choose to manage our projects with is one thing; the way we apply this methodology is another thing.
In this project, our client wanted to apply the agile methodology, but he also wanted everything done in exactly one year. Those two conditions were contradictory.
And because of that — because our client’s planning was so rigid — every team on the project started to experience tensions with other teams; developers, wether they were working on the backend part, on the frontend part, on the SAP part, were exhausted. Every designer, and every PO.
Even our client started to be exhausted, as they were many to take decisions and they rarely agree with each others.
Beside, the agile methodology quickly went from SCRUM to PAIN (stands for Prodigiously Absurd, Inefficient and Nasty): decisions were absurd (let’s stop doing tests and send scrum masters home), people started to be inefficient, and the code was the nastiest I had ever seen (thanks NGRX).
The more time passed, the more we were in a hurry. And you cannot deliver a good product when you are in a hurry. Actually, you can barely deliver anything when you are in a hurry.
We should have listened to you guys
I saw one of the top-decision people of the project a month ago.
I was having an afterwork with some former colleagues from this project. The former team was gathering to take news and have a nice time, when our ex-client came by the pub we were at.
We happily discussed with him, and here is one thing he told us: we should have listened to you guys.
After two years, this was the post-mortem conclusion of the project.
Sometimes, clients will not listen to us. It is our duty to accept that. Remember, clients experience fear. And fear is the mind killer. When you experience fear, it is extremely difficult to focus and take the good decisions.
On the other hands, our clients also do have a duty: it is to listen to the experts they are hiring. When your teams warn you about dangers and risks (probability of a danger to actually happen), you should listen to them.
What you should not do is :
Care too much about the velocity of the team: if features are delivered in due time, then it is OK. If features are not delivered in due time, then we need to reassert our estimations.
No one is going to die if features are not delivered in due time. It just means the due time was not the right time.
Interfere in the technical parts of the project. Wether we choose Jest or Karma, wether we choose Protractor or Cypress, wether we choose NGRX or not, the way we are going to code, should be almost irrelevant for you.
What you should be concerned by, on the other hand, is wether your app will be maintainable in the future or not.
Try to force your teams to follow your vision of a methodology.
I once worked for a client who literally took the SCRUM Methodology to transform it into some nonsense (3-hours sprint plannings to estimate two stories? Really?). No matter what methodology you are going to use: at least use it well or take responsibility for every customization you make.
Believe that because what we do is virtual, we can do it faster than any other product. That idea is simply wrong. The product we deliver allow us to do some tasks faster than other products, but building such complex applications takes time.
[Note] Please keep in mind that time is your most usefull resource. It is, to my opinion, better to allow more time to fewer developers, than hire more and more developers in order to meet your deadline. Generally speaking, if you need more developers to meet your deadline, then you might want to rethink your deadline.
Try to go fast.
Trying to go fast will most likely make you go slow
Let us conclude this post with one last example.
In 2019, I worked for a client who was developing a complex web application. The project had a really beautiful stack and some nice challenges: Angular 7 for the frontend, NestJS for the back, four squads and a beautiful automated integration environment.
Plus, they were working with the agile methodology, and they were apparently doing it good. So what could go wrong, right?
They were migrating from their previous stack to this new one. And, as they were migrating, they were also implementing new features.
Doing like this, they had so much pressure on them they did not take time to eat properly at lunchtime. Some of them were staying up late and working during the week-end. This client privileged developers quantity over time. We were constantly in a rush, and I struggled a lot trying to find the right components to use, how to implement my solutions in order not to break anything — and of course, I broke things.
I left this project with a bitter taste in mouth: I wanted so much to do a good work, but all I saw was a whole team rushing each and every day.
The fact this project was a mess was not due to any technical issue. It was due to the context and the management. We were trying to go fast and efficiently with SCRUM.
We were actually going slow.
I am now working on another project.
We take responsibility for the way we apply our agile methodology. Every release is a success. We do not try to meet impossible deadlines. My client’s customers are satisfied with our work. We are only two externals developers. Our team, counting the interns, is quite small. Time has been privileged over quantity.
And this helped me realize something really important.
We should not try to go fast. We should try to go efficient.
