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 (businessillustrator.com 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?

Communication.

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

• No document is the source of truth (only the small story)
• Business must be involved during the whole development process
• The team owns more responsibility on the delivery and a clear global knowledge of the direction and status is fundamental.

How can we work towards solving those barriers?

• by making sure each story has “enough” information for the team
• by making sure business is always present and able to provide a continuous cooperation during the process
• by recognising the effort and feedback from each team member, making sure cross teams dialogue exist

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)

• shu (守) “protect”, the stage of copying the technique and learning to do it exactly the way one has been taught
• ha (破) “detach”, the stage of making changes (changes which follow the original theory) to suit one’s own needs and specific characteristics
• ri (離) “break away”, the stage when one has mastered the knowledge and technique

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.

• Shu: First of all the team should schedule the ceremony at a regular rhythm. To begin with try to use one of the most popular techniques to run the retrospective with the “Start, Stop and Continue” solution, try to replicate the rules and suggestions as explained, creating a communication and identifying steps for the following weeks.
• Ha: The team is now progressing with the communication, the feedback and there is an improvement in their environment/process by following the agreed steps, but the team participation and the overall energy level could be better. So, start introducing different technics, try the “Good, Bad, Better, Best” or the “I like, I wish, I wonder”. Continues for some time and keep experimenting with various solutions or challenge the team in different ways.
• Ri: The team has moved away from the original “by the book” structure of their retrospective, it is now a more flow of information and feedback that everyone finds useful, using their unique working solution. It is effective, impactful, and adapts easily to the situation the team is facing identifying and reviewing actions taken or to be taken.

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

• Researching a bit more into shu-ha-ri concept, I’ve realise that Piaget’s theory of cognitive development has similar steps, here the wikipedia link if you are interested
• Shuhari is not a unique concept for Shorinji Kempo, but a common Japanese martial art concept (wikipedia link).