Ce site utilise Google Analytics. En continuant à naviguer, vous nous autorisez à déposer un cookie à des fins de mesure
En savoir plus ou s'opposer.
Les cookies Google Analytics
Ce site utilise des cookies de Google Analytics, ces cookies nous aident à identifier le contenu qui vous interesse le
plus ainsi qu'à repérer certains dysfonctionnements. Vos données de navigations sur ce site sont envoyées à Google Inc.
Nous avons bien pris en compte votre souhait de ne pas envoyer vos données de navigation à Google Inc.
NB: ce message va s'effacer tout seul au bout de 5 secondes.
In the previous parts of this series, I focused on my two first (quite long) takes on a project we started at the end of 2005. I left the project in early 2007, I came back in 2009, and left again in 2012. and this post is about a new come back (for a bit more than a year now) on this 12 years old project. I will try to expose lessons learned from this experience, from organizational and technical points of view.
In the first part of this series, I focused on the genesis of the monolith we started at the end of 2005. I left the project in early 2007. It was planned to grow quickly, then the team would have to adapt (in size and more...). I came back on the project in 2009, this post highlights new challenges we faced from organisational point of view, evolution we made (lots of experiments) and consequences until 2012 when I left again.
In the first part post (5 years ago...yes!), I talked about some refreshing visions on IT industry. It was quite rhetorical, now it’s time to illustrate with real examples from my experiences. 5 years later, sadly, I just have more examples...
The mainstream organisation is still quite far from Features Team, collocated teams and all other concepts that were proposed early by Agile advocates (and even Lean before Agile...). Even if Agile is more and more popular, it is often interpreted just as a method, missing crucial aspects.
So let's try to dive in details of these organisations, but I will not mention specific to avoid defamation.
I would like to write a post on this subject for a while (amongst lots of other…), and a post of Mike Cohn about Agile in the Age of Hyperspecialization reminds me the subject (in addition it is also a recurring subject at work for me). I wrote some comments on his blog, but I would like to detail a little bit here.
First of all, I am not confortable with the analogy done between manufacturing activities (or buildings and civil works) and IT industry, which basically leads to reduce developers to “simple” workers that could work in a production line (cf. Ford, with respect for manufacturing workers)…and I think that’s a point that is totally missed with hyper-specialisation.
I prefer other visions more suitable to our industry. In this first post, I will talk about “cultivate your code” analogy, “mentofacturing”, and feature teams approach. Then in a second post, I will dive into an illustration of what could be stereotypical organization nowadays with “hyperspecialization” and my vision (shared and applied in my team), which is best aligned with Agile and Lean principles from my point of view.