The Zeigarnik Effect

An interesting discussion came up on one of the agile groups I subscribe to; the Zeigarnik effect. What this theory says is that people remember unfinished tasks better than they remember finished tasks.

The context of the discussion was retrospectives. During a retrospective, people will be less likely to remember the tasks that completed smoothly in the project, things that fall under the category of what did we do well. Since these are important, you want to make sure people remember them.

One of the tools I use in retrospectives come from Norman Kerth's book. The tool is building a timeline of the project and having people identify key events throughout the project. This is one way to help people remember. Another technique is to hold your retrospectives often; at the end of the iteration rather than waiting until the end of the project.

As I was thinking about the Zeigarnik effect for this post, I also realized it impacts your work in progress (WIP) limits for Kanban. The more things you have in progress, the more things that you are trying to remember. Get your WIP to high, you start forgetting what you're supposed to be working on. So how much unfinished work are you trying to deal with?

On a side note, if you teach, you can use this effect to your advantage. Give your students an assignment right at the end of the day. They will keep thinking about it until they have time to finish it. They'll learn their lesson better than if they finished the assignment in class.

Who do you hang out with?

It is often said you are a reflection of a few people you spend the most time around, so are you making good decisions about who you spend time with? As a triathlete, I know if I spend more time with fellow athletes, I will work out more. The other week I did a 30+ mile bike ride with some teammates. It was freezing weather (17 Fahrenheit/-8 Celsius) and we rode for over 2 hours (at which point my water bottles were frozen solid). I would never have done a crazy ride like this on my own, it was only because of the people I was with that pushed me to go so far.

The same thing can be said of our work-mates. If you're always spending time with the person complaining about how they don't like their job, you will start getting a negative attitude. If you spend a lot of time around a workaholic, you'll probably find yourself working more hours.

A lot of times we don't have much control about who we work with, but there is something you can do. Find someone that has those skills you want to improve on; maybe being better at public speaking or being more proactive. Now ask this person if they would be a mentor for you. If you spend even a couple half hour sessions a week, they will start influencing your behavior. It could be as simple as having coffee one day and lunch another day (you can usually decide who to spend lunch with).

Inspections

I have a client that has a practice of doing inspections, such as requirements inspections at the end of the analysis phase. Most of their projects follow a waterfall methodology. They implemented the practice because they were finding to many defects in testing and production, and they wanted to be able to identify defects earlier in order to reduce the cost to fix them. For their waterfall environment, that seemed like a logical approach to them.

However, we started talking about if/how inspections would work with agile, and particularly Kanban. We had just wrapped up project using Kanban techniques, and there were no defects found in testing. So if we did inspections, how would we do them?

On our project, our cycle time was 2-3 days per feature. We would then review/gain acceptance of that feature with the business owner. While this might seem like an inspection, it wasn't the same as what our client was doing. Their inspections didn't involve the business owners. A typical requirements inspection would involve the business analyst, someone from the quality engineering team, and someone from testing. So this would be an additional step every 2-3 days in our approach. As a lean advocate, my question is "what value does this add?"

The real answer goes back to Deming, and the 3rd of his 14 points (slightly paraphrased) - don't rely on inspections to ensure quality, build quality into the product from the start. If your quality assurance approach consists just of testing at the end of development, you aren't meeting Deming's point. However, if you have other QA activities such as paired programming, TDD, code reviews, frequent feedback from the business owner etc, you don't have to rely on testing to find all your defects, you've already worked them out, or at least most of them.

That's not to say we don't do any testing. It's still part of our overall QA approach. We also conduct our retrospectives to see how we can fold even better QA activities into our next project. I think with a couple more successful projects, I'll be able to get the client to see my perspective on this.

A new habit - daily retrospectives

So I'm trying to build a new habit. I've heard it takes 30 days for a habit to take hold, so check back in a month to see how I'm doing.

So what I'm trying to do is a mini retrospective at the end of each day. I'm taking 5 minutes before I wrap up for the day to ask myself a couple questions and jot down some brief responses in my journal;

• What were my successes and challenges?
• What did I learn?
• Who should I reach out to?

The 3rd question is a good one for me. The idea is to think about the people I interacted with that day. Did I promise to send somebody something? Do I want to follow up just to say thanks? Maybe there's a compliment I didn't have time to deliver earlier that day. I'm not the best networker, so this will help me make more of an effort to keep my network alive.

Out with the Old/In with the New

So have you made your New Year Resolution? I heard a quote that 4 out of 5 people fail to achieve their resolutions. It sounds like we need a better plan to succeed.

For many years, fire has been used in ceremonies; from Buddhist monks or Native Americans burning prayers to the Burning Man ceremony; this has been a way to get rid of bad karma and move on. I've participated in a burning bowl ceremony, where people write down what they want to get rid of (bad habits etc) and put them in a bowl to burn. I like the idea of getting rid of something old in order to make room for something new. If we want to lose weight, we need to give up our bad eating habits.

This might be a symbolic first step, but we still need a plan if we want to succeed. This time of year I plan out my racing plans for the coming season; key races I plan on participating in, goals I want to achieve etc. Based on that, I plan out the type of training I need to be doing, down to a weekly level. As I get into the year, the plan may get modified, but I have a plan to follow, not just a vague resolution to exercise more. We need this for any of our resolutions; a plan to ensure we can achieve success. So set some goals for the year (resolutions) and plan out how you're going to reach them. What are you doing this week to help reach those goals?

More on Culture

As I mentioned in my last blog post, one of the presentations at last week's P2P was on the challenges of implementing Agile in the Egyptian culture. Since I'm working with a team in India, I wanted to take a look at how Indian culture aligns with Agile.

One area of consideration is that of the self-organizing team. Indian culture supports team work. However, there is also respect for hierarchy, so the team may not feel empowered to make decisions. The team may feel the need to defer to a senior person for decisions. I have found that I am being asked to make more decisions compared to a US based team.

Indian culture also tends to avoid open confrontation. I think some conflict can be good as the team is developing. On my US-based teams, it isn't unusual for one developer to provide constructive criticism to another's work. This type of feedback should be delivered with a softer tongue for my off-shore team.

Another area that I have noticed relates to communications. Indian culture puts more emphasis on written communications. I know my off-shore teams have often asked for more formal requirements documents than what I expect from a US based team. One adjustment I've had to make is to provide more documentation for my off-shore team to work from.

Indian businesspeople tend to be tough, smart negotiators. While this conflicts the idea of customer collaboration over contract negotiation, successful negotiation is built on trust. However, building this trust can take time. In my case, I had time to start working on building that trust before the project work started up.

So what does this really mean? First, my points are just generalizations. For anyone working with other cultures, this type of understanding is just the starting point. You shouldn't rely solely on generalizations for determining how to work with your team any more than you would use New Yorkers as a benchmark for working with Americans from other parts of the US. For any cross-culture work, take the time to know the people you are working with.

Projects to the Point 1st Impressions

Day 2 of Projects to the Point has wrapped up and so far it has been an interesting conference. One of the themes of the opening day was change. Emad Aziz from Brisk Consulting talked about how change is the only constant. As project managers, this is what we have to deal with. Related to that, Dr Mohamed Tewfik Elmasri talked about organizations that are transforming (such as through a merger/acquisition) and how a key part of the change management process is communications; "People can deal with bad news, people can't deal with uncertainty."

Another interesting presentation was by Ali Zewail and ElMohanned Ahmed. They discussed the challenges of implementing agile in an Egyptian company from a cultural perspective. They even compared the principles of the Agile Manifesto to the cultural attributes of Egyptians. It made me think about my team in India and how agile aligns or conflicts with some of their cultural characteristics.