I am pretty sure that you might have heard about Lean Coffee and how it could help you have effective, structured, agenda-less meetings. Lean Coffee format could be used in any kind of meeting so why not in a team retrospective?

If you are thinking to use it in your next retrospective consider the following steps:

  • set-up a personal KANBAN board (cards to use: to discuss, discussing, discussed)
  • reflect on your previous sprint and write on sticky notes your insights related to what worked well, what didn’t work so well and what need to be improved (you can use any other set of questions to gather insights)
  • collect all this items under the “to discuss” card. give a few details about the topic if sth is unclear
  • vote those items that you think are most important for you and your team to discuss (two votes per member)
  • prioritize them based on the number of votes received
  • move the top rated item in “discussing” and start discussions! 4 minutes might be a good duration but it’s up to you to decide if you would like to have a longer duration
  • after the four minutes for the specific topic are passed decide if you would like to give another turn! (thumps up or down). if most of the people would like to discuss take four minutes more, if it is equal take the half time
  • when you have finished with one item put it under “discussed”. suggestion: keep one minute to reflect on your take-aways , actions, conclusions e.t.c
  • repeat again with the next item until the time planned for the retrospective
  • ensure to leave a few minutes at the end to reflect on all items discussed!

give it a try!


inspiring posts

what is a lean coffee



Implementing agile in an organization could be a very hard and complicated thing and it could become even harder especially if you are impatient to see the anticipated benefits. It’s common said that it is very easy to start with agile and to my experience and observations it is even easier to fall back to old ways of doing things – maybe renamed – when you realize that you are in the middle of chaos!

Is there any way to have a successful agile change that serves its purpose? The answer is yes and Jason Little describe that way in his book “Lean Change Management” which is an excellent resource with concrete practices, that could help any agile change agent to be good at change!

Recently i had a great challenge to train a big project team in agile methodologies, that came as their need to handle a very complex product with high uncertainty in what to do and how to do it! I’ve seen this challenge as from the very beginning as a change rather than as a conventional two days training and i thought that it was a great opportunity to experiment with the Lean Change management approach!

As Jason suggests in his book, a  Lean Change cycle starts with gathering insights about the current state of the organization. There are multiple ways and models that could help someone to do that and i found really challenging to experiment with a retrospective based on Virginia’s Satir change model as one of the method i’ve used to gather insights.


I’ve made the hypothesis that making all participants aware of that change model will help to improve the way they process their own change related to their agile implementation and move smoothly from one stage to another.

In brief the model consist of the following five stages:

Late Status Quo: Everything is familiar, comfortable and performance is stable

Foreign Element (Resistance): A foreign element threatens the stability of familiar structures. Most people resists by denying its validity. That foreign element is not particularly a sudden crisis, but rather the “sudden realization that things have been very unhealthy”

Chaos: In Chaos people affected by the change try to ignore the foreign element , hide from it or actively fight it. People might even reject the foreign element so much, that they end up at Old-Status-Quo behavior! Confusion, anger, drop in performance are just a few side effects.

Transforming Idea (Practice and Integration): In that stage after coping with the foreign element, people finally discover in a transforming idea that shows how the foreign element can benefit them and they start integrating the benefits into their new identity.  People will need a lot of slack-time to try out new things. Some things will turn out to be bad ideas, others will work greatly.

New Status Quo: Performance stabilize in a higher level that the old status quo. Roles, responsibilities, ways of working are clear and a new status quo is born, just until you realize the next foreign element, and the cycle starts from the start!

I’ve started the retrospective with the description of the model and on the way people react in every stage. As a next step participants triggered to answer in sticky notes a few questions related to  model stages and we discussed as a group the different views.

The questions i’ve used, inspired by Jason’s book are listed below:

Late Status Quo, “everything being familiar and in balance”

What was working well?

What was making you feel comfortable in that state?

Foreign Element, Resistance, Chaos, “sudden realization that things have been very unhealthy”

Which are your main concerns related to this change?

Which are the main obstacles that restrain you to get the benefit of this change?

Transforming Idea, “AHA!..i learned something!”

Which are the forces that driving this change?

Which are the benefits you have seen so far?

What are you willing to do in order to make the change work?

What will you need to do differently?

What support do you need for me?

New Status Quo, “everything being familiar and in balance”

What is your VISION, your new target position with respect to this change?

How will we measure success New Status Quo

The amount of generated insights was impressive! Project team members came to a conclusion that maybe the foreign element that triggered their comfort zone was the project complexity and it was less related to their agile implementation. For sure agile surfaced even more dysfunctions that there was need to handle. However they have started seeing it as the transforming idea, the vehicle and not the impediment to succeed with their project and get out of the chaos. They were expressing some of benefits they had seen so far form their agile implementation, while reflecting on things that they need to change or challenge for themselves. It was also useful that the main barriers related to their change, like management support, product roadmap, team structure were highlighted. It was also interesting that participants thought about their new status quo and what they need to do in order to reach their wanted position. This helped the project team to co-create a list of options (second step on the Lean Change management) that they could work further depending on the value they will get compared to the effort or cost they need to invest as suggested in Lean Change Management.

If i could sum-up the whole approach we have used to generate insights in a few words i would choose awareness, alignment and co-creation! and IMHO i believe that are important  pillars for any change to happen!

Concluding, start gathering insights is the first step in Lean Change and to my experience the Satir Change model could be a really helpful way to generate them! To move forward and support any change to serve it’s purpose you just need a few more steps. Apart from insights, you need options, make a lot of experiments, learn, reflect, run more, start anew!

Would you like to be good at change? I would suggest to learn about the Lean Change Management approach and try it!

First appear as a guest post in 


inspiring reading

Lean Change Management

The Satir Change Model

3 reasons why you should build your own change method

inspiring video

Creating alignment for agile change at agile and beyond 2015



Underlying all human actions are needs that people are seeking to meet, and understanding and acknowledging these needs can create a shared basis for connection, cooperation, and more globally peace


Dr. Marshall Rosenberg, the founder of Non Violent Communication (NVC) language used to say that quite often we tend to use the language of  “jackal”,  we judge, lay blame, we demand and eventually disconnect. NVC is another communication process that focuses in understanding each other at the level of our needs and learning to communicate with compassion towards ourselves and others

While studying and trying to practice the NVC language (great trigger a learning lab i attended @ Ericsson’s Learnathon on that subject) i thought that it would be a great experiment to try NVC language in a team retrospective. I was curious to understand, how honestly expressing ourselves and emphatically listening others, could improve or challenge team relationships and trust among team members. It was a completely new way to communicate and express things that didn’t work well, things that worked well and areas that could be improved.

We run the retrospective using, to the extend possible, all four components of NVC process: observations, feelings, needs and requests. Since it was the first time using that language we kept some notes on every component to help us during our discussion using NVC language! Below is a short description of every component with a few examples

  • observations: in that phase we reflect on things that we have observed (hear, see, remember) free from our own evaluations or interpretations of what happened. We focused on both positive or negative observations on team or even on personal level.

ex. during our previous sprint i remember that <a team member> had to handle too many tasks

ex. i’ve noticed that we didn’t get from sprint beginning the expected support from system experts and i remember that we finally got the support after raising specific questions and setting up a couple of meetings

  •  feelings: in relation to what we have observed, in that phase we have expressed our emotions rather than thoughts which were associated with our met or unmet needs (next phase). The observations were just the triggering points

ex. […] and i felt a little bit uncomfortable

ex. […] I felt initially insecure on they way we have approached our solution and i felt more confident when finally we got the required support.

  • needs: in that phase we have tried to express our deeper needs that caused our feelings triggered by our observations.

ex. […], because i value fairness and balance on workload distribution among team members

ex. […]. My need for safety, security and support on what we are doing as a team even at later phase was met!

  • requests: in the last phase we tried to clear express our requests that will improve our personal and team’s well being. Trigger improvements that are closely connected with our expressed needs.

ex. […] Do you think that we could try in our next sprint planning to split more equally our everyday task and try offload<a team member> from tasks that for the time being his expertise in not needed and let him focus on those tasks that our team needs his expertise so to meet our goal?

ex. [..] Would it be nice whenever we have uncertainties and we need support proactively send our requests, while trying to be as specific as possible, to people that could help us?

It was interesting to observe that we have managed in a very polite & humane way to express what happened in previous sprint and identify behaviors that we would like to keep and try. It was quite impressive the way people expressed their feelings and their met or unmet needs.

We have used the same language to reflect on the hour spent so to get used on that new way of communication and once more the outcome was amazing! People felt proud of their team, observed that they have different needs not expressed so far, felt more confident to share their feelings caused by their needs and helped them alot to see that there are ways to avoid conflicts, blame and disconnection. We will definitely use that language in our retrospectives and as suggested we should even try it in our everyday work as well! I think we had just made another step while trying to grow strong team relationships!


inspiring reading

non violent communication: a language of life

how you can use the NVC process

inspiring videos

Nonviolent Communication Part 1

Nonviolent Communication Part 2 



I’ve recently facilitated a route cause analysis for a feature that we have failed to deliver within our estimated range. Worth to mention that our estimations were adapted during our feature development, we scoped out a few functionalities but still we exceeded our maximum estimated delivery date.

The analysis surfaced a lot of issues that we didn’t consider throughout our development phase. We’ve got a lot of insights and we suggested actions that need to be considered for our new feature. Soon we are going to have our feature retrospective (a.k.a postmortem) as well, to gather even more data and get more insights on ways we could improve ourselves and our organization.

We all benefit from this analysis except our feature! Post-mortems and RCAs are really useful, we learn, we improve but not all of us! Psychologist Gary Klein described it in one of his article really nice:

A postmortem in a medical setting allows health professionals and the family to learn what caused a patient’s death. Everyone benefits except, of course, the patient.

In that article (referred in 99u’s post) Gary Klein introduced the concept of pre-mortem as a method that could be used in the planning phase of a project. As it is stated, pre-mortem can improve project’s chances for success and can help project teams to identify risks in a very beginning stage!

Based on my recent RCA experience, i’ve experimented with the pre-mortem concept for another feature team that i am coaching and had started a really challenging and complex feature. The steps i’ve used are described below

the case study

In that step it is important to “illustrate” an imaginary failed state of the current project/feature. Adding details, using pictures, creating a kind of “script” could help the team “live” that unwanted state.

The “script” in our case was a failed deployment of the very complex telecom feature we have developed for a very demanding telecom operator. The consequences for our operator and customer was a huge amount of call drops for a few hours. Our feature team has received an email from our customer’s head of sw deployment describing the impact of this failure, the urgency to find a workaround and remove our feature from operator’s network.

why this has happened

After describing the case study all team members need to take some time to think of possible causes that triggered this failure. Using sticky notes we’ve gathered all the causes and discussed on them. We then tried to group them in themes and we prioritised them based on their importance and their contribution in that imaginary failed state.

It was interesting to observe that feature team members were felt free to express all possible causes came in their minds and they were more open comparing to post-mortem or root cause analysis for failures that have actually happened!

how we could prevent this

The next step is a brainstorming session to find ways to prevent this imaginary failure and anticipate all possible causes. In our case we decided to work on the top themes, based on our ranking from the previous step. The outcome of our brainstorming was a concrete set of actions that we are following up weekly. In the meantime we are enhancing the rest of the themes with actions that need to be considered as well.

keep calm and carry on

you can close the pre-mortem session with a message just to relax all participants :-). It was just a simulation and we have done our best to prevent this happening in real life!


We have used almost two hours to gather causes, group them, prioritise them and find actions for the top themes. As facilitator you will need an hour to think of a failure scenario (ask your feature team, PdO e.t.c to get a few details) and prepare a “script”

personal reflections

The feedback i’ve received from all participants was really positive. This exercise trigger their creativity, as it is mentioned they were more open to express all their concerns,  and they had a feeling of doing their best to increase the chances of success. As facilitator and observer i really feel that most of the benefits as described in Klein’s article were gained

Although many project teams engage in prelaunch risk analysis, the premortem’s prospective hindsight approach offers benefits that other methods don’t. Indeed, the premortem doesn’t just help teams to identify potential problems early on. It also reduces the kind of damn-the-torpedoes attitude often assumed by people who are overinvested in a project. Moreover, in describing weaknesses that no one else has mentioned, team members feel valued for their intelligence and experience, and others learn from them. The exercise also sensitizes the team to pick up early signs of trouble once the project gets under way. In the end, a premortem may be the best way to circumvent any need for a painful postmortem.

Are you ready to imagine a failure? or a success (a.k.a future-spective)?


inspiring reading

avoid a failure with a premortem

performing a project premortem

29-2s It is well known that we learn the most from our failed experiences and our mistakes!  According to Thorndike’s law of effect  it is the negative outcomes that accompany a failure that increase the probability to change or adapt our behaviour in subsequent events. However a recent research attempted to answer that people could learn not only from their failed experiences but from their successes as well! In that research three functions (or methods) that enable us to learn from our successes and our failures were described:

  • Self-Explanation: analyzing our behaviour and trying to find reasons why we failed or succeeded.
  • Data Verification: brainstorming different ways we could have approached the problem and how we might affect the outcome.
  • Feedback: determining whether there is success or failure, and then reflecting on why things went right or wrong and how need to be changed in the future.

The combination of all these functions that characterize a systematic reflection, motivate people to draw their lessons from past failed or successful experiences and eventually trigger a behavioral change.

Based on that research and working in an agile environment, where the attitude on failures, problems, challenges, successes is to transform them into learning that may involve further development and improvement,  i came up with a retrospective technique, as described below, to help teams grow an agile mindset!

retrospective goal

Encourage team members to reflect on the learning (on individual, or on team or both levels) from their failed and successful experiences and based on their reflections adapt or change their behaviour that will enable them to further improve.

retrospective process and practicalities

A board that is split in the following four areas and sticky notes to let team members right their experiences and learning will be needed.

Q1: where i/we have succeed (previous sprint/project/feature e.t.c)

Q2: what i/we have learned from our successes

Q3: where i/w have failed (previous sprint/project/feature e.t.c)

Q4: what i/we have learned from our failures

For every success or failed experience the relevant learning should be written. Depending on retrospective focus, you might trigger team members to think of their personal experiences and learning or on team’s experiences or both.

If you have a large team you might split them in subgroups to work on every area. I’ve tried quite a few times with really nice results. Sharing gathered data is a really important step. More specific sharing personal experiences and learning could increase psychological safety among team members, which in turn create an environment of trust in the team.

After sharing their gathered data on experiences and learning, it is important to focus on how the learning from their experience could trigger changes on personal and team level.

For a normal team (5-7 people) and for a period of sprint, one hour would be enough to cover all the above steps! (15′ gather data,20′ sharing and discuss, 15′ move forward and you will have a few minutes to reflect on the method used!)

facilitator’s tips

As retrospective facilitator you can use some of the following questions that could prompt participants to reflect on learning

how did you contribute to the performance observed in this failed or successful experience (self-explanation)

how effective were you in this failed or successful experience (self-explanation)

consider a different approach that could have been taken. What might have happened if that approach was chosen? (data-verification)

what has been learned from this failed or successful experience? What worked, what didn’t work? How will you behave in the future? (feedback)

personal reflections

I’ve received a really positive feedback from the teams i’ve used this method and this motivated me to share it in this post. I’ve received comments as well that helped me improve it ( secure that there is time for discussion on learning, focus on how could use our learning as a trigger for behavioural changes e.t.c). This retrospective technique will be more effective if you will try it with teams that are working some time together, they had faced various experiences in the past, their members are open to share and are willing to learn! But this doesn’t prevent to use it with new team as well. In that case it might be good to discuss with them about the importance of learning in agile environments, and that learning could happen from both failed and successful experiences!

Concluding for me it was really important that people spend some time and use their failures as information for further improvements and use their successes not only to increase their self-efficacy but as a trigger to revise how they managed to succeed on sth and set even higher goals and standards!

if you’ll experiment with that method, it would be nice to share your experiences and your adaptations!


interesting research

systematic reflection: implications for learning from failures and successes

A few months ago i’ve read an interesting post from Leo Babauta (zen habits)  where he described a simply method that could be used as a guide to simplify any area of our life! The steps he mentioned were:

collect everything in one place
choose the essential
eliminate the rest
organize the remaining stuff neatly and nicely

Inspired by that simple method and the way it could be used, form things related to our daily routine up to our own life, i was thinking that this method could help teams as well to simplify their working life!

Working with teams for a few years and considering the changes “agile” has brought to our organization, it was obvious that there were many things each new team should  handle! New responsibilities, new expectations, new processes were just a few areas that they should take care!

My experience has shown that it is impossible to handle all that stuff at once, even if sometimes there is some pressure to have everything in place as from the beginning! You need to focus on those items that return the most value back to your team and your organization and then work on the rest!

Confucious once said that

Life is really simple, but we insist on making it complicated

Based on that belief, my hypothesis was that “agile could be really simple, if we do not insist on making it complicated”! To experiment with my hypothesis i’ve used the “Four Laws of Simplicity” during a team’s retrospective. The steps are described below.


In that phase each team member thought about everything that was related to our way of working. From practices, processes, methods, agreements, responsibilities, expectations e.t.c. There was nothing right or wrong! All notes were gathered in one box that was finally turned upside down! We continued with grouping of the common items and create a few more general themes where possible. As an example a few items are listed below

solution testing, testing on target, US preparation, US selection-sprint planning, demos, stand-up, retros, taks splitting, code quality, e2e teams, collaboration, communication, commitment, feedback, openness, initiatives, self-improvement, adapt to changes e.t.c


We then chose the “essential” items! The items that could return the most value to the team or items that could have long term benefits. We discussed on notes and themes, and we used dot-voting as a technique to reach consensus and to prioritize our pool of items!


Team decided that there was no need to eliminate any item! Every item had its own value, so everything was kept for future reference.


As mentioned above dot-voting helped the whole process  to come up with a prioritized list of items. We further agreed that there was no need to work directly on the most voted items! For that reason we added two more parameters in our decision to prioritize the list of identified items. The value that will return a specific item and the effort required! The outcome of this exercise was the creation of a “prioritized” improvement backlog including items that the team would like to keep, “tweak” and further explore!

As an example, the team decided to work on “code quality”. Worth to mention that all team members were really satisfied of the quality they produce but they were willing to further challenge their “local optimum”! A couple of actions they came up: re-activate improvement list (add items related to legacy code improvement & bring them to architecture meetings) and introduce the concept of “re-factoring US” as soon as an EPIC had been implemented.


based on the feedback i received, team really enjoyed that method! we spend almost two fully productive hours!

In my opinion team managed to express and visualize their personal thinking related to their work, reach consensus and focus on those items that could help them to get improved and could return the most value back to them and their operations! It was a start that requires effort and discipline to grow a mindset of little constant improvements!

What i would change based on the feedback i’ve received…i would introduce an estimated technique to estimate the “value” of the chosen items! it might help teams to understand the “value” of estimation as well!…and why not invite team’s group leaders/line management and PdOs to express their own thinking and contribute from their sides on the improvement board!…


inspirational reading

4 Laws of Simplicity and How to Apply Them to Life

I Manage Products


Si Alhir (Sinan Si Alhir)

© 2016 Si Alhir (Sinan Si Alhir) — All Rights Reserved.

Assess your Agility - BETA

A framework to evaluate and improve your organization's agility

Lean Adaptive Leadership

Transforming technology organisations using lean and adaptive principles.

Systems Thinking and the Vanguard Method

Musings, discoveries and experiences

Control Your Chaos

That Scrum Girl on everything Scrum, Agile and Lean

The Product Owner Framework - BETA

Evaluate your skills and identify areas for growth

Digital Business Transformation

Inviting you to explore the world of Digital Business

Agile For Startups

Tools and Techniques for Tech - Startups .

Escape The Local Optimum

jump out of any local optimums by iterating, evaluating, accepting, memorising and restarting

Software Process and Measurement

Software Process Improvement and Measurement - Oh My!

Dave Nicolette

Effective software development and delivery

Arialdo Martini

Random notes about software

Agile By Culture

Doing Agile means being Agile


Thoughts on software, code, philosophy and games

InnerActive Leadership

Partnering with you to find insights that lead to results!

Agile, Data, APIs, startups and more

Everything I find out about Agile, Data, Big Data, Data Science, APIs and of course Startups.

quantum shifting

think bigger, go further

Benjamin Mitchell's Blog

Helping IT teams & their managers deliver great software solutions

Diary of a ScrumMaster

Finding a path to a new way of working

An Ethical Island

How to Teach Without a Lecture and other fun

Mike Cohn's Blog - Succeeding With Agile

jump out of any local optimums by iterating, evaluating, accepting, memorising and restarting

Jim Highsmith

jump out of any local optimums by iterating, evaluating, accepting, memorising and restarting