Thursday, December 26, 2013

Annual Performance Review and Your Brain

A lot has been written about the impact of performance review and why it is bad.  Organizations like Microsoft , Adobe and ThoughtWorks have changed their performance review system.  Rather than looking at why performance reviews are bad, let us look at what happens in our brain during the performance review process. Our brain understands stories better and so I will illustrate the concepts with a simple story.


TheBigCompany is one of the very reputed companies in the city and developer Dave was very exited to get a job offer from TheBigCompany.  During the interview process, the recruiter (and the hiring manager) had talked about incentives, including a possible bonus of $10,000 after a year, by evaluating his performance through the annual performance review process. The annual performance review is due shortly.  Dave has to fill in a self-appraisal form as well as get "feedback" from his manager Mark on his performance.  Dave has been a star performer, a eager learner, and a team player. But as much as he is a team player, the organization's performance review process is geared towards assessing the performance of an individual against his/her annual goals.  Mark wants to meet Dave tomorrow at 11:00 AM to finalize Dave's annual performance. 

Looking at Performance Review through SCARF:
Over the years, our brain has evolved to survive by "minimizing danger and maximizing rewards". David Rock proposes that there are predominantly five domains of social experience that our brain considers for survival: Status, Certainty, Autonomy, Relatedness, Fairness. What matters is our perception of these five elements  for a given stimulus (e.g. event / context) , regardless of whether the stimulus is real or false . These five elements are also interconnected, and affecting one of these elements (in a negative or positive way) has a domino effect on other elements as well. Threats and rewards activate the pain/pleasure circuits in our brain. Anything that boosts our SCARF is views as reward and we are motivated to do more of it (to gain pleasure). Anything that reduces our SCARF is seen as a threat and generates a flight/fight response (to reduce pain). Recent studies have shown that physical pleasure and activate the same circuitry as social pleasure (e.g. food, sex) and physical pain activate the same regions of the brain as social pain. By default, any external stimulus is categorized as a threat, unless proved to be otherwise. And some of these responses are so small that we may not even consciously notice it (and we can be trained to notice it by practicing mindfulness).

When Dave knows that he has to complete his performance review, his brain subconsciously initiates a threat response. There is a threat to his status, he is judged on how valuable he is to others (relative importance) . It is also about his recognition and "pecking order".  The mere act of speaking to his manager Mark who, in his perception, has a higher status creates a threat. If Mark is known to be critical, it will generate a greater threat response in Dave than if Mark is known as a cordial person.

Most of us are not very effective in giving feedback, and when someone gives us a feedback, there is an immediate (but subtle) threat to our status. The threat is more if the feedback is given by someone with authority and power and is less if it from someone whom we trust. Most of the time, we defend our stance, to protect our status and to not be perceived as less than what we were perceived. This explains someone defensiveness when they are confronted/given feedback.

Dave's meeting with Mark is characterized by uncertainty. The only certain fact is that Mark and Dave are going to talk about Dave's performance. He is only given annual feedback and consequently has very little chance to take corrective actions to receive rewards (the $10,000 bonus + other incentives). There are other factors (like the notorious bucketing system, company performance,  team's performance, formal and informal feedback about him given by others to Mark) which add up and the implication of these are not known to Dave till he gets his final results.

Our brain has evolved to be a pattern recognition machine. It likes rhythms, cadence and cycles. It receive patterns from outside world, store them and makes predictions based on what it knows and what is happening now. When the expectations are met, the reward/pleasure circuitry is activated (as chances of our survival increase) When those expectations are not met, our "error detection circuitry"  (orbital cortex ) and "fear circuit" (amygdala) is activated. Priming the brain (in this case, Dave knowing about the meeting ahead of time) about a future threat event does not reduce the anxiety 

Dave has very little control or say (autonomy) over determining the outcome of his review. And if TheBigCompany is like any other big company, Dave would have very little say in determining what his next year's goals would be. 

Autonomy and certainty are very closely linked. A sense of autonomy is the degree to which a person can control his or her environment to maximize the chances of survival. When we lack a sense of autonomy, blood flow is directed from our prefrontol cortex (our thinking brain) to limbic system (also called as the reptilian brain). Our limbic system is much older than prefrontal cortex and is tuned to maximize our survival by equipping us to take a fight/flight response instantaneously. Having a choice (or even a perceived sense of autonomy) reduces stress and consequently reduces the arousal of our brain's limbic system and activates our prefrontal cortex.

Humans as social beings. During evolution, our chances of survival increase when we lived together as tribes and hence a large portion of our human brain is devoted to social networking. Recent studies show that when our brain is at rest, the default mode network (DMN) ( a type of neural circuitry) is active and there is a strong correlation between areas of brain responsible for social cognition and DMN. When we interconnect our thoughts, emotions and goals with others whom we can relate with, we release oxytocin, a pleasure chemical (This is the same chemical release by newborns when they are fed). Recent theories on Attachment, mirror neurons only bolster the fact that we are more social than what we initially thought. 

When Dave is evaluated with respect to others, his sense of relatedness (with others) is decreased  as it creates a "Dave vs. others" situation regardless of whether Dave gets his reward (If you are a manager, you now know that this is a double edged sword. Regardless of who gets rewarded, it creates a me vs. others situation).  

People's perception are different and what Mark perceives as fair and may not be the same as what Dave perceives as fair and just. The more Mark tries to justify his stance, the more Dave may defend to say why it is fair that he should receive the reward (Sometimes, Dave's dialog may be an internal dialogue on why Mark is wrong and why he is right). 

Fairness tastes like chocolate. When you perceive something as fair, the same regions of the brain (ventral straitum) are activated as when you eat chocolate. A sense of fairness drives a lot of our emotions and everyday behavior. A perceived sense of fairness can build positive emotions  (releasing dopamine and reinforcing reward based learning). Making something right (or fair) also releases serotonin, a chemical which can calm the brain (the same chemical is released with anti-depression drugs like Prozac) When you perceive someone as being fair, an increased sense of trust is developed, reinforcing "Relatedness" and releasing oxytocin. When the expectation of fairness is met, it creates more certainty for our brain. When the expectation of fairness is not met even slightly, especially from someone whom we trust, strong hurt feelings are generated which may last for many days. 

Abraham Maslow may have been only partially right in suggesting that our physical needs are the primary needs for motivation. New research in the field of social neurobiology suggests that our social needs are as important as our primary physical needs, if not more.

Monday, September 9, 2013

Team Agreements as Social Contracts

Teams usually have a contract. Most of the time, it is unsaid and is in the form of an mutual but unsaid expectation. And when these unsaid expectations are not met, it usually creates differences in opinion, negative feelings towards others, suppression of negative emotions, avoidance to deal with a problem, procrastination, group think (because of avoidance), group behavior(where you talk with someone else, who is usually sympathetic towards you, about the problem instead of confronting the actual person with the problem) and many other challenges.

These challenges can be overcome by explicitly having social contracts during the formation of a team and updating them regularly. Team agreements can also be formed when a new initiative is undertaken.Research shows that even having one bad apple in the team can be very disruptive. If you are a part of a team and you do not have explicit social contracts, it is better to form them now, than repenting about (not having it) later.
This is a living document, and is prominently posted in the team area (if the team is co-located) or in a wiki, which is easily accessible. A good facilitator, who can be neutral and who does not have any stake in the outcome of the meeting, can help the team in creating the teaming agreements.  These agreements usually go beyond roles/responsibilities and schedules (example - what time should be have our Daily Scrum). These agreements usually serve as a foundation for self-organizing team.  Here are some questions that can help you form better teaming agreements (these questions serve as a guideline for the facilitator )

General Questions
  • What is our purpose/goal/vision?
  • What is the kind of environment/culture/atmosphere should we(team) want to intentionally create?
  • How will you know when you have it?
  • What are our values/principles that will guide us?
  • If this team is the epitome of these values, what are the corresponding Behavior, Attitude, Skills and Knowledge  (BASK) that will support these values?What will help your team excel (BASK)?
  • Two of the Scrum values are Openness and Courage. Psychological safety is important for openness, to be courageous. How can you create a safe environment?
  • What can you count on each other for?
  • Sometimes, a few vocal people dominate the team. Sometimes, a few do not participate. How will you ensure everyone's participation?
  • How do you want to be together when things get difficult?

  • What do you expect from the coach?
  • What should the coach expect from you ?
  • How will you hold your coach accountable to high professional and personal standards? 
  • How should the coach expect to get feedback from individual/team if he inadvertently slips from his high standards?  (example - The team can call for "Protocol Check" with the coach/other team members)
  • What individual/team behaviors will not surprise him? What individual/team behaviors will surprise him?
  • How do you expect the coach to give you feedback, especially difficult feedback? What are some acceptable ways? What are not acceptable ways?
Conflict and disagreements
  • How will the team handle conflicts and disagreements?
  • What are some of the acceptable behavior during a conflict?
  • What are not acceptable (during a conflict)?
  • When should a conflict be resolved?  (example - if someone does something unpleasant, you cannot bring it up as an issue after 4 weeks)

Decision Making:
  • How should we make decisions?
  • How do we make decisions when not everyone is present?
  • If only a representative gets to represent the team, what is our protocol that he/she should follow in making decisions?

  • What is our responsibility, as a team (and as an individual)?
  • How do we, as a team, handle Scrum Master/Product Owner responsibilities when they are off?

Distributed Teams
  • One of the pillars of empirical process is transparency, how do we create more transparency when our team is distributed?
  • How will our on-shore and off-shore teams stay in sync?

  • What are our Meeting Norms (Meeting norms/agreements are very similar to teaming agreements)
  • If some one external to our team participates in our meetings, what are our expectations from this person to follow/not-follow our norms? How do we communicate this to them?

  • How will you hold yourself mutually accountable to each other to these agreements?
  • What if someone breaks these agreements?

You need not ask all the questions, they merely serve as a guide to jog your memory. If you feel strongly about not asking a question because it makes you uncomfortable, then that is probably a question you should ask. Think about it !!

Monday, June 17, 2013

The Multitasking Myth - A Brain Based Explanation - Part 1

It amazes me when people, especially developers, tell me that they are great multitaskers. Time and again studies  have shown that multitasking reduces performance. Then why do managers insist that employees should be able to multitask? Studies show that even with intentional priming (advance notice that the person will be switching to a different task), there is a switch cost associated with multitasking. With mobile phones, cloud computing and fast paced work environment,  a cousin of multitasking, continuous partial attention, has become even more prevalent (how many times did you unconsciously check your email in your mobile phone when you were in a meeting)

I do want to emphasize that there is a difference between consciously doing two things simultaneously (multitasking) and doing one of the tasks subconsciously (ex - talking over phone when driving to work. They use different parts of your brain). By multitasking, I mean consciously switching between tasks to accomplish something. Some of the reasons that I hear for multitasking are

  • I do not want my employee/consultant to be idle, I am paying him for his/her time. 
  • All stakeholders are important, I do not want to antagonize any business stakeholder by telling him that his project is less important and will be started later. 
  • I am not able to prioritize stuff (projects, user stories, work items, etc)
  • We prioritize stuff, but only part of the first item can be implemented now, so we do it, then switch to the next task. If we encounter a blocker with the second item as well, we switch to the third task.....
  • My organization is different because ....... (add your own reason here)
  • My manager tells me to because .....(hint: if he tells you to, show him this blog)
I am not here to convince you that multitasking is bad and that you should fix its root-cause.  I will leave it up to you to decide if you want to take advantage of how our brain works (or work against it). Our brain's Pre Frontal Cortex (PFC) is primarily responsible for the executive function including understanding, differentiating, prioritizing, idea generation, remembering and anything which we do consciously. In the next blog, we will look at what happens when we multitask and why there is a cost associated with multitasking.

Sunday, April 1, 2012

Possible new scrum extension

Scrum is evolving and changing. Product Backlog Items evolved from prioritized to ordered. Product Backlog grooming is becoming a Generally Accepted Scrum Practice (GASP). Charles Bradley has also blogged about some new direction scrum is taking. Burndown is no longer an artifact, but increment is. Ron Jeffries frequently writes (in scrum development yahoo groups) about small, similar sized user stories and working in smaller chunks instead of large user stories.

David Starr has already proposed an extension (Feature focused daily scrum ). Along these lines, I want to propose a new extension "JIT Planning"

Proposed Name
Just In Time (JIT) Planning

The PO already has an ordered list of backlog items.The team starts the spring with a planning meeting where they together to discuss the features that will be taken up during the current sprint.  The planning meeting consists of two parts, the "what" part where the PO and the development team understands the scope of the backlog items which need to be considered for the current sprint (mostly in the form of user stories), and the acceptance criteria for each of those backlog item. The Product Owner should be present during this part of the meeting. The second part consists of the "how" part where the team decides how to implement the the stories and the tasks associated with it. Usually, the sprint backlog is a set of tasks associated with those product backlog considered for that sprint. Though the product owner's presence is not usually required for the second part of the planning meeting, he should be able to help the development team if any clarification is required. For teams where the sprint duration is 30 days, the spring planning meeting can take a whole day (8 hours, split as 4 hours for the first part and 4 hours for the second part). For teams having a shorter sprint duration (say 2 weeks), the sprint planning meeting is proportionately short (4 hours for a 2 week sprint).

Proposed Change

The scrum team maintains the cadence by having their regular "what" part of the sprint planning meeting. These backlog items conveys the theme of the current sprint.

The "how" part  is broken down into a series of "JIT planning" meeting for each PBI.  The development team initially addressed only for the top-most backlog item. It then works on turning this PBI into a completed feature. Once it is complete, the team picks up the next backlog item, discusses different tasks associated with it and discusses how to turn that to a shippable increment. This is repeated for all the backlog items taken up for that sprint.

1. The team is co-located or has a very high bandwidth communication channel so that the team can swarm over/plan an impromptu "JIT planning" meeting once a feature is implemented and tested.

2. The backlog items are well groomed, estimated (story points) and/or diced to small stories which can be implemented in a day or two.


1. One Piece Flow helps the team deliver as fast as possible: The development team explicitly focus on one PBI at a time without switching context between backlog items. This should help team complete the feature faster. The impediments for completing that particular feature become much more evident (since the team cannot work on completing the feature) and those responsible for removing the impediments (the scrum master, product owner and management) are much more proactive in identifying and removing any impediments. Also, no one, including the team members can gloss over  the impediment by saying something along the lines of  "I have this impediment for this top priority feature, but that's OK because I am focusing on implementing some other product backlog item".  Also, the scrum master (and who ever is responsible for removing the impediment) becomes more effective as he is focused on removing all impediments related to a feature than just shot-gunning on impediments of multiple backlog items. With a good backlog with well defined acceptance criteria, backlog items should be implementable in 1 or 2 days. With stories that small, no explicit tracking is necessary ( Conversely, if the story is large, which may take 3-4 days, it might be a better idea to track the remaining efforts for the feature using a burn-down. Also see #6)

Johanna Rothman modified the daily stand-up question to "What feature did we complete yesterday ? What feature are we going to work on today?  What are the impediments to implement this feature?" JIT planning and one piece flow (execution) sets a boundary for the team (sprint backlog being implemented), and helps answer the modified daily stand-up questions.

2. Encourages team becomes more cross-functional: Since the focus is on completing the feature, it challenges the team members to get out of their comfort zone and learn new skills (if required, or hone their existing skills) to complete the feature at the earliest. A tester can no longer say "I am done writing the automated test case for this feature, but since the DB work is not done, I cannot fully test it" . Instead he focuses on contributing what ever he can to complete the database related task.

3. JIT planning eliminates waste:  The development team forecasts the product backlog items which it can deliver during a sprint. As the team gains more experience (with scrum, with the product, with technology and knowing each other), their estimates get better. But they are still estimates. By only targeting ( tasking out) one PBI at a time (and completing it), it avoids planning for features which may not be completed during the current sprint. Why plan for something which you might never need?  Remember- one of the agile principles is " Simplicity -- the art of maximizing the amount of work not done -- is essential"

4. Plan at the Last Responsible Moment (decide as late as possible): The team continuously learns about the product as well as about the technology used to build the product. Though the tasks associated with the sprint backlog can change, with JIT planning, we plan for the PBIs after gaining as much as much knowledge as possible. Since JIT planning focuses on the implementation for only one PBI, chances that the tasks associated with the PBI being missed out are much less. If the sprint duration is long (say 30 days), planning out the tasks just before the execution helps the team in easily remembering the design/execution strategy. On the corollary, it is very hard to remember a discussion about the tasks, designs and possible execution strategy (for a particular backlog item) which happened 20-25 days ago.

5. Development team member does not lose much if he he away during spring planning: Face it, in real life there are unforeseen emergencies, vacations and off-days. And if that happens to be on the day of sprint planning, he/she is missing out a lot. Though I would not like to call it an advantage, JIT planning minimizes the impact of a team member being away during the "how to" part of planning by distributing the "how to" for all the backlog items throughout the sprint. I assume that, in any team, the other team members will bring this person up to speed once he is back and the "burden" of getting that person up to speed is much less. Disclaimer: This point, in no way, encourages team members to stay away during planning, instead , I just want to convey the the impact of that event is reduced for the person and for the team.

6. Focuses on feature implementation explicitly rather than tracking efforts: Most of the commercial tool vendors have some form of sprint burn-down charts where the "ideal" trend is mapped along with the "actual" effort remaining. As bad as it might be, this brings up comparison between ideal burn-down, the actual and the variance. If JIT planning is used an ideal trend-line for the sprint backlog would not be possible as not all tasks and efforts have been identified for all the sprint backlog items.  If the stories cannot be split to smaller stories/features which can be implemented in a day or two, but takes three, four or five days to complete, it might be worth while to track the remaining efforts (for the tasks associated with that feature) using a burn-down chart (only for that feature). Considering this, the sprint can have as many "feature burn-downs charts" as the number of features taken up for implementation for the current sprint.

These are some of the ideas which, I hope, will help the team be more efficient. Please feel free to share your thoughts.

Tuesday, February 21, 2012

Reasons why your agile adoption might fail

Rebecca Parsons gave a wonderful talk on why agile is not the easy way out, but is the only way. Having worked on multiple projects agile/lean/scrum, I can only agree with her. Most of the organizations adopting agile feel the pain of traditional methodologies and think agile is the silver bullet which can solve all their problems. Other organizations say they are following agile, without even knowing that there exists an agile manifesto, simply because they don't want themselves to be excluded in the race of adopting agile. Some organizations openly admit that they are still following traditional methodologies, because they are not comfortable with agile. Agile is usually associated with a lack of disciplined development efforts and loss of control. Nothing wrong with a traditional waterfall based SDLC, but time and again we have seen that a lot of software projects either go beyond their allocated budgets, time-lines or both. Though I strongly suspect the methodology employed in the recent Standish group, which reported more success with agile projects, I believe that if a more methodical survey is carried out, we would still arrive at the same conclusion. VersionOne recently published some statistics on agile adoption. Though the percentage of agile projects which did not fail was about 16%, the top category of failure was "do not know" - 13%. These are some of my thoughts on why agile adoptions and transformation fail

Failure to understand agile principles, but just implement the practices
Agile principles are like roots of the tree, they hold the tree together. The trunk and branches represent different processes (XP, Scrum,Kanban, etc) and practices (TDD,CI, Pair programming,etc) respectively. Most of the times, we neglect what we don't understand (the agile principles) and instead focus on what is easy (the practices). And the results are disastrous. We can see that from the survey that at least 78% of the respondents practiced at least one of the agile practices (daily stand-up being the most widely adopted practice at 78%), but 84% of the agile projects failed for one reason or the other. What would you think of a doctor who treated you for the symptoms, instead of understanding the underlying cause and treating the cause ? I can only attribute this kind of failure statistics to the fact that people adopt the practices without understanding why they need a certain practice.

Lack of clear understanding on what is agile
Agile, to me, is a journey. Not a destination. It is a journey striving towards continuous improvement. And it goes beyond the development team. Unfortunately most of the adoptions stop with the IT department. And to fully realize the benefits of agile development, other departments should also be educated about agile principles and why it helps development teams. These include sales/marketing, Human Resources and facilities as well. When sales/marketing is not fully involved with the transition, they promise unrealistic features and delivery dates to their customers. They associate agility with flexibility and speed (and this is true) and that the dev team should match their expectations (which, realistically might be beyond the teams' capability). Regardless of how good the team is, such unrealistic expectations set the foundation for failed projects. No methodology can fix these kind of issues.

Lack of education
One of the organizations I worked with was ready to transition their very well experienced Project Manager (who also had a very good understanding of the domain) to the role of a product owner (in fact, I suggested it) but refused to send him to a Product Owner Training (citing cost reasons). It is easy to cut down on things which you can quantitatively measure (like cost), but hard to derive ROI on things which are subjective/qualitative, like improved product management. Granted, if that person had seen how a good product owner works, I would not have had much concerns, but that was not the case. The product owners were themselves new to scrum and were half way around the globe. Now, I don't mean to say that a simple two day training would make a good product owner/scrum master out of you, but that is just a starting point. If you have a coach who can guide you and your team, that is equally good. Regardless, learning is a continuous process and you learn from conferences, books, blogs, subscribing to distribution lists (Yahoo groups, LinkedIn) and from peers.

Adopting agile and expecting that it is going to solve your problems
Agile is about transparency and visibility. Agile gives visibility to your problems. It will not solve problems for you. If you hire bad programmers, it is going to make it more evident, but it is up to you to hire better programmers. If the business stakeholder is sitting half way across the globe and is hard to collaborate with him/her (and it is true for even someone sitting in the next cubicle desk, but does not want to collaborate), agile is going to make this problem more visible, but does not solve this problem. If you are building the wrong thing, but skipping sprint reviews, "your customized" agile adoption will not help you. If you have customized scrum to accommodate change requests during sprints, say goodbye to good processes and say hello to the devil. If you pile up technical debt, you will eventually pay a price for it. You are better off paying it early than paying it later.

We are resistant to change
I once read a story about an old dog sitting on a nail and whining all night. A traveller asks a wise man why the dog does not move away to which the wise man replied "It does not pain enough for the dog to move away". A lot of us do not want to change the way we think, simply because we are used to it, it feels comfortable and changing any of that will make us uncomfortable. We justify it saying that "a known devil is better than an unknown angel". Some of us are like ostritch which burries its head in the sand. We don't want to acknowledge a problem because if we do acknowledge it, we will be forced to take action. But change is the only constant. And We resist change because we lack the discipline to follow new practices.