How to internalise agile practices, how to make them your own

I like going to meetups, it’s the best place to gather feedback, ideas and absorb experiences from other people.

Not long ago I went to an agile meetup and a criticism I was listening to was from someone transitioning from waterfall to agile methodology, he was struggling with the “lack of a strict how-to in agile”.

I have to admit that waterfall is well structured and the rules are clear, explaining exactly which document you need to create, when and how. Moving from a waterfall company or team to another is easy, the steps in a waterfall process are the same, the naming and structure of a document is similar and the responsibilities within the team and organization are always well defined.

Innovation distribution curve and crossing the chasm ( copyrights)

But when we come to agile, there are several “flavours” with guidelines, suggestions or ideas, where the most typical comment is “do what works for your team”.

I have to agree that when you first look to an agile methodology there could be a sense of lost, non-agreement and not one single how-to that is followed 100%.

Each company or even teams within the same company, often use different solutions that are similar but are not the same. Responsibilities are often overlapped within multiple members or roles and a first look almost seems like there is a continue chaos.

…but it works, it is effective and no matter what agile “flavour” is adopted, in my opinion is a step forward to a more dynamic and resolutive team.

My suggestion for a successful waterfall to agile transition?


It doesn’t matter the agile flavour (scrum, kanban, lean), the biggest mentality shifts from waterfall to agile are:

How can we work towards solving those barriers?

The focus of every agile ceremony can be summarised with a simple word “communication”.

But what is “enough” information in a story? What is the level of interaction business/development? What is the best solution to manage the story progress?

You can find multiple answers and ideas for every single of this question and possibly I should write a specific article for each, but in reality everything always ends up with “whatever works in your team”, each team, each project, each environment is different and the solution will always be unique for each of us.

But then, how can we find “what works in our team?”

An interesting concept I learn in Shorinji Kempo (Japanese martial art) is shu (守) ha (破) ri (離), which roughly translates to “to protect, to detach, to break away”.

Shuhari in Japanese (wikimedia)

Personally I view those 3 steps as concentric cycles that repeat themselves and which are not unique to a physical activity, but can be applied to the learning process of any skill and discipline.

A simple, but useful example: Retrospective is not always celebrated and when it is, it is complaints only.

Here’s how the Shu Ha Ri progression could help.

A basic concept I think we often forget is mentioned here:

“Retrospectives aren’t just a time for complaints without action. Use retrospectives to find out what’s working so the team can continue to focus on those areas. Also, find out what’s not working and use the time to find creative solutions and develop an action plan. Continuous improvement is what sustains and drives development within an agile team, and retrospectives are a key part of that.”

Additional information



Agile practitioner, security fanatic, coffee addict, sci-fi fan, chess lover, Linux/Android user, Shorinji Kempo enthusiast.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Andrea Gigante

Agile practitioner, security fanatic, coffee addict, sci-fi fan, chess lover, Linux/Android user, Shorinji Kempo enthusiast.