Why NOT retrospectives


How do yo pull this donkey's tail?

This is a report from the Open Space of #scanagile 2009 conference. The reports will be collected at the Agile Finland wiki. Please link or create yours!

If a donkey is not willing to drag the cart, you pull it’s tail. It will resist the pulling and start dragging the cart.

The suggestive question “Why retrospectives”, might create pressure to conform, or to give the right answer. I have used the controversial question successfully a few times. Asking the opposite:

  • Is actually the important question: “What is blocking you?”
  • Everyone is working for the same goal 🙂
  • Is often fun and creative
  • Breaks the expected or established roles and games. Makes people change their position or perspective, even for a moment.

Feel free to use for any topic.

At Scan Agile we got the following list of reasons why not. Some advice between the lines.

  • The value of retros is not perceived
  • No experience of the benefit
  • Actions are not done
  • Experience of superficial retros
  • Assumption that retros are “feeling stuff”, with no “real” benefit. People are not used to it
  • Teams are (feel) unempowered
  • Too many meetings even without retros
    Levels of control

    Where do your findings and actions hit?

  • Culture of conflict avoidance
  • Fear of blaming
  • Misunderstanding retrospectives
  • Cost of delay is a good argument for actions
  • Scrum does not resource retros explicitly

    Some advice to use 2% to formal retros. 1% (hour/2 weeks) for iterations, 1% (1 day/quarter) to full product.

  • lack of facilitation skill, person (with identity), role
  • some people just don’t like to talk
  • people have not learned to recognize their own feelings
  • we don’t have the time
  • boring, boring, boring (defense mechanism…)
  • feelings are disconnected from the work context and identity

    Technocrats may turn surprisingly talented in emotions. Just give them a thinking tool, a rational systems model, with which they can connect feelings with work. I have had success with Nonviolent Communication. Is frustration or anger a feeling? Significant? Is disappointment significant at work? Or joy of success?

The conclusion is, that we have not tried retrospectives, because we don’t have a positive experience. Kind of logical…

The advice would be to give it a try with good enough sponsoring and facilitation.

I use this opportunity to publish another list with the same theme… very similar findings.

Understanding why NOT retrospectives at the International Retrospective Facilitator Gathering UK 2007

Post-it’s by Ari (host), Eshter, Sandra, Sal, Gabby, Linda

  • Poor facilitation
    • Bad facilitator
    • Only the strong get their thoughts come through
    • Time zones / distributed team
    • Chaotic retrospective
    • We blame or action people not in the room
    • No or poor facilitator
    • Facilitator has favorites
  • Honesty
    • Everything is going well !
    • Threatens illusions that reduce anxiety
    • “they” are not doing their part (mgmnt team)
    • no honesty
    • too positive. Hard to be honest and burst bubble
    • no-one tells what really happened
    • everyone lies
    • problmes are too big
    • if we admit there’s a problem, we may have to d osomething about it
    • not seeing your own part in the problem
  • Empowerment
    • Im minority, so my contribution isn’t worth anything
    • Team does not take it seriously
    • (Fear of) losing control
    • We just bring up the same old things
    • Actions agreed upon does not come through
    • Ae can’t do anything about it
    • Uncover managemtn’s powerlessness
    • Our action plans will be over-ruled by management anyway
  • Cultures
    • Culturally inappropriate (taiwan vs china)
    • Too touchy feely
    • It”s whacky stuff
    • bringing personal issues to the job isn’t proefssional
    • short term ebefit culture – ony this project matters
    • you can’t express the benefit in hard numbers
    • gap between management and team; no real knowledge nor/or understanding of significance
    • power is elsewhere command & control
    • no meeting rooms available
    • developers can’t possibly understand what we (mgmnt) have to face
    • it has not worked earlier
    • sipmplistic retros that don’t uncover anything significant
    • cultural differences (no common language?)
    • I am leaving so I don’t care
  • Pointless
    • people feel powerless
    • I’m not creative
    • I have nothing to contribute
  • (Blank)
    • I am ADD
    • I have asberger syndrome
    • I already have another forum (“Honest talk time at japan)
    • Managers mistake system problems with individual problems
    • retrospectives may discover unconventional solutions, which can’t be supported by management without their safety net. “What others did”
    • 80% of problems are management problems… and they don’t want to deal with them…
  • Time
    • We’ll do it later
    • Doing my real work is more important thatn going to meetings
    • something more urgent came up
    • we don’t have time!
    • Takes too much time
    • takes time away from real work
  • Fear
    • Don’t want to look bad in front of..
    • It disempowers me as a manager
    • retrospectives may uncover bad (management) decisions
    • fear of being blamed
    • “what is my role” if they do decisions on their own.
    • fear of criticism
    • fear of conflict
    • fear of admitting problems
    • Im not comfortable expressing my feelings in a group
    • we have to change. That’s scary.

Work with the right questions

At work people strive for a goal. This is often called the principal task, the value-adding work. It is the expressed intention at the levels of individual, group or organization. Related to this people solve problems with e.g. process, resourcing, business or technology. (It is always valuable to ask, what the principal task really is.)

People are, however, people. Especially when many. They have other questions at the same time, related to e.g. human needs, group dynamics or the organizational integrity. These other questions:

  • Take attention, time and energy
  • Do matter, have potentially significant consequences
  • Have second order consequences – build the culture, learning and so on
  • Block working with the principal task for shorter or longer time

In order to optimally promote the principal task, you need to recognize the right question and work with it. Forcing a solution to the wrong question does not really help. Have you ever heard: “Does not concern us, because we are rational adults.” Or “We can skip those, because we don’t have time.”

Conscious questions are the obvious normal stuff, technical and social things that people have learned to handle. Sources of questions

Pre-conscious questions are recognizable, especially when you try. You can observe and talk about them, and they become somewhat conscious. Examples:

  • Suppressed topics, taboos, cultural issues
  • Human needs: e.g. autonomy, safety, recognition, being heard…
  • Questions of trust, power, status
  • Question of leadership and dependency
  • Group dynamics
  • Should I invest the effort
  • Envy and competition – a sensitive topic
  • Games people play
  • Constantly ongoing inclusion and exclusion
  • Resistance, individual and group defense mechanisms e.g. groupthink
  • And some special cases

  • Scapegoat syndrome, tends to repeat
  • Pathological narcissism, difficult and dangerous

Oops. The list grows so easily! I will come back to these!

Unconscious is not observable. It can be considered the creative source where the other stuff emerges. You can not predict how the unconscious will respond to your actions.

Most of the times, things go naturally with no major roadblocks, just some very frustrating or insensible moments. People work with the preconscious questions unconsciously, and solutions emerges. This baseline is not the full potential – working consciously with the questions probably leads to a better solution. The group/team development is a good example.

It saves time and energy, if someone experienced can recognize the present questions and help to handle them consciously. Often just making the correct guess, giving a name to the question, makes it dissolve quickly, and the work can continue. Sometimes the interpretation is too much, and the group does not accept it. The proper timing, dose and form matters.

Sometimes, the unrecognized questions really block or deteriorate the work, and external help is beneficial.

A good situational leader, may it be boss, coach or scrum master:

  • Knows this preconscious people stuff. Actually it is not complicated, but needs some practise.
  • Has courage and social permission to work with all kinds of questions
  • Is able to use oneself as an instrument. For example when you feel strange, what is really going on? Are these feelings mine or what?

This is also called emotional intelligence. Surprisingly, it can be learned and practiced. I have coached many technically oriented people, who have turned to be emotionally talented – once they got the permission. The organizational culture and narrow identities sometimes really block people from using their full capability.

The Gap between the R&D and the product management

While looking around in any organization, you most probably recognize the Gap between the product management/PO and the R&D/Teams/designers. It is significant in surprisingly small organizations.

This becomes obvious when starting Scrum. The Gap has always been there. Why? What have been the workarounds earlier? Why is it important to understand the root cause? Actually there are more gaps on the value stream…

The Gap

the Gap between R&D and Product management

Drawing the Gap on a flipboard often stops the blame war.

Have you ever heard the following, when taking Scrum into use:

Team: Scrum says Give us the prioritized backlog.
Product manager: Yes, but we don’t know about tech, you do. Here You have the 5-liner. Just start working.
Team: Yes, but we need to know where to start.
PM: Yes, but we can’t prioritize technical items, you have always done it.
Team: But we can not work if we don’t know the priorities for the next sprint.
PM: What’s wrong with you?
And so on…

The Gap means simply that there is too little knowledge power, too few people who would understand both technology and business. I have many many times experienced how drawing this picture on a flipboard will stop the blame war in the room, when people realize that it is the system, not us.
Read the rest of this entry »

Work overspecialization by requesting knowledge instead of service

Just writing down a small and simple idea I got while looking John Seddon http://vimeo.com/4670102

Overspecialization is extremely common, and expensive to overcome once established. It has often grown to the extent that everyone in the organization feels helpless in front of it. Changing this requires widening both roles and knowledge.

Culture and knowledge are accumulated from small real incidents. The following could be one practical piece in building wider knowledge and new culture by small steps.

Overspecialization is supported by the basic assumptions of the culture, like:

  • it is more efficient and safe that people do only things they know already (realized and expressed)
  • bottlenecks are handled by external resource planning (realized and expressed)
  • features delivered is value, knowledge and quality is not (realized but denied)
  • avoiding conflict to keep people (=me) happy is more important than organization’s needs (realized but denied)

Overspecialization accumulates by repeating automatically the pattern:

I as the designer with skills limited to MyArea need to implement something that touches YourArea. I add a request to Your backlog and wait. I work to get priority in Your queue. Then you make your change and it hopefully works with mine. Maybe some iteration is needed to finalize.

Result eg.:

  • I own MyArea, you own YourArea
  • I learned the external behavior, “interface”, of YourArea
  • Maybe the changes in YourArea were done more safely and efficiently from YourArea perspective. Maybe.
  • Waiting, handovers and other stuff familiar from lean studies

The key idea is to request knowledge (created together), instead of service (created by You):

I own the change/feature, also what happens at YourArea. I request consultation, advice, knowledge, pair work etc. from you. We need to schedule the co-work. There is however more flexibility in adjusting the interaction and how much effort is needed from You.

Result, eg.:

  • creating new knowledge
  • more short term cost (?assumption?), but even more value
  • overlapping ownership
  • I learn more
  • more possibilities to optimized solution
  • small risk investment, owned by designers

In a similar way, when the business and the team work together with critical details, it creates understanding of the others’ perspectives and values.