TL ; DR : Agile aims at focusing all the developments to the value delivered to the end user. To do so, it’s critical that the developers and the end users understand each other well: any misunderstanding between them could result in features that are not perfectly aligned with the user needs. However, too often, agile’s implementations imply the disappearance of any link between dev and users; such a role being dedicated to the Product Owner.

This presents several risks for the delivery, mainly (i) misunderstandings thus misaligned features; (ii) low motivation for developers.

Reversely, implementing a direct link between devs and users will be beneficial for everyone.

Technically : (1) no more quiproquos; (2) innovations thanks to devs.

For the team dynamic: (3) dev teams feel proud and valued; (4) precious knowledge of business issues by dev; (5) less work for PO no longer interpreter.

The “no link dev / user” antipattern occurs because of good intentions but generates several risks

Good intention 1: the wishful thinking of “protecting” the developer from sollicitations from the end-users

• Most of the time, the idea is just to keep the dev focused so (s)he is not disturbed all the time when (s)he develops, an activity that requires focus.
• Of course, the developer is not a “hotline” for all the users, to be called when there’s an issue on the application. However, that shouldn’t make us jump to the conclusion that any direct exchanges between dev and users should be forbidden.
• Such exchanges should be feature-oriented and help both dev and user gain a common understanding of their relative issues. If every exchanges end up in a bug fixing / discovering session, then it means you have technical excellence issues. And you should deal with that in priority and not focus on your dev’s time schedule.

Good intention 2: the idea that users cannot handle exchanging with a “technical” people

• Users are most of the time very busy; PO / PM usually have a feeling that their time is precious and that it shouldn’t be wasted. And as users are not technical people, they fear that users will be frustrated if they exchange with dev, because they won’t understand what they say.
• Even though it is a good intention initially that drives this decision, it shows a huge lack of trust regarding your dev. They are able to handle such exchanges with users and there is no need for PO / PM to be an “interpreter”.

Here are the risks implied by such practices.

Risk 1 : the more intermediaries you have, the more misunderstandings you get

• If the User tells something to its Business Owner; who then repeats it to the Product Owner; that validates the need with the Product Manager; before finally talking about it with the Developer…
• … there is a high chance that some information has been lost in all the process

A video illustrates better than 1000 words 👇👇👇

Risk 2: lack of focus of developers on delivering value to the end-user

• Of course if you can never freely exchange with the end-user, it’s harder to understand how what you do impacts positively its work.
• It creates frustration and can have the downside effect of having developers focusing mostly on achieving technical tasks rather than focusing on delivering value.

Such lack of focus is detrimental to both the technical realizations and the team dynamic.

Three technical benefits, of enabling dialogue between developers and users

By putting in place regular and direct exchanges between developers and end-users, your delivery will improve.

Benefit 1: no quiproquos

By discussing together, we create a common language (what Domain-Driven Design calls “ubiquitous language”). The same word has the same meaning for the user and the dev; any ambiguity can be solved most quickly. It ensures that the features will correctly deliver value: when the users asks for “something”, there will be no misinterpretation of this “something” by the dev.

Benefit 2: innovation opportunities thanks to devs

Developers spend a lot of time developing applications; therefore they do get a lot of ideas in order to improve them and better the service they are delivering to the users. With this kind of exchanges, it encourages developers to pitch such ideas and to validate right now that they’re on target.

It does make sense if you look at the numbers, 1 agile team = 5 devs + 1 PO; we shouldn’t be surprised if at least 50% of innovation ideas come from devs that are 5 times more than POs.

Three benefits for the team dynamic, of enabling dialogue between developers and users

A better team dynamic is something you should aim for as it will result in delivering high quality products.

Benefit 3: dev team feeling valued

We owe developers to have a feeling of self-accomplishment through their work. They must feel proud and valued of what they do. There is no better way to do it than making developers talk with their end client, assumedly satisfied with the application. Of course, things might get messy sometimes and the users might be unsatisfied. If so, there should not be as well, any “protection” towards dev that must understand why their work hasn’t given full satisfaction.

Benefit 4: pushing devs to master user issues

Through dialogue, developers will tend to be business / user experts, which is invaluable. Less quiproquos as mentionned, but it goes further. Their knowledge is very precious within the team, because they will be able to fully understand by themselves the issues at stake. And their vigilance is precious: the more the better when it’s about making the right choices of features / prioritization.

Benefit 5 : less work for PO/PM

If dev and users can have direct exchanges by themselves, the PO/PM can focus on more value-added tasks. Being just an interpreter is not only time-consuming and not very satisfying, it’s not the best manner of employing their time for POs/PMs that usually have a lot to deal with on their plate.

Instead of translating between these two world, one interesting occupation should be to identify how the communication and the flow of information could be intensified between users and devs.

What about these “exchanges” ? How to put them in place ?

Two quick ideas here:

• Use one of the several agile meetings to put them in place, for instance sprint planning or backlog refinement
• Let them (devs & users) decide by themselves! They’re grown-up (most of the time) and they can figure it out.

You want to debunk the false belief of “no exchanges between devs and users” ? Join us:

careers.loreal.com

Interested about tech like us? Get in touch with us and stay tuned for more articles to come.

Five benefits of making your developers talk with your end-users was originally published in Beauty Tomorrow on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL ; DR : Nowadays agile frameworks like SAFe and Scrum are criticized a lot.

This is for a reason: first, frameworks tend to normalize ways of working which is anti-agile; second, institutes behind frameworks are most of the time more interested in making money, than making agile better; third, frameworks might lead you to fail your agile transformation and “throw the agility baby out with the water”.

However frameworks do bring a lot to agility: (i) they are reinsuring for stakeholders that might not buy in agile without; (ii) even if superficial, they are a great learning starting point; (iii) at the end of the day, it gets people interested about agile and there’s no such thing as bad publicity.

My recommandations regarding frameworks: (1) see them like a table of contents not like a guide / gourou; (2) don’t shame agile newbies, beginning with SAFe or Scrum, pull them upwards; (3) be clear with stakeholders that frameworks are not a silver bullet towards agility.

A quick definition of frameworks: they are methodological guides that define good practices and ways of implementing agile. Two of the most famous agile frameworks are Scrum and SAFe.

Scrum is twenty years old and has created roles like Product Owners or Scrum Masters; items like backlog (prioritized list of functionalities to develop) and ceremonials like sprint plannings.

SAFe is more recent but is very renowned in the IT world as it’s supposed to help you achieve agility @Scale, namely, for a number above of 50 developers.

First a little confession : SAFe taught me huge deal about agile

I was certified SAFe Program Consultant (SPC) in november 2019 and it actually enabled to improve myself a lot about agile:

• First, I had to study hard. The certification is tough. I had 4 days of course with 2 high-level teachers, each of them with several years of agile transformation experience. You have to study for at least 10–15 hours to make it through the exam which is a hard multiple choice questionnaire.
• Second, you know better where to look to deep dive into agile. You cannot deep dive in all the topics are mentionned in SAFe before the certification. But afterwards, it was very interesting for me to dig further into topics. For instance, I bought, read and studied books about DevOps or Lean Software Development (which constitutes the theoretical basis of SAFe). Thanks to SAFe, I knew these books were references on the matter and it had already given me a first understanding of it so the books were not unaccessible for me.
• Third, “you’re certified? So you’re an expert”. Good or bad, deserved or not, once you’re certified, you’re seen as an expert of agility. Quite concretely, it implied for me to give trainings to many people in my company. The training and the expert posture pushed me to challenge myself even harder which helped me improve myself even more.

You should be careful with frameworks can easily lead to agile antipatterns

Nonetheless, let’s keep in mind that most of the critics about frameworks like SAFe or Scrum are justified:

• They tend to normalize when agile theoretically strongly relies upon auto-organization to deliver value. Frameworks push us to apply rules that are supposed to be agile without understanding how agile could help us and to what extent following these rules is agile. Therefore it might make things more rigid and making us diverge from our goals with antipatterns like “we do that because it’s in the framework not because it brings value to the user”.
• Institutes behind frameworks have marketing / sales objectives. Just like any business, they want to make money through certifications and providing coaches. The more people know them, the better for them. It introduces a bias towards easier and lower quality certifications that are therefore less relevant. Moreover, to appear the most relevant on the theoretical plan, they tend to gather many theoretical elements even if the whole lacks consistency

For instance, with SAFe, it seems that as soon as there is a new trendy buzzword, they have to include it in the framework which ends up looking like a “patchwork”-framework

• Consequence of the two first points, you might not succeed in your agile transformation only thanks to the implementation of SAFe or Scrum. There’s a high risk then, that the initial buy-in of sponsors gets replaced with a strong opposition not only against the framework but also against agility in itself. What we could call throw out agility baby with the bath water.

Many prominent actors in the software world have put emphasis about the agile antipatterns brough by frameworks ; I like a lot the one of Ron Jeffries (one of the signatory of the Agile Manifesto) “Dark Scrum”.

However, it would be wrong to completely discard frameworks because they also bring a big deal to agility

Despite all their flaws, I still believe frameworks can be useful for agility:

• The “patchwork” aspect makes the whole framework less convincing intellectually; however it gathers a lot of informations in the same place and it’s a good starting point. Of course it doesn’t make quite sense to gather in SAFe Lean Software Development principles; DevOps practices and Design Thinking methodology. But still, it’s still useful just to know that these stuff exist in the IT ecosystem and to be able to find easily the relevant books on SAFe website.
• Big fat frameworks like SAFe are reinsuring for stakeholders. They can picture themselves in it and they can see their teams in it. Of course agile is not supposed to work this way: stakeholders’ focus should rather be on how to picture developers and themselves, but if it’s the only way to get an initial buy-in, I’ll take it.

• Good or bad, they make people talk about agility. It remains publicity and publicity is never bad. Even Scrum of SAFe or another framework are not the best way to achieve agility, they might still be smart enough to take hindsight and not follow religiously the framework. This is the exact path I took. Eventually, so many people go into agile through this frameworks that they cannot be 100% bad.

Three recommandations to make the best of frameworks

To sum up, I think that frameworks are “good servants but bad masters”; use them wisely:

• See the framework as a table of contents that can guide you towards more detailled content that will help upskilling you or anyone that want to be better at agile. And most of the time, frameworks do rely a lot on detailled content written in books, so make the effort to go further than only the superficial presentation for the framework and read the raw content.
• Don’t shame beginners that are enthusiastic about frameworks as they start their agile journey. It will just make them feel bad and once again, enthusiasm about agile even if it’s through a questionnable framework is still positive and must be encouraged. As a more experienced agilist though, you should pull them up towards better ways of achieving agility. The journey is not over. Help them achieve and keep a learning spirit.
• When it comes to stakeholders, be very careful to handle their expectations wisely to avoid the “throw out the baby with the shower water” effect. It’s okay to start with a framework be it SAFe, Scrum, XP, Kanban; but stakeholders should be aware of the fact that it’s not enough to generate all the benefits of agility. Therefore, communicate clearly about the fact that it’s only the starting point of the journey and that the rules within the frameworks should not be followed eternally to the letter.

You want to learn more about agility and the wise use of frameworks ? Join us:

careers.loreal.com

Interested about tech like us? Get in touch with us and stay tuned for more articles to come.

Why you should be careful with “agile frameworks” and three recommandations to make the most of it was originally published in Beauty Tomorrow on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s time for our final chapter on Datawarehousing.

We already discussed :

#1 ETL vs ELT & BigQuery choice

#2 Secure the Data access

Today we’ll discuss data Governancy and Deployment !

Governancy

A successful project starts with strong executive sponsorship in line with the organization’s business strategy.

It’s not so easy to develop a data-driven culture, so we clearly defined new ways of working with the business team, the product owner, etc.

We have decided to let business team build their use case on what we call the consumption layer, based on the transformed & prepared data called shared domain layer.

The most important information is the responsibility model, which means that a Domain Product Owner is in charge of the complete life cycle, definition, access and evolution of its data.

Deployment

On how we deploy this new platform with all its capabilities and guidance, here are the principles that the data platform team is adopting:

And here is below the set of tools chosen with industrialization at the heart of these choices (the best example is probably Terraform, as Infrastructure As Code is a standard to be adopted without any doubt to be sure that everyone does the same work everywhere)

Additions to this template should be proposed on GitHub to the entire company’s technical team to reuse (and contribute) to the code.

In the end, from a purely technical point of view, we have something like this

Again, don’t forget to use the ETL model and transform/aggregate the data as much as possible in BigQuery using only SQL (again a standard).

All the technicals elements are shared here :

https://cloud.google.com/blog/products/serverless/loreal-combines-google-cloud-serverless-and-data-offerings

Any ideas or comments ? Contact me :)

Back to the future of the Datawarehouse Episode 3/3 was originally published in Beauty Tomorrow on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL ; DR :

I’m sure you’ve already heard this sarcastic phrase “IT projects are always late”. It doesn’t make sense for two main reasons:

• First, an IT project is highly unpredictible. It goes back to the combined complexity of computer systems and users needs. Therefore, it’s impossible to anticipate a priori everything that could happen during an IT project. Hence, speaking of “delays” doesn’t make sense : how can we be late if we’re not able to anticipate the duration of something in the first hand ?
• Second, planning is the last thing you want to focus on when developing an application. Shipping features within the expected timeframe but without bringing value to your end users is useless. Focus on the value delivered. That’s the only thing that matters.
• Finally, if you’re absolutely required to give planning estimations, do it wisely. Perform estimation of small batches of work which will be more accurate. Actualize a lot these estimations. And most importantly: communicate with a lot of caution about these timing issues for the reasons mentioned above.

When it comes to IT, the notion of “being late” / “delay” doesn’t apply

An IT product / project makes you deal with two complexities: (1) computer’s complexity and (2) users’ needs complexity. This makes it impossible to define or measure rigorously any delays.

Computer’s complexity: an IT project being late would mean you can anticipate all the implementation caveats before even starting it

Let’s picture ourselves a quite classic story to illustrate this point.

• You’ve planned on shipping a feature at the end of week 1
• Once you start building the feature, you realize that you need first to perform a major upgrade of a technical brick.
• The feature you’re developing depends on this upgrade, and without it, you won’t finish it
• You need one week to perform the upgrade and you will only be able to ship the feature before the end of week 2

Is it a delay?

• We were not able to identify the need of the upgrade in the first place, the scope of what had to be done changed after this identification.
• If it had been identified before, it would be correct to say that we were “late”. As it had not, it cannot be said that it was a delay.
• One might argue that we should have been able to identify anything from the start but that’s just impossible as we’ll explain it afterwards.
• Thus, NO, it’s not safe to say that the feature was delayed in this context.

This kind of issue actually goes back to the complexity of computer systems that consists in two main aspects.

First “intrinsic complexity”: an IT system is composed of several different components. (A) The behavior of the whole system cannot be reduced to the sum of the behavior of all its components. This makes quite harder the identification of causal links in the system. And therefore, (B) the same action performed at two different moments doesn’t imply the same results.

As a consequence, you will never be able to anticipate everything without a holistic view (A) and even if you can anticipate some things, the behavior of components might not be the same over time (B).

Second “interdependency complexity”, an IT system never lives in isolation. Softwares rely on other systems, libraries, APIs. Softwares are in the end deployed on servers that are composed of hardware devices, fueled by electricity and so on. You are not alone whenever you develop software and you cannot secure and cross-check that all the “partners” you rely upon won’t block you.

As a consequence, issues will happen and they will make your job harder; you cannot control everything, especially when it comes to external partners. That’s a fact and you have to deal with it.

Users needs’ complexity: you cannot forecast all the users needs regarding a tool without showing it to them. You cannot do it by anticipation

Another anecdote to illustrate this point:

• Back to the early days of Google, they conducted user interviews to identify if people would rather have a long list of results whenever they were searching for something.
• 10 ? 20 ? 30 ? The users told they wanted to have “as much results as possible”.
• When Google implemented it, they realized that their users weren’t happy: the higher number of results induced a slower response speed. In the end, users would rather have less results but a quicker response speed.
• They wouldn’t have been able to identify this without showing the working website to the users.

This time, once again, we cannot say that a feature is delayed just because it wasn’t shipped within the expected timeframe because of a misunderstood user need. It’s just impossible to anticipate the user experience before you have a tool.

Just like computers, humans are complex and you cannot anticipate all the functionalities that they would have in a given tool without showing them prototypes or a beta version of the application. With all the user research in the world, you won’t be able to fully anticipate these needs. Hence, it doesn’t make sense to expect a software “not to be delayed”: the timeframe will be continuously adjusted to emerging user needs.

What’s next then ? If planning is not the right thing to measure, how can we handle efficiently IT projects ?

Monitor the value delivered by a tool and not the fact it’s been developed in the expected timeframe

Focus on the right thing: value delivered to the user.

• Go talk to your users and ask him bluntly if the software you’re giving him access to is useful for him. You can do that during demonstrations or schedule ad hoc meetings. How you do it doesn’t matter as long as you do it. For instance, Reed Hastings Netflix’s CEO has a customer-testing session every three months.
• Do not only focus on what the user says, use analytic tools, observe the behavior in order not to biase this analysis. Remember that as the Google users mentioned above, users are often wrong about what they need. I’ve deep dived more on the topic in this article about MRI for kids.
• Prioritize your work accordingly. The only reason why a given feature is on the roadmap should be that it delights our user. Period. It should not be because the CEO or a sponsor likes it. It should not be because it’s a feature we’ve put on our roadmap for a long time.

If you still need to provide visibility on planning, be very careful with estimations and communication

Sometimes, your sponsors will be very pushy and agressive about plannings and deadlines. Thus, you might have to give them “timing estimations” and answer to questions like “are we late ?”.

• Small batches of work are key in order to give more predictable estimations. By developing software incrementally and trying to have a software always releasable, many things will be easier and more predictable. For instance, all we said about interdependencies remain true. But by being more incremental, you will identify dependency incrementally and deal with them one by one without having the complexity of dealing with their combined impact.
• You can also estimate higher volume of work. But when doing so, try to do it by using references to past projects : “the amount of work to perform broadly corresponds to half of this other project we’ve finished a few months ago”. And use some margin.
• Actualize a lot your estimations. Planning should always refer to the process of thinking about estimates and not about the “plan” in itself. As most of your initial estimations will be false, make sure you go back to them quite often. Scrum advocates planning adjustments at every two week-sprints which is a good rule of thumb.
• Most importantly: communicate with a lot of caution about a given project / product being developed on schedule or not. It doesn’t mean that you should always be pessimistic and put an extra margin of 200% on any roadmap you’re presenting. But be very transparent about the fact that any estimation about an IT task is most of the time not reliable on the long run. More ambitiously, you should also advocate the right ways to think about IT : your sponsors are able to understand that roadmaps and timeframes shouldn’t be our primary focus.

Tired about people being focused on IT products / projects being late or on track ? Join us:

careers.loreal.com

Interested about tech like us? Get in touch with us and stay tuned for more articles to come.

Don’t focus on planning, focus on value was originally published in Beauty Tomorrow on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL ; DR
Most of the time, agile is summed up by organizational aspects: new positions, new meetings. However, these aspects are only agile by name and are mostly “good practices” (well defined roles, clear meetings’ objectives etc.). They do matter, but they won’t help get the whole value that agile could bring you.
Therefore you should rather put a high emphasis on the three following aspects along your agile transformation:

• Achieve technical excellence (TDD, DevOps, decoupled architecture)
• Implement a true link with end user
• Shift from “cost/quality/delay” project-paradigm to “value delivered” product-paradigm

Agile is too often summed up by new meetings and new positions

Whenever an agile transformation is initiated, the focus is most of the time put on organisational aspects.

New meetings
Several new meetings are put in place. And wording is important:

• The developments are now sequenced in “sprints” (between 1 and 4 weeks)
• The development team plans the content of what will be developed during a “sprint planning”.
• Everyday, teams gather to exchange on what they’re currently working and what is blocking them, that’s the “daily stand up”

• At the end of each sprint, the developers broadcast what they have achieved during a “demo” (and applauses are in order)
• Finally, you discuss about the improvement axis during a “retrospective”…

New positions

• What used to be the project leader is now either a Product Owner (PO) either a Product Manager (PM); (s)he is now responsible of the backlog’s priorities — which used to be the specifications
• Scrum masters enter the org charts with the responsibility of ensuring that agile is properly implemented
• Architects become tech leads
• The developers keep a similar role but are now gathered in smaller “two-pizza” teams…

It’s the easiest way to go when you begin but you won’t generate much benefits from it

Be careful because even though (i) these are most of the time the entry points into agility and (ii) these practices will generate some benefits to you, they are in no way sufficient in order to achieve agility and the huge benefits it can generate.

Why it’s the easiest way
-> First, any transformation can be worrisome; therefore creating right away new roles / positions has a reassuring effect for everyone that can picture oneself in the “new” world. It even remains reasurring if it just means putting “agile” in front of any old positions’ name (agile PMO, agile Project Leader, agile Program Manager etc.).
-> Second, the meetings and the whole agile ceremonial has a quite energetic and dynamic effect. Meetings’ objectives are well-defined. They are time-boxed and there’s even someone in charge of time-keeping. Gathering people in smaller teams reinforces communication and forces more transversality
-> Third, the numerous meetings and new activities to perform are of course chronophage which keep people busy a lot and give them the impression they’re effective. However if the time spent is not allocated on the right work items, your effectiveness could as well be only a false impression.

Why it won’t generate huge benefits
There are three main aspects that will surely block agile from delivering its maximal value to you:

• Technical excellence: without being careful about how you design your code and how you architecture it, the complexity will increase more and more as you ship more features. In the end, your software will get harder to change. You can create any meetings or any roles you want but insufflate this kind of excellence rigor is not something you can improvize and without it you risk facing the following vicious circle:

• Link with end-user: agile is by essence a software methodology that aims at delivering value to the end user. That means that you have to actually talk and put it in the hands of these users. However, with many new positions like Product Owners, Product Managers or Business Owners, you introduce stratifications and rigidity between our product and the end-user. Yet, anything that gets between our product and our user is delaying feedbacks and thus, is increasing the risk of developing a product that doesn’t fit the user’s problem
• Project/product mindset : most of the time, when agile meetings and agile positions are implemented, people still have a project-oriented mindset. It means that they judge the success of the development of an application on the fact it was delivered within the expected timeframe without budget exceedance. Once again, this kind of mentality moves us away from our sole objective that is delivering value to our customer. Shipping a beautiful application in the expected timeframe without budget exceedance doesn’t have any interest AT ALL if the user won’t use it in the end.

The three practices you need to truly make agile happening

Guarantee technical excellence of the teams

This implies putting in place the technical elements necessary to make agility possible over time; the three main aspects are

• (1) DevOps approaches to be able to have a software that you can deploy multiple times a day, incrementally so that your end-user can use it and give you feedbacks
• (2) modular architecture to decouple the different modules of your application so you can change one module without fearing to introduce regressions in other modules
• (3) TDD / self-testing deployment approaches to make the system “bug-free”. A common error in implementing agile is to keep QA/testing a separate aspect from developers. Quite the opposite, we should make them work together in order not to fix bug but rather to make the system bug-free

(more on that in this other article)

Establish a strong link with the end-user

Agile aims at delivering value to the user by solving a problem they encounter. To be sure that we are solving the right problem, we need regular exchanges throughout the product lifecycle. This should include as well exchanges between the end users and the developers. PM / PO shouldn’t be the only privilegded people to be allowed to talk to the end users. To do that, you should set up meetings dedicated (1) to validate the features developed with a sample end users ; (2) to engage discussion to help the developers and the users to gain a common understanding and language of what needs to be done. (Nb : this is what Domain-Driven Design puts forward as ubiquitous language.)

Change the culture of the organization from a project mindset to a product mindset

Everyone’s objective should no longer be “to finalize a project on time” but “to deliver a product that solves a problem encountered by our end-users”. This means being able to measure the value delivered and use it to orient our product’s lifecycle in time. This might sound scary and expensive but it is not “how will we be sure we don’t throw money down the drain ?”. Actually, you will still monitor your expenses but you will just make sure it is well allocated because it generates value to your end users.

If you are willing to do true and not fake agile, join us: https://careers.loreal.com/fr_FR/content/HOME.

Interested about tech like us? Get in touch with us and stay tuned for more article to come.

“We’re agile” : why it is usually false and 3 essential practices to make it really happen was originally published in Beauty Tomorrow on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is TDD ?

TDD is a software development approach where you make incrementally emerge code and tests at the same time. In the end, all the code that is being written, developed is covered by tests. It can be summed up by the repetition of this cycle red / green / refactor.

Here is how the cycle works for a given feature :

RED

• Start by writing a test that describes part of the behavior of the feature
• If you run the test, it will fail because the code hasn’t been written yet
• It’s the first part, make a failing test : RED

GREEN

• Write the minimum amount of code to make the test pass
• “Minimum” is key here, the code should grow incrementally by baby steps
• Thus it’s OK at this step to be quick and dirty, copy paste lines of code stack overflow etc
• Run the test, it must pass: GREEN

REFACTOR

• Now you have code that behaves as expected because it passes your test.
• If you change this code, you will see right away if it doesn’t have the behavior expected anymore thanks to the test
• Therefore, it makes you quite comfortable to improve its design without fearing breaking its right behavior : REFACTOR

At this step, you can use design patterns or any good practices of code design. Nonetheless, even if the refactor phasis is a little longer, it should not take too much time as this cycle is meant to remain quick and repeated many times. Of course, having been focused on incremental and baby steps makes this phasis shorter as well which is a good thing.

What it is not ?

TDD is often misunderstood ; these are two misconceptions about it.

Not a test first approach
A test first approach is quite different from TDD. For one feature or one technical component, you create all the test cases verifying its behavior before. Usually, it’s a senior member of the team that creates them so that a junior can have “safeguards” when he develops its code to check that it brings the right behavior.

Even if this approach can appear right on the paper, it has two important drawbacks :
First, it forces the senior developer to anticipate how the code should work beforehand with all the test cases. However, all the agile methodologies rely on this heavy assumption that it’s impossible, before writing code, to anticipate all the technical problematics you might run into.
Second, as the code and the tests don’t grow together simultaneously, the test use cases might be less fine-grained than what they would have been in TDD approach. Yes, you would have the validation of the expected behavior. But it might be harder to make emerge the right code for that, when TDD drives you all along the way with better-sized tests.

Behavior driven rather than technical driven
A second misconception makes tests focused not on behavior but on technical elements (classes, methods, functions). In this case, you would not be writing a test to validate a business behavior. You would be writing one test for one class or one test for one method.
The main drawback of this approach is that you couple your tests to the technical implementation of your software. This makes refactoring way more difficult : tests aren’t anymore a safeguard against changing how a component validates a functional behavior, it’s a safeguard against the current technical implementation of one given element. In the end, it makes it harder to change the business behavior of software, which makes it per se a bad approach because any proper software development methodologies aims at making software easier and not harder to change.

Two experts of TDD go further on that topic :
A famous reference on that by Ian Cooper, a TDD purist : TDD here did it all went wrong
Another reference by Valentina Cupac explaining the difference between the two approaches : TDD and clean architecture, driven by behavior

One obvious benefit : an automated test suite

The main benefit from having automated test suite is that, well, the tests are automated meaning they’re not performed by human. This brings three benefits :

• No schedule : tests can be run whenever you want by the machine
• No time limit : machines can repeatedly run test cases for long hours
• As many tests as you like : you can run tests in parallel on different machines which enables you to be way more exhaustive in your coverage

But there’s more than that !

1 : Always up to date documentation
Your tests constitute a “living documentation”, at any time, the behavior of the system is tracked in all the test use cases. Whenever the behavior changes, the tests change accordinly therefore it’s always up to date.
Therefore you don’t need anymore to plan retro-documentation session or create documentation US to track system’s behavior.

2 : A cleaner code thanks to a continuous and disciplined refactoring
As explained before, the inclusion of refactoring all along the TDD red/green/refactor cycles is extremely powerful. The code is continuously improved and refined which has a very high return on the long run.
Without that, refactoring is always deferred which results in a dirty codebase you have to clean every 3–4 years with a huge refactoring project.

3 : A decoupled architecture
TDD makes you focusing by design, on having small testable components. The only way to keep your tests simple is to have small decoupled components. As soon as components are imbricated and grow too big, it’s way more complex to test them. Therefore, TDD helps you get small decoupled components tested in isolation.
The benefits of a decoupled architecture are numerous, to name only a few: bugs are easier to localize, changes / bug fixes might not bring regressions at unexpected places, developments can be paralellized.

If you are interested in making making tech efficient with TDD, join us:

careers.loreal.com

Interested about tech like us? Get in touch with us and stay tuned for more articles to come.

There’s more in TDD than only automated tests was originally published in Beauty Tomorrow on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s hard to deliver value to users

Where is value?

While we build products, delivering value is always our number 1 focus. An application has no interest if it doesn’t bring value and help a user solve a problem it is facing. However, it’s always hard to deliver value because value in itself is always hard to identify.

As PM / product builder, we’re always biased towards solution. We always have a tendency to think that our product is delivering value to the users. It’s scary and difficult to humbly ask your end-users if the product is efficient in solving its problem, if it’s giving him a fulfilling experience or solving its needs. And if we do, users might not be able to answer right to these questions.

In fact, we must treat with cautious even the opinion of the most willing-to-help users.

When users know what they want

• What they want may change: users’ need might change and fluctuate
• They might have difficulties to verbalize what they want, which makes it harder for a PM to understand the right need behind
• They might know what they want and verbalize it clearly but be biased towards an answer, for instance they might just twist their answer because they want to give you the answer that pleases you

When users don’t know what they want

• In that case, there’s hardly a chance you can get a clear explanation of what would bring value to the users. Worst case scenario, users might not even know the solution to their problem exist

When users know what they want, it’s easier, with careful analysis and awareness of biases dangers, you might be able to identify their needs.
But the last point is the hardest one, how can you help someone that can’t know how he/she could be helped?

Let’s hear a quick story about how someone achieved great success facing such problematic.

How a terrifying MRI was transformed into a playful pirate vessel

That’s Doug Dietz story, twenty year engineer veteran at General Electrics, as it is related in the great book Creative Confidence written by Tom and David Kelley.

Context: an MRI specialist on a trip to see its device in action

• Doug Dietz worked at General Electrics for several years and worked on several improvements on the very famous and succesful MRI. A device that enables to see “magically” inside the body of a patient without any physical pain for him.
• The device improved by Doug’s work was installed in several hospitals and had even been submitted for an Excellence award: “Oscars of design”.
• When Doug had the opportunity to see his invention in action; he jumped on it and went to a hospital in order to see his machine in action.

Trigger: a kid that seems to dislike the user experience of the device

• As he was about to leave, he noticed a child with his mother that was actually very afraid of going inside the MRI. Despite the encouragements of her parents, the kid was still terrified. In the end, she was so scared that the technician had to call an anesthesiologist to sedate her.
• This helped Doug understanding that even his device was extremely efficient, its kid-experience could be improved. And that it was actually a great opportunity to make MRI more valuable through a fresh perspective so that kids feel reinsured and nurtured in the MRI environment

Solution: a kid-centric device to make MRI a positive and memorable experience

• Through a lot of exchanges, workshops and prototyping Doug transformed MRI into a kid’s adventure story. The device is rebranded into a pirate vessel and the kid is the hero of an adventure in this vessel. They even pushed the realism to create a script for the technician so young patients are lead in the adventure.
• Of course the results were measurable and showed an impressive success : the satisfaction of patient increased and the need of sedation reduced a lot accordingly. Nonetheless, the biggest measure of user satisfaction for Doug was seeing a little girl asking to her mom after going out of the MRI “can we come back tomorrow?” (as a matter of fact, a feedback he got from unbiased observation and not direct interviews)

Three ideas to help you dealing with this kind of situations: data; unbiasedness to raise empathy; open-mind

Good data don’t lie

But it might be hard to perceive the right signal when you listen to it: in the MRI, there was this statistic that 80% of children were sedated, but was Doug aware of the stat? And was it possible to establish the link between the sedation and the fact that MRI was scary for kids?

Unbiased observation is key

Doug Dietz discovered about how kids were terrified, only by chance, when he was in the hallways and just observed silently the family with the little girl entering the MRI.

There’s hardly a chance that he would have been aware of the problem and able to develop empathy without this kind of unbiased observation. By asking directly a kid, he/she might either censored itself or just couldn’t have pictured a more user-friendly way to go through MRI

Always keep an open mind

Even if your device / product is succesful and state-of-the-art, there’s always room for improvement. Therefore, keep doing user research, continuous discovery and cycles of prototyping along with confrountation of profiles from different services and industries. It will give you a broader perspective.

If you are interested in making making tech efficient with user-centric tools, join us:

Homepage | L’Oréal Careers

Interested about tech like us? Get in touch with us and stay tuned for more articles to come.

Focus on what your user doesn’t even know she/he wants was originally published in Beauty Tomorrow on Medium, where people are continuing the conversation by highlighting and responding to this story.

Two-pizza teams: an Amazon best practice but not only

There are not many IT concepts / organizational concepts that are as famous as the “two-pizza teams” motto of Amazon.

Jeff Bezos once mentionned that he had instituted a rule: the teams in Amazon should be small enough to be fed with 2 pizzas. The idea behind that was to increase their efficiency: intuitively, less people means less need of coordination and keeping people up to date

This rule is so “catchy” that IT literature makes numerous references to it:
- Agile theory emphasizes the idea of small delivery teams <10 people auto-organized
- DevOps advocates small, market-oriented, pluridisciplinary teams in order to stimulate autonomy and reduce technical dependencies
- Some famous “small” product teams are renowned: Apple’s iPhoto was built by 5 developers (source); there were 13 people in Instagram product teams when it was acquired for 1 billion by Facebook (source)

Bref, smaller teams appears to be more relevant to deliver software.

Why less is better: fewer people enhances communication

As we bring more people into a project, the communication complexity increases quadratically:
- If there is only 3 people in the team => 3 communication links;
- If the team is composed of 6 people => 15 communication links;
- If the team is composed of 12 people => 66 communication links.

Thus, we see that by adding people, the number of intercommunication grows way more than only the number of people added: between 6 and 12, we multiply by 4 not by 2 the intercommunication possibilities.

There’s another way of seeing it; if we have one team already formed and we decide to add one people in the team, we generate a lot of new intercommunication possibilities:
- From 3 to 4 people ->we add 3 communication links;
- From 6 to 7 people -> we add 6 communication links;
- From 12 to 13 people -> we add 12 communication links.
We see that the number of new communication links = the number of people in the initial team, logically each initial teammember has 1 link with the new teammember.

The anthropologist Hackmann also made this reasonning and points out the “process problems” that get exponentially more severe as the number of people in a team grows. He identifies two main issues:
- The first is the communication links as explained before, the intrinsic complexity of “keeping anyone up to date”;
- The second is the fact that larger teams will get overconfident with the false feeling that they will be able to be more efficient as they are more numerous.

The “more resource antipattern”: why adding more people to an ailing project is probably making things worse

This reasonning has initially been introduced by Jeff Brookes in The mythical man-month with the following story / vicious circle:
- An ailing project is experiencing delays
- Therefore, the sponsors bring in more people
- Therefore, it adds complexity regarding communication for the reasons presented above
- Therefore, the delays are more severe

In other words, increasing the number of people on a delayed project is unlikely to make things better; quite the opposite actually, it’s surely making things worse.

To illustrate this point, Brookes uses the strong metaphor of tarpits. Big projects are like dinosaurs in tarpits. Bringing more people here would be the false belief that struggle and move in order to escape the tarpits will make things better. However, struggling and moving in tarpits is only making the situation worse.

Furthermore, it’s not only intercommunication that’s making things worse. When you add new people to a preexisting team, it also implies: (i) getting to know each other to achieve a good team dynamics; (ii) upskilling newcomers; (iii) performing work to secure contracts and HR aspects.

Reversely, smaller teams enable better communication which generates numerous benefits

By now, we’ve made clear that bigger teams are never the solution. Here are some illustrations of why the bettered communication in smaller teams that can be fed by two pizzas make them way more efficient.

On the skills level:
- Team members can be upskilled more quickly
- Better pluridisciplinarity therefore a more reactive team
- Reduced tendency to rely on experts that always risks to create bottlenecks

On the alignment level:
- A smaller team will be more engaged and solidar
- It’s also easier to orient fewer people towards a goal
- Fewer people will feel more accountable : that’s the Kitty Genovese effect

On the technical level:
- Smaller teams will more easily work in smaller batches with more incremental developments
- This will make continuous delivery easier with numerous other advantages
- As a consequence of Conway law, independant teams will generate modular and decoupled software components

In fine, your project will be more efficient, deliver faster and your teams will be happier.

If you are interested in making making tech efficient with right-sized teams, join us:

Homepage | L'Oréal Careers

Interested about tech like us? Get in touch with us and stay tuned for more articles to come.

What is the rational behind the “two-pizzas” team was originally published in Beauty Tomorrow on Medium, where people are continuing the conversation by highlighting and responding to this story.

Technical excellence and codebase’s complexity

Agility can be defined as a user-centric software development process that aims at delivering software in small batches to the end-user in order to get fast feedbacks and to generate knowledge.

Technical excellence consists of practices enabling softwares, products, applications, to be delivered fast, with high quality and be maintained without prohibitive costs in the long run.

In the context of this article, technical excellence will refer to three main areas, the constant focus on maintaining a high level of exigence on these aspects:
 — Decoupled architecture: the architecture consists of modular and independant components that are consistent functionnally ; one component serves different features and changing one feature of one component can be done in isolation from other components:
 — Self-testing development: developers are continuously implementing tests in order to validate that the code written has the expected behavior; TDD appears to be the most effective technic to do it
 — Automated deployment and continuous integration: codebase evolutions are merged as soon as possible (several times a day) and automatically deployed on prod-like environment to be tested (with automatic tests and manual — exploratory tests as well)

As you develop more and more features, the codebase gets bigger, it’s getting hard to understand it as a whole and all the interactions in it. These practices will help you control the increase of your codebase’s complexity:
 — Decoupled architecture keep changes localized, therefore complexity remains localized as well on a limited scope
 — Self-testing development forces you to keep small testable unities, along with decoupled architecture; furthermore you can detect regressions as soon as they arrive and help you knowing exactly the behavior of your system at all times
 — Automated deployment and continuous integration will help you focus on value-added tasks and synchronize teams regularly withou having to perform quick & dirty hot fixes because you deferred the painful integration of codebase’s evolutions

Antipattern: agility without technical excellence

At the beginning of a project, there might be a lot of enthusiasm. Delivery is fast in the beginning; agile processes enable the team to be very dynamic; users are happy to see features arriving “fast”
But if you haven’t been careful about the technical excellence the complexity of codebase grows,
 — 1 as you don’t automate test and still want to ship quickly to users, defects will begin to come and their number will grow;
 — 2 as you don’t automate deployment and implement CI, merges will get more and more painful and therefore you will naturally lean on doing them less often;
 — 3 with an intrincated architecture, developing a new feature gets complicated because it might have impacts on other part of your application; therefore (i) you’re reluctant to developing them, (ii) when you do so, inexplicable regressions might occur (and you’ll have difficulties identifying them without automated tests)

All is then gathered to have a nice vicious circle:

How your agile development process can benefit from technical excellence

Self-testing development will give you:
 — Better design through TDD approach, among other reasons because in order to have an effective testing strategy, tests must run fast and therefore testable units must be small and decoupled from each other
 — Faster feedback, because you don’t need to wait for painful merges or deployments and then for manual acceptance tests to check if your code behaves as expected, you can see it (and fix it) right away
 — Maintainability in the end, with an effective automated test suites, 1 there are less bugs because the system is defect free; 2 the test suite is a safe guard preventing you from changing behavior unpurposedly, quite the opposite it will help you continuously refactoring

Automated deployment / continuous integration:
 — It enables your teams to focus on the value-added task of developing feature for the end-user instead of (i) manually provisioning and deploying software; (ii) trying to fix all the defects happening because of a “merge hell”
 — You can figure out more rapidly your software’s behavior in “live conditions” because you can directly deploy it in prod-like environments
 — Make deployments and integration less painful because performed more often [(1) more used to it; (2) changes are smaller); (3) users give feedback more frequently]

Through a decoupled architecture:
 — Components are better isolated and therefore changes are located and so are their potential pbs. Therefore it’s way easier to add more and more features for users
 — With hexagonal architecture paradigm, business rules / business invariants are properly housed and protected which helps you focusing on business complexity without having to deal with “details” like data persistance or view aspects

What are the benefits for you?

In the end, you are winning on all sides:
On the technical side, it’s easier to develop new features and it’s actually the one thing expected from software, namely being easy to make change.

On the people side:
 — Users are more satisfied because they were able to give feedback regularly and the software given to them is reliable and efficient,
 — Teams are more engaged because they enjoy building new features instead of fixing bugs, moreover they can be proud of their work

On the financial side: costs are more predictible and controllable, revenues keep on increasing because satisfied users retain and refer to other people.

If you are willing to make agility right with us, join us: https://careers.loreal.com/fr_FR/content/HOME.

Interested about tech like us? Get in touch with us and stay tuned for more article to come.

The importance of tech excellence — there’s more in agility than only ceremonials was originally published in Beauty Tomorrow on Medium, where people are continuing the conversation by highlighting and responding to this story.

After a few years with positions of Product Owner / Product Manager in agile environments, a recent PM certification I passed made me realize how much being a PM means not only designing an IT solution right [doing the thing right] but also resolving the right problem for the user [doing the right thing].

On the one hand, since I’ve been a PM, I mainly focused my efforts on “doing the thing right”. Designing software is a hard job because it forces you to interact with the inherent complexity of computer systems.

Such systems are complex because they are among other things non-deterministic (a same action performed on two occurences can have different outcomes); no holistic vision; sum of component’s behavior doesn’t enable to predict the system’s behavior, etc.

Facing this, I’ve always thought about a PM’s mission to adapt its ways of working to deal optimally with these challenges. This is achieved through mainly two aspects :

1. Fostering technical excellence to achieve a sustainable and reliable product through advanced software design technics (TDD, BDD and DDD) jointly with DevOps and Automation.

2. Implementing lean and agile processes to enable efficient and short feedback loops that help achieving incremental objectives and delivering a flow of value to end-users.

On the other hand, since a few weeks I’ve had sort of a revelation that emphasized to me how much “doing the right thing” is equally important. One cannot stress enough how much you have to keep in mind as a PM creating a product that you are building it for someone, a user. This is as difficult as designing an efficient and sustainable solution as it makes you interact with the inherent complexity of human behavior.

It’s hard to define what makes human behavior complex. Some elements to be aware of in the context of product could be the following : users are easily biased towards a decision, asking them what they want might in itself influence them towards an answer ; even if they are unbiased, they might not be really aware of what’s best for them, of their “latent needs”. Something this quote wrongly attributed to Henry Ford synthezises quite well :

“If I had asked people what they wanted, they would have told me faster horses” Henry Ford (apocryph)

As a PM, it is then crucial to deal with this complexity in the whole lifecycle of product. To sum up how this takes place concretly, I like the definition of product design of Keenan Cummings

(i) Recognizing patterns of human behavior ;

(ii) discovering the motivations and impulses that drive those patterns ;

(iii) creating tools that improve or elevate the output of those behaviors.

This goes through two main fields of actions:
1. Do research to undertsand your users’ problems: focus on the problem first before to think about a solution; to understand your user, you need to observe them the most unbiasedly possible; and work iteratively with hypotheses statements you try to validate.

2. Conceive applications and make sure they solve the users’ problems: identify key features; design smart interfaces that guide users; take into account all the potential interactions of your user with them; build prototypes to validate your hypothesis then release a first version of your product and continuously adjust with feedbacks with the objective of maximizing product’s adoption.

Of course the point here is not to say that one of these two aspects is more important than the other: they are both equally crucial and necessary to build succesful products.

Being a product manager : doing the thing right… but also doing the right thing was originally published in Beauty Tomorrow on Medium, where people are continuing the conversation by highlighting and responding to this story.