6 months working with SAFe(c) : my analysis

A friend: “Sami, you’re crazy !! You’re going to work in a transformation SAFe (c), you the agilist! But you read the article by Ken Schwaber? You saw the picture of the thing?”

Me: “Well yes I know, but as Dave Thomas says : Agile is not what you do, Agile is how you do it .I think we can hijack a tool like SAFe (c) and make it Agile … I’ll give it a try and we’ll see “

No, I will not spit on SAFe (c) as some have done. No, I do not make a block rejection of the proposed approach. Based on a 6-month experience of SAFe (c), I will try to give my analysis.

What is SAFe (c)

SAFe (c) is one of the large scale Agile framework with LeSS, Nexus, DAD, spotify model, etc. The goal of these frameworks is to provide agile frameworks on groups larger than a team (a set of teams, a company, etc.). All of these frames are based on the basic brick “Scrum” with several approaches and different philosophies.

SAFeDifferentiator

Unlike other Agile Frameworks, SAFe (c) has (strong) ambition to attack the company’s overall organization around Scrum teams. Rightly or wrongly it proposes an approach that allows the whole company to work in a Lean / Agile mode. One of SAFe’s main objectives  is the alignment of the company. To this end, it proposes an approach that allows the company to ensure that the teams are working on what counts, from top to bottom, and that there is no dispersion in the efforts provided.
SAFe (c) is also the only one to offer a well-structured and clear approach on how a business should be organized around agile teams. It means that for a non-agile company, the deployment path is clear and precise.

What makes SAFe so successful

A small comparative google trends between the research “LeSS agile” and “SAFe Agile” over the last four years shows the trend of adoption:

less agile, safe agile - Explore - Google Trends - Google Chrome

SAFe (c) is reassuring (since it is safe):

The creators of SAFe (c) have better identified potential users, their needs and how to sell them the product: Those who make the choice of Agile Frameworks, are not agilists but often sponsors who are not yet agile and who are looking to transform their business.

In an old world not yet Agile, the way to reassure is to provide a well-detailed and well-studied plan (at least in appearance). SAFe provides them with a plan that answers a lot of questions and uncertainties (what happens to my managers, what is the deployment roadmap, how do I measure my success, how do I manage dependencies)? Of course the reality is much more complex, and the more rigid the plan, the more it will fail …

SAFe (c) does not just deal with agility

I’m not even sure that agility is well taken into account. From my point of view, SAFe is above all a framework of alignment and predictability. It allows the company to work on the same objectives, with the same vision. This is done via the different layers offered, with their different backlogs. These different layers are essentially linked thanks to the elements of their respective backlogs (Epic, Feature, US).

SAFe also allows for better predictability at the development level. The teams make a big planning together every two months, engage on it. At the end of this iteration we measure the production of the teams and we calculate their predictability. This predictability helps to create more trust and honesty about commitments in the business.

Alignment and predictability … but at what price?

The risks of a SAFe deployment?

  • By deploying SAFe (c) we miss a strong recommendation for an Agile company:
    • Build as much as possible independent teams that can manage their product area, develop and deliver independently. The initial rule is that the people doing the work are those who know the best how to do it. What SAFe misses is that the PO is also the one who knows the best his part and that needs autonomy in the way he manages his scope.
    • Go for a flat company, with a simplification of the structure to have a better collaboration and lighten the weight of the hierarchy. This allows among other to release the initiative and the autonomy of the teams.
  • The SAFe (c) approach to innovation is very light. To claim that two weeks of “Innovation and Planning iteration” are sufficient is just wrong. By practice it’s just a buffer to finish what has already been planned and unfinished during the sprints. SAFe(c) misses the point where Innovation is rather a company culture and a continuous process that is reflected in the overall operation of the company.
  • An alignment around the strategic intentions that are declined in Epics, Capabilities and Features. The only thing left for the Scrum team is to execute what “falls” in the train’s backlog. We are far from the Product owner who is close to his customers, who knows his product and who adapts his backlog to always be in tune with customer expectations. This cross-company approach means that teams move away from the context and cause a considerable loss of information between the original intent and the final execution. The risk is limited thanks to the demos and reviews, but it is there.
  • Too many artifacts! SAFe tries to solve all the problems at the same time. By deploying SAFe one is tempted to take it all without worrying about the initial purpose of the company. And this results in many artifacts that can be useless and harmful. These “useless” artifacts can result in poor return on investment and disengagement from your teams when they do not see the value of what they are doing.

What do I retain from SAFe (c)?

Some aspects of the PI planning:

  • Alignment with the company’s vision, the roadmap to achieve business objectives. That managers take the time and make the effort to structure their vision and share it with everyone is great! It gives a lot more visibility to the contextualization of what the teams do and it gives meaning to what people do, a very strong element for the motivation of the troops.
  • The collaboration of the whole train structure (BO, PM, architects, teams) around the construction of a plan for the next two months with a common commitment on the objectives to be achieved and very rich discussions.
  • The identification of dependencies between teams and with the outside world. Risk identification and sharing with the entire train. This is a very good sharing of responsibilities and allows managers to find concrete elements to support and help teams.

PI demos:

It is interesting to have once every two months a “big demo” with a large audience and in which we show what has been done on the last iterations. I tried in the past to invite people to sprint demos, but the frequency too high multiplied by the number of teams makes it quickly becomes too complex to manage. The idea here is to demonstrate, the result of the work of all teams in collaboration. This ceremony reinforces the idea that we work for common goals in collaboration.

The lean vision of the company

with among others the prioritization and limitation of WIP at the Program level. The construction of this prioritized backlog forces managers to have a global alignment and resolve conflicts of interest upstream. The limitation of WIP allows teams to have a strong focus and avoid the paper jam effect.

Conclusion

Personally, I had a lot of trouble with SAFe (c). I was expecting to work with self-organizing teams who are co-constructing a better way of doing things, and I ended up with a rather heavy framework and limiting in terms of autonomy. The company culture has not helped either, because above SAFe (c) the company has added its layer of mandatory “recommendations” with quotas for maintenance, metrics to use, a corporate DoD hard to reach etc. . It took me a long time to understand that the company is looking for more alignment and continuous delivery than true agility in the sense of the “Agile Manifesto”.

And you, have you tried SAFe ? What is your opinion ? Have you tried it ?

Advertisements

Tips and Tricks to prepare for PSM 1 certification

PSM_Banner_Web

As a happy PSM II certified, collegues and friends often ask me question about why I’ve chosen this certification (and not the CSM) and how to prepare for it. So I thought it would be good to share my answers with all my network.

Why PSM 1 ?

These are the reason I took this certification :

  • The price : in the philosophy of Scrum.org, training and certification are decoupled. There is a price for the training which is around 1450$ (check on Scrum.org the official trainings) and a price for the certification voucher (150$ for PSM I). If you are confident in your level and you think you don’t need an extra training than you can directly buy a voucher and pass the certification.
  • The credibility : Your objective is to prove that you really know about Scrum.
    • The PSM certification has a passing score of 85% and the exam is 85 questions in 60 minutes.
    • For CSM the passing score is 75% and the exam has no time limit. The number of CSM holder is much bigger than for PSM I. I personally know few people holding CSM without having any concrete experience on Scrum.

I let you guess which one has more reliability and trust on the market.

How to get PSM I certification without the official training ?

The PSM I certification validates your basic knowledge of scrum and Scrum theory. In opposition to PSM II, it has no real life examples to answer and no tricky questions. It is simple and straight forward. But since the timing is very short, it is better not to hesitate and be quick when answering (be quick or be dad !).

To prepare for it I advise you to :

  1. Read the Scrum Guide carefully and multiple times. The guide is not long but each word in it is important and carefully chosen. You’ll need time to get every single detail in it.
  2. I highly recommend to also read “Scrum – a Pocket guide from Gunter Verheyen.
  3. Pass the open assessments on Scrum.org, and not only the PSM one. To have larger variety of questions go also to the other open assesments (PSPO, SPS, PSD).
  4. On mplaza.pm you can buy a PSM preparation package for 37 dollars I think and it gives you the right to pass 3 PSM I blank tests.
  5. Do the open and blank assessments until you have more than 90% good answers automatically. This way you avoid all risks of failing.

The day you pass it

You’ve followed my advises, you’re ready to pass the exam. My last advices are

  1. Make sure that you will not be disturbed during the 60 minutes of the exam
  2. During the exam do not lose time thinking too much about a question. If you find it hard you can bookmark it and pass to the next one.
  3. If you really don’t know how to answer, the first answer is the best.
  4. If you have enough time, revise your answers before closing the exam.

Hopefully with all these advises you’ll pass and get your PSM I certification. If you have any additional tip write it in the comments.

Tools for distributed Teams

It’s always painful to do scrum with distributed teams but unfortunatly it’s something we need to live with. Therefore there are many startups and companies that are making effort to provide tools that facilitate working “Agile” with distributed teams.

I personally used to work with a team in 3 locations (Germany, Ukrain and Russia) and we experienced some of the technics and tools that helped us to have a better collaboration. In this entry I’m not going to talk about the standard tools used in companies such as Webex, Jira, Skype for entreprise … but the tools that helps us to do Scrum and Agile development.

  • https://www.planningpoker.com : is a tool that you can use for free for your planning poker sessions. It is possible to prepare the session before starting it by filling the list the Items that you want to estimate. It is also possible to add them on the run during the session. The tool is very flexible and helpful. After trying period (which is quite long) there is a limitation of number of users for the free version (5 people). Multiple ways of  estimation are possible in the tool, the most important are the Fibonacci estimation (1,2,3,5,8…) and the t-shirt size estimation. PlanningPoker
  • https://www.retrium.com : A really nice retrospective tool that allows you to run a distributed retrospective with distributed teams. It offers you multiple formats of retrospectives :
    2017-06-29_10h59_14moreover, retrium manages all the flow from anonymously writing tickets to flipping them, dot voting and building an action Plan. It also keeps a history of all the retrospectives you had with your team. The tool is complete and very easy to use.
  • https://www.featuremap.co : A collaborative story mapping tool that allows to easily build a map. The free version gives the right to build two maps and I suppose limited number of presons. Compared to other tools this one is very intuitive and complete. I also liked the fact that it provides an interaction with Trello, Jira and others. You can build your map on featuremap.co and than export it directly to Jira and start scrumming.FeatureMap

… yes in my day to day life I work in French. Bonjouur

  • Google sheets : yes google sheets, very simple collaborative tools that allows you as scrum master or coach to prepare your retrospective and make everyone work on the same sheet. I used it many times, maybe the two formats I can share with you are :
    • What do you like about them ? Is a team building exercice I did with one of the teams. The purpose is that everyone expresses what he likes about the other team mates. Below screenshot of the sheet : what do you like
    • Thematic retrospective : Organize the improvement points by theme or area. In the example below I was working with a new fresh team and I asked them to propose improvement per Scrum event. I also asked them to work in groups first than to converge togather after. The format is the following :Improvement

These are the tools I personally use with distributed teams. These are only tools what really matters is that you build a solid team with the collaboration and openness mindset no matter what tools you use.

Change your behavior, get out from your “self-fulfilling prophecies”

“It’s only under pressure that people work correctly”, “My team lacks rigorous thinking”, “We don’t control what happens to us, only god can”, “My team members are not responsible people”, “I can’t ask for help” … And so many of these thoughts that we have, or hear around us that imprison us in a mechanism of self-fulfilling prophecies.

I remember I was coaching a project manager that asked my help because he was close to burn-out. He told me “I don’t have any leadership, I can’t get people to go on my direction“. He deeply believed in what he was saying and he was accepting it as a Truth. As a consequence, he was no longer sharing his projects and vision with people around him thinking that “They will not help me anyway“. Instead, he was doing everything by his own and delegating nothing. Colleagues and friends who want to help do not know how to help him. Even when they ask directly he responds by a “I’m handling it, I’ll do it by my own“.

Obviously he was not realizing that he was stuck in a self-fulfilled prophecy. His first thought which is “I don’t have any leadership, I can’t get people to go on my direction” made him behave in a way that reinforces his thoughts.

This is a typical story of a self-fulfilling prophecy that imprisons the person in a an endless loop. This is exactly the same schema of a woman saying “Men I marry are always violent” or a common society belief such as “performance is individual” or “parents know better what is good for us”…

How does it work ?

self-fulfilling-prophecy-model

The mechanism of a self-fulfilling prophecy is the following :

  • Someone has a certain belief(s) deeply anchored. A believe is something that is not based on facts. But for the person concerned it is a Truth that cannot be challenged
  • Based on our belief we have expectations, a result that we expect and that corresponds to our belief
  • This beliefs and expectation made us behave in a certain way assuming that our belief is a truth
  • From our behavior we obtain a result. The result obtained will very often correspond to our expectation and therefore reinforcing our initial belief.

This mechanism leads to a snowball effect. The more we are stuck in this loop, the more we can’t see it and feel it. You will only feel that you are blocked, frustrated and tired But very often you don’t realize that the cause is probably a strength belief shaping your actions.

Our believes protect us

Their first role is to protect us. I remember my father telling me”In our family we are not made to start businesses, we don’t know how to do that“. A strong belief that probably slowed him down in his professional life. But the most important is that it is protecting him from the guilt or shame he could feel about never trying to start a business and making all his career with the public sector. Another example is all the believes coming from a religious system. We all hear “Things happen only with god’s will” or “God knows what is good for us”. All this thoughts are protecting us from the hardness of life and from potential feeling of guilt.

How do get out from a self-fulfilling prophecy ?

Change is here

As explained, the schema is a positive loop reinforcing itself. And this loop need to be broken somewhere to get out from it. Attacking the belief itself could be harmful since believes have  a role of protectors. We protect ourselves from feelings of failure or regret s, etc. by constructing our believes.

The solution is to change the expectations and so the behavior. Expect things to be different and behave in such a way you make it happen. Do it even if it goes against your believes. First time you will force yourself changing your natural behavior. Think of what you can do differently to have a better result. Think about what can you change even if it does not seem natural for you. Take it as an experiment and expect everything from it. Based on the result obtained you can judge if it works for you or not.

I come back to the example I mentioned above of the project manager “no one is helping”. We did the exercise together and he started doing different experiments. First one was “sharing clearly his purpose and the benefit expected with the others” second was “People can figure out how they will achieve this purpose by themselves. I no longer tell them or care about how they do it“. At the same time we attacked a second belief which is “personal and professional life are separated“. Little by little he started sharing his ideas vision and delegating to people. He started expecting the best from the teams and stopped micro-managing them. He also showed more empathy towards people, giving autonomy, caring about people happiness and well-being.

The result he get from these experiments was mind-blowing. People became more engaged in the projects he was leading. They were really taking ownership of what they do and they do it well. The belief that was limiting him was little by little replaced by a positive belief that made his success.

Self fulfilling prophecy can be positive

A self-fulfilling prophecy could also be very positive when starting from a positive belief such as “I always get what I want, sooner or later”, “People around me love me”, “I can make my dreams come true”. Anchoring these believes in our mind will affect our behavior in a way that we finish by making them happen. In this case the snowball effect is very positive for you and can lead you far away. This is probably on of the success factor of president Trump. No political skills, no experience but a strong a belief that “he can get what he wants”. I’m typing this story and thinking that in this special case it’s a disaster for everybody else than Trump.

What is the link with Agile ?

I let you figure out what are all the believes in a company that can harm an Agile transformation 😉

Do the stand-up the kanban way : stop starting and start finishing.

A stand-up meeting is a meeting in which attendees typically participate while standing. The discomfort of standing for long periods is intended to keep the meetings short. (Wikipedia)

Purpose

  • Inspect : The team inspects the advancement during the sprint by reporting what have been done so far and the impediments they have. They inspect where they are regarding the sprint goal and scope.
  • Adapt : Based on the actual state of the sprint, the team decides what to do next. They collaboratively decide how they are going to tackle the job to maximize the number of Done US at the end of the sprint.

How daily stand-up is done

The most common way of doing the stand-up meeting is : each team member answers the following questions :

  • what have you done yesterday ?
  • what are you going to do today ?
  • do you have any impediments ?

What I like about it is that each team member speaks without bein interrupted. The speaking time for each one is respected. Alles gut. The team have a clear idea on what each one is doing and if there are any blockages.

What I don’t like is the fact that it’s focused on persons and not on the work. This can rapidly be misleading and break the team dynamics.

The alternative : do it the Kanban way

What I want to see happening in a standup meeting is :

  • A clear focus on the work and not on the persons. What is the state of the sprint ?
  • Team collaboration on how we’re going to tackle the remaining work.
  • Building a team plan on what should happen during the day

This means that team members report, discuss, plan and validate … and should still stick in 15 minutes.

Doing it the kanban way is answering the questions by walking through the wall from right to left with the objective of having things done. The tickets which are closer to Done are discussed first and they are the priority.

When to do it

I often run this kind of daily stand-up at the end of the sprint (3 last days for instance) that the team focuses on getting things done and avoid losing time on User stories or tasks that cannot be closed this sprint.

And you guys ? How do you make your standups effective ?

Agile is not the objective, agile is a toolbox

Fictive Job interview :

Customer : Hi samitriani, I’m going to present my self I’m the Global Head of practices, agility manager King of Mereen and father of the dragons . Our company has as objective to become more agile and flexible. We’ve already transformed 30% of the teams and we have as goal to have 70% of teams working with agile at the end of the year. That’s why we are today meeting to check how we can collaborate together toward this objective.

Samitriani : Looks good. So you want me coaching your teams through agile. Then I would like to know what are your objectives ? What do you want to achieve ?

Customer : Heuuu I told you we want to be agile. This is my objective, I don’t get you ?

Samitriani : Agility is a toolbox, a good one. And I’m here as a consultant to identify practices, frameworks that can help you in your day to day work. But in order to coach we will have to define the objectives for your organization, what is the long term vision ? What we need to clarify, is what do you want to achieve throught agility ? What’s in it for you ?

Presentation

During the last weeks I’ve been discussing and visiting many customers as an “agile coach”. They have as objective to deploy agility in the company and to have their teams using Scrum Kanban frameworks or whatever. But surprisingly most of them do not have a clear vision on where they want to go ? What they want to achieve ?

In this blog entry I’ll clarify what is agility, What are the objectives of agility as a thinking. Based on that I will give my point of view on what agile as a toolbox can do and what are it’s limits  ?

What is Agile ?

The Agile manifesto has been created in 2001 and is limited to 5 values and 12 principles. (I found a very simple and accurate definition of “Manifesto” HERE). So it is not a a methodology, not framework and there are no directives. It’s up to anyone building software to adapt it and to find the best way to apply these values.

This manifesto is at the heart of agility. Everything else you hear/think about (Scrum, Kanban, Lean, Lean startup, Less, Safe, Nexus, etc.) serves these values. They help you structuring and managing your work. They allow you to put in practice the agile manifesto quite easily by following simple rules. But keep in mind that the main focus the manifesto.

I’m saying that because more and more companies are putting in place Scrum, as a methodology, and forget about agility values such as “collboaration”, “responsability”, “Respect”, etc.

Why Agile ?

There are no established list of agile objectives. But these some I personally think about and that are worth mentionning :

  • Rapidly and accuratly respond to customer needs : Build the right product for the right market in the right time. One of basic principles of agility is to have all the focus on the customer and to continuously provide value to fit his needs. By building increments that are frequently released and confronted to market, you’ll be able to mesure it’s response (usage, adoption rate, growth, etc.) and adjust your approach.

Mythes sur

  • Software development effectivness : Agile has a complete different approach on managing the software building risks and succeeds to reduce it dramatically. Continuous collboration with PO reduces the risk of misunderstanding. Having a feature team will reduce the risk of Integration and late Bug discovery.  XP practices will allow you to have technical excellence (pair programming, refactoring, unit testing, functional testing, etc.). DevOps makes your deployment/operation much closer to development and reduces conflicts. An agile organization is an organization that is able to master and highly reduce it’s risk
  • Optimize the process : .Agile is closely related to Lean manufacturing which has as objective to optimize the process by reducing waste. Kanban is one of lean framework that is now considered as Agile one. It allows you to have faster production and to reduce all costs of overproduction, storage, waiting etc.

Team coaching

Coaching is a form of development in which a person called a coach supports a person or a team achiving a specific goal. It is different from training, mentoring, consulting in the fact that the coach do not provide a solution or teach you. The coach helps you to find out what is blocking you and what are your strenghts that you can by yourslef achieve your goal.

When I coach a team, first thing to do is to establish a “demand”. What they are looking for ? Then during the coaching we define a SMART “objective” on which we work. During this coaching, agile and lean thinkings can has a lot of benefits because they are the best toolbox to reach excellence, effectiveness etc.

How to run a retrospective meeting

looking-back

I’ve been running retrospectives for more than two years now with several teams. I’ve done this with a Dev team as a Scrum master and then with 3rd level support team as a team coach. Although the context was very different, the way I run the retrospective is still the same and still quite effective. Obviously there are multiple ways of running retrospectives depending on the context, objectives etc. In this blog entry I’m sharing how I personally run retrospectives.

Retrospective purpose

A retrospective meeting is one of the Scrum official ceremonials. It is also used in other agile frameworks such as Kanban. The main purposes of retrospectives are :

  • Review the last iteration (called sprint in Scrum) by checking what went well, what we could improve and how to improve it.
  • Embrace change : it’s in general the occasion to deal with the changes that are happening (in the team, company, organization) and to find a way to adapt accordingly.
  • Empower the team : The team, and the team only, decides on the actions they are going to take. They take ownership of their mission and the process.
  • Team Building : The more retrospectives are done, the more people will know each other. They will communicate better and be able to take decisions collectively. They build a meta-communication model that will allow them to communicate effectively. And you’ll need this when you’re facing critical situation. Where some other teams will fight and blame, your team will (Hopefully) be able to handle the stress and keep same way of communicating.
  • Have Fun : I keep it as a personal objective, but in such meeting we’re having fun. no pressure! Very often it’s the end of the sprint, everybody is tired. So I always keep it cool and fun. By doing this, the team will be in a better position to speak up and reveal their deepest thoughts.

Scrum master/coach role

TheArtandMastery-400x283

When you run a retrospective your role is to make the magic happens. You need to make sure that :

  • Impediments are discussed and well understood. Nothing should be kept under the carpet. Each point of view has to be exposed and explained.
  • Decision(s) are taken collectively and approved by everybody. I share with you the wikipedia page on Group decision making which is very complete and useful.
  • Make sure that the decisions are feasible and that will have a follow-up. Do not neglect this part. During the next iteration you need to make sure that things are done. The objective is not to have some post-its displayed in some board with no one looking at them.
  • Time Boxing is respected.

As a team coach you need to keep low posture. Your role is to make things emerge from the team members, make them speak, make them confront, encourage them. You’ll have to avoid suggesting things or come with ready to use solution. You’ll have to use open questionning and active listening techniques. I will explain later how to use it.

Retrospective meeting framework

Preparing a retrospective meeting

Collect data during the iteration

In my experience people often forget some of the thoughts they had during the iteration. They briefly talk about some of the impediments either in the stand-up meeting or during informal discussion then they forget about it.

In order to avoid loosing these information, I display on the team board any thought or subject mentioned during the iteration. They are then exposed during the retrospective meeting. If some of them are relevant they will be voted.

Observe

As a team coach you also have to be very careful about what happens around the team (interactions,  team dynamic, conflicts, etc.). All what you observe can be used during the retrospective.

Running the retrospective

agile-post-104-feedback-the-retrospective-meeting

Organization

This is how I organize retrospective meeting :

  • Free talk round table : Round table where people talk about their concerns without being interrupted. You give each person a free talk of 5 minutes max. In a Dev team I make people talk about what went well, what is to improve in : Sprint, release and the team. As a coach, you have to note what is mentioned and be careful on issues that could have an effect the team.
  • Concerns listing : I ask each team member to write down on a 3 post-its the issues/concerns they want to discuss during the retrospective. The postits are then sticked to the board.
  • Building organized discussion backlog : You make the team vote on the items displayed on the board. There are multiple ways to vote, anyone of them is ok. Based on the vote result you organize your backlog order.
  • Conduct discussion : This is for me one of the hardest phases of the retrospective. You’ll need to be very careful on everything is said. You also need to make sure everybody is speaking up. Then based on what is said, you’ll conduct the discussion, note items, stick post-its etc. The discussion happening around any item should follow this structure :
    • Understanding the issue : The objective is to have good and same understanding on the subject discussed. All aspects have to be explored. As a coach you’ll use “analytics open questions” such as :
      • How do you define … ?
      • What is the purpose of …?
      • How would someone else think about it ?
      • What is the impact of … ?
      • What are the challenges of … ?
      • etc.
    • Resolve/work around the issue : As soon as the issue is understood, then you should try to find out a solution or a work around. Without this part, your retrospective can be useless. As a coach you’ll use “resolution questions” such as :
      • What options do we have to resolve the issue ?
      • How could we work around it ?
      • What other ways can we take to reach our goal ?
      • What are our constraints ?
      • What makes you say <doing this> is feasible ?
      • What motivates you to do this ?
      • What is the result expected ? How to measure it ?
    • Valid retrospective action(s), put in place a follow-up : Make the team vote on the action(s) to take. The less actions you have, the better it is. Make sure that the action, the follow-up, etc. is very clear for everyone. During the iteration, make sure that you follow-up the action taken. To keep your team motivation for retrospectives, you’ll need at some point concrete results.

If you are reading this, it probably means that you resisted to all the article until the end. Thank you for that and do not forget to make any comment 😉