“We’re agile” : why it is usually false and 3 essential practices to make it really happen

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.