Today I repaired my TV. I have had the unfortunate events that the two TVs in the House died within a month of each other.

Now I should mention that I do not have experience repairing TVs, but I have assembled computers in the past and have pulled apart my fair share of electronic devices as a kid. I also have an electrical engineering degree which I haven’t used in over 20 years.

It started a few weeks ago when the TV died. The TV is an old Sony Bravia 32 inch. It started having the standby light blink twice. A quick search on the internet revealed a power supply issue. So the next day when the sun was up so I could get good light, I took the back off the thing and looked at the power supply board. I have heard before that a common problem with LCD TVs is that the capacitors blow. Not in this case, they all looked fine. The problem was elsewhere. I decided to replace the board for the power supply. A quick search online and I found one for $83 in China. Before I went out and bought the board, I thought I should check repair costs. The next day which was Monday, called up a few places, the cheapest was $66 just to look at the thing. Not repair. So I decided to try the repair myself. I had nothing to loose. A replacement TV would cost only $200 if it was beyond repair. My work colleagues told me that I was wasting my time, just get a new TV, it will be better, but I thought of this as a learning experience. If I can repair the TV, I learned something. So I bought the part and waited the two weeks for it to arrive.

Well, it arrived this week and today is the day that I put it in.

First things first, I took the back off. There are quite a number of screws on this thing.

Then I took the power board out. There are only 6 screws and 3 ribbon cables that attach to it.

I then pulled the board out gently, then put in the new board and started putting the thing together. The whole process took about 20 min at most.

Then came the test. The TV worked!

So what has this got to do with agile? Well, a lot of companies have the “install” mindset. They purchase a big “solution”, have the vendor or a consulting company like Wipro, Capgemini or Accenture do the implementation and after a lot of pain and customization have a new thing to play with. The problem with this approach is that the new product gets thrown over the fence to the internal team to maintain. If the team is lucky, they were involved in the implementation, but this is not always the case. If they are involved, its usually at a limited capacity. What ends up happening is that the team although made up of competent people have no idea how this complex system works and they end up  just doing what they know. Sometimes all they know is how to restart the system.

If anything goes really wrong, it’s a call to the vendor who then has to come out and fix the issue.

This is usually not free and can cost quite a bit, if you do not have a service contract.

The thing is that you have reduced your competent people to incompetent people because you have denied them experience. You have denied them an opportunity to learn. Companies with the install mindset see the work as the goal. The work needs to get done, so get the outside people who know the work to do it. This is fair enough, but you need your own people deeply involved to get the knowledge. Not a one hour handover at the end of the project. This is just asking for trouble in the long term.

A better mindset is to have a “learning” mindset. You can still have the vendors and implementation specialists start the work, but you need to get your own people heavily involved. Get knowledge transferred from the implementation specialists to your people. It may be a bit slow at first, your people are learning, but you eventually have people just as competent as the installers. If not more as they also know your business and environment.

I have read that Toyota tries to implement and repair their own systems themselves. It means that their people can repair the equipment quickly, it’s part of the operators job. They know how t repair it because the were the ones who implemented it. They were given the knowledge. It means less downtime, more self reliance and actually lower cost. 

So let your people have a safe area where they can pull things apart and learn. Just like I did with my TV. It will help them and your company become more self reliant. 

Oh, as for the other TV, I ended up buying a bigger TV to replace it, but I pulled the back off today as well to see what went wrong. It seems to be a capacitor issue. Two capacitors have blown. When I get the chance, I’ll be heading off to Jaycar, an electronics supplier here in Melbourne for a couple of capacitors to replace the blown ones. Wish me luck on seeing how I get this one fixed. I’ll update on the result.

With my interest in human psychology, I recently came across the Yerkes-Dodson Law. The Yerkes-Dodson law is not new. It was originally developed by psychologists Robert Yerkes and John Dodson way back in 1908. This is an interesting theory. The law basically states that there is a relationship between the amount of mental stimulation one receives towards a task and their performance. If the level of mental stimulation is too low, then performance suffers. If the level of stimulation is too high, then performance also suffers. There is a middle ground where for the mental task, performance reaches its optimum point.

I have experienced this myself, where given a task that has no challenge, I am bored out of my mind and tend to take longer to do the task. I tend to find distractions. There is the other way too. If the task is too hard, over and above my current skill set, I get frustrated, I don’t give up, but I find the task difficult and thus I do not accomplish as much, but if the task is challenging enough and I make progress, even little progress, then my interest increases. My focus increases and I’m able to accomplish quite a bit. This state is known as Flow. Coined by Mihaly Csikzentmihaly where Flow is a mental state where time seems to stand still. Focus is at its optimum and the world seems to fade away and all that there is is what you are currently working on. This state is one that I call, in the Zone.

So how do you reach this optimal state, well, from what I understand, the subject needs to be put under a little stress. Now this seems bad, but there are actually 2 levels of stress.

Eustress, this is good stress. This is the stress that you feel when you feel challenged. Something that you have control over, something that stretches your mind. The other form of stress is Distress. This is the bad sort of stress. This is the stress that gives you a mental breakdown.  The strange thing is that the body cannot tell good stress (Eustress) from bad stress (Distress), its all in our perception. It is also very subjective to a person. One situation, someone may take as a challenge, and feel good about the challenge. Another person in the same situation may feel overwhelmed, freak out and not know what to do. Think of your parents or grandparents and how stressed they get when confronted with a TV remote control with quite a few buttons. At least in my case, my Mother and Father who are both in their 80s could not turn on the TV via the remote just because by looking at the remote, they were overwhelmed. Then you have me who works in IT, sees a remote control with a lot of buttons and thinks nothing of it. I pretty much play with the buttons to see what happens. It is a minor challenge.

By putting the subject just outside their comfort zone, just adding a little stress – not too much, and time with no interruptions, the person can reach the state of flow at be at their peak performance. Maintaining this state is very difficult and exhausting, but it makes for a happier worker.

The problem is that the current workplace does not make for this state to happen easily. You can put on headphones, but even then there are constant distractions and interruptions, but if the team is aware of it, maybe they can do something about it.

So, are you challenged just enough to get into the Flow state?

I have been reading Edward De Bono’s Six Thinking hats, the 1990 edition,  and I find it an interesting concept. He talks about the compartmentalisation and segregation of thinking when trying to find the solution to a problem or generally trying to resolve some issue.

The thinking has been segregated into six categories, hence the six thinking hats and each hat has been given a colour. If you are wondering about where he got the idea for hats, it comes from the phrase, “Put on your thinking cap”. The colours are…

White – For facts and figures
Red – For emotions and feelings
Black – For negative thinking
Yellow – For positive thinking
Green – For creative thinking
Blue – For the overall thinking process

To go into these in more detail.

Thinking

According to De Bono, there are two types of thinking.

• Coping Thinking where your thoughts are just there for day to day life.
• Deliberate Thinking. This where where you actively try to think. This is where his book comes into play.

Deliberate thinking is when you actively need to solve a problem which those of is in IT do quite frequently. Much like Carol Dweck’s work in Mindset, De Bono is of the mind that thinking is a skill that can be improved. By actively putting your mind into certain “Frames” you can change your brain chemistry and think outside the box.

The following is my take and learnings on the six thinking hats.

White Hat Thinking

White is Cold, Neutral.

White Hat thinking is the first of the 6 hats. It is concerned with only Facts and Figures. It is not concerned with how to interpret these facts, nor does it deal with trying to resolve the relationships between the facts and figures. It is only to cold hard facts that we are interested in. Now, according to De Bono, there are 2 types of Facts.

• Checked Facts
• Believed (or Unchecked) facts.

A checked fact is something that has been verified, either through reference or through experimentation.

Believed facts are where things get interesting. Believed facts are where you rely on something not verified. For example, your memory. You may have read something a week ago, not be able to produce the reference, but you “Believe” that you have read it somewhere. Therefore this gives you an outlet to state it., but because it relies on something fallible, the human memory, it is considered an unchecked fact, and an unchecked fact is of lesser worth than a checked fact.

The white hat is also not concerned with “opinion”. Specifically, your opinion. That is for another hat. Whereas, if you report the opinion of someone else, then it is a fact (or unchecked fact) that that person had an opinion on the subject.

Facts are also timely. There may be times when a fact becomes irrelevant.

Be careful on how you state the facts and figures to as not draw an opinion or interpretation. Be as neutral as possible.

Red Hat Thinking

Red is the colour of anger.

Red Hat Thinking is concerned with emotions. These can include

• Hunches
• Intuitions
• Impressions
• Feeling and so forth

You do not have to justify a feeling, in fact you shouldn’t under the Red Hat. Something may or may not feel right.  Feelings are completely irrational and rather than ignore them, the Red Hat gives a legitimate outlet for them. Whereas the White Hat was completely cold and neutral, the Red Hat is where you can make your opinions known.

There are 3 points where emotions can affect your thinking.

• Background emotions. These take the form of fear, anger, suspicion, jealousy and love.
• Initial Perception. For example when someone says one thing, and you jump to a conclusion in your head, you may think that they are saying something out of self interest or trying to make themselves look good.  The third is
• Emotions from After the fact. Once you have been given all the information, then how do you feel about the situation.

Once emotions have been made visible, then they can be explored further or may be even changed through satisfying those emotions.

The Red Hat is there to reflect on the emotions that are produced and explore them further. They should not be used in overkill.

Black Hat Thinking

Black is the colour of negativity, darkness.

Black Hat thinking is about the negative side of the subject. It is not the emotional negative side, that takes place under the Red Hat. Black Hat thinking  deals with the negative logical thought.

With the Black Hat, we are trying to find out what is wrong. What are the faults, but not in the sense of tearing the idea or subject matter down, but in finding out where the weaknesses are with the intention of improving those weaknesses and faults under another hat. (Yellow or Green)

Black Hat is concerned with finding the negative consequences. Not the solutions to those consequences, but just the stating of them.

Black Hat thinking is also concerned with alternative paths that the proposed solution may take. It can also be used to point out where facts are wrong or irrelevant.

Black Hat thinking isn’t concerned with solving the problems that have been found out. It is only concerned with finding out those problems.

One thing that Black Hat thinking definitely isn’t is an Argument. It is not there to show doubt of the solution. We are pointing out the areas that need improvement, areas of danger, areas where we could be wrong ,areas of risk, not tearing down the subject matter, nor are we trying to deny the validity of the subject matter. This can be very difficult as it is a lot easier and more satisfying to tear something down than create or improve something. Tearing something down is a childish indulgence as DeBono puts it. The equivalent of knocking over a tower of blocks. Finding out where the tower of blocks is unstable and finding ways to reinforce those blocks is a lot harder.

In the area of new ideas, it is harder for the brain to switch from a mindset of negativity to that of positive thinking, therefore it is recommended that the Yellow Hat precedes Black Hat Thinking.

Yellow Hat Thinking

Yellow hat is the colour of positive, sunshine, happiness.

Where Black Hat is concerned with the Negative aspects, Yellow Hat is concerned with the positive and optimistic aspects.

We are concerned with where will the subject matter work. When focussing on the positive aspects, even when it seems futile, it is possible that non-obvious positive aspects will be found that would not normally be found any other way. Value and benefits are not always obvious at first glance.

When using the yellow hat, over optimism is encouraged, but not all things are equal and thus should be categorised as either

• Proven
• Very Likely
• Good Chance
• Even Chance
• No better than possible
• Remote or Long shot.

Keep in mind that a remote or long shot idea (A Black Swan) has been known to succeed spectacularly.  Yellow Hat is constructive in nature. You build up an idea, find the positive aspects. Then afterwards use the Black Hat to find the flaws.

Under Yellow Hat you can generate proposals, find positive aspects of proposals and continue developing those proposals or ideas up.

Faults found under Black Hat thinking can be corrected. Ways around those faults, or solutions can be found.

Yellow Hat Thinking is the frame of mind that says “It will work, we will make it work, we will find a way”, but you have to be a realist, and if the benefit is poor under the best scenario, then sometimes the idea may not be worth pursuing, but you need to give it every chance to try to succeed.

Yellow Hat thinking deals with vision and dreams. It helps give a goal to strive for.

Yellow Hat thinking does not deal with creativity, it only comes up with the opportunities, The Green Hat then explores those opportunities and finds new and creative ways to exploit those opportunities.

Green Hat Thinking

Green is the colour of nature and creation.

The Green Hat is about new ideas and looking at things in a different way. It is about change, deliberate and focused change. This is what makes the Green Hat special and valuable. The Green Hat gives an outlet to give illogical and provocative ideas, to bring in new concepts that can go against the grain. Sometimes it those counter intuitive ideas that give something special.

Ideas can be fragile and easily killed and thus need to be protected from negativity that the Black Hat can bring. The Green Hat gives a safe haven for ideas to flourish and thrive.

The Green Hat gives a time to deliberately think creatively. It is not important that you gain an outcome that is creative, it is not important that there is an outcome at all. It is quite possible to sit, think and not come up with anything at all. Which by the way isn’t how it works. What is important is that you make the effort to spend time looking at the subject in different ways, to try. For without trying, you will never know what you could have achieved.

Ideas can be completely illogical or impractical, but the exploration of these ideas can lead to something more practical. For example, I want a robot to do the boring work for me. This can lead to automation through scripts and sites like https://ifttt.com/.

Other times ideas need to be nurtured. The initial idea may not be fully formed. It needs work to get more traction.

If you have troubles generating ideas, De Bone goes through a couple of ways to spur creativity. One method is through provocation. Provocation is to deliberately provoke ideas through injection. The injection can be something completely absurd. It can be something completely random.  One example from the many that De Bono gives is that “Shoppers should be paid to buy things”. Now, thinking, why would you pay shoppers to buy something, but if you have a loyalty card or received a cash back from a promotion, this is exactly what a practical application of an absurd idea can lead to.  Another method of provocation that De Bono mentions is to create a random word. Pick a random number, go to that page in the dictionary and find the first noun.  For example my random word is “Friend” taken from a poster of 100 essential words that is for my 6yo Son to learn. The subject matter is a “Wall”, in this case another random subject. Something nice and boring. The subject matter would normally be something that you are discussing. Then you find the properties of the random word and try to see how it can relate to the subject.

For example, just coming up with these myself now.

Friends – Communication, Sharing.
Have a wall where put notes for one another.
A wall is a flat surface, a screen of sorts, an app that allows friends to communicate, share information (Yeah, I know – I’ve just thought of Facebook), but you get the idea. One thing you don’t do which I have just done is tear down an idea. Explore it further. See where it takes you. Also, do not go with just the first idea that comes into your head or the teams heads. We have a tendency to accept the first thing that we think of, or at best the most obvious alternatives and leave it at that. Creativity is about going beyond the obvious and exploring what is not obvious. What is hidden, especially if it is hidden in plain sight.

Once you have your ideas, then apply constraints too them. There is no point trying to pursue ideas that you do not have budget for, but see if there is a way to do things within the budget.  Samuel Pierpont Langley had all the budget and time in the world and the best minds on payroll to make the first heavier than air flight, yet two brothers who owned a bicycle shop were the first make powered flight a reality. Sometimes having next to no money is a good thing.

So when do you invoke the Green Hat. Basically any time you want. There may be a formal time where you invoke the Green Hat and be creative, there may be times when you are exploring something through for example the Red Hat, you pause and then start invoking the Green Hat and explore the thoughts creatively and see where it leads to, but don’t take things too far. Creative thinking can lead you away from the problem you are trying to solve, this may or may not be a good thing. Judgement needs to be taken into account. What you don’t want to be doing is trying to “find better ways to shaving a Yak” when the initial problem was “how do we improve our deployment”. The Blue Hat is there to help you keep in line.

Blue Hat Thinking

Blue is the colour of the sky, overarching everything

The Blue Hat thinking is different to the other hats. The Blue Hat thinking is more about the orchestration and facilitation of the other hats. For example, you could use the Green Hat to generate new ideas, White hat to get some data on the idea, Yellow Hat to explore the positives of those ideas, the Black Hat to find the flaws and maybe cull a few ideas, Yellow Hat again to fix up those flaws, Green Hat to find creative ways for some of the more tricky issues, then Red Hat to get a feeling of what feels right.

The orchestration can be predefined, for example have the team put on their Blue Hats and determine what order the thinking process will take. At this point we are not concerned with the subject matter, but how we will think about the subject matter. The Blue Hat is a very strange concept indeed as we are use to thinking as something that flows rather than something that is deliberately organised, but that is precisely what the six thinking hats is for. The deliberate organisation of thinking.

The Blue Hat does not necessarily only deal with the orchestration of the hats, it can be used to to determine priorities and constraints on the subject of the thought process.

I mentioned previously that with the Green Hat and creativity that things can drift, it is under the Blue Hat that focus is kept. The Blue Hat can be used to bring the thought process back in line. It can also be used to determine if the focus of thought is narrow or wide. It is completely up to the circumstance.

The Blue Hat also calls out incorrect thinking at the wrong time  for example if someone is expressing feelings during the white Hat process. Saying that, you should not go too overboard about controlling the hats. Some hats do overlap. For example the Green and Yellow can have traits of one another. You also do not want to get into a situation where someone is invoking a different hat every seconds statement. The whole idea of the hats is to invoke a certain mindset about the thought process. Not to be a process unto itself.   There may be even times where the discussion does not fall under any particular Hat. That is ok too.

My Thoughts

The concept of deliberate thinking is very interesting and I can see how it can be used for problem solving. This sort of segregation of thinking would be great for Retrospectives in my opinion. For example, with Yellow Hat thinking, being able to get everyone to focus on the positives of an idea rather than have someone shoot it down straight away. Even making the person who shot down the idea come up with at least 2 positives could change the mindset to get constructive feedback before unleashing the negatives. Having the whole thinking process orchestrated and facilitated by the Scrum Master or Iteration Manager, would be interesting, especially since that is how I see it is part of the job to get the team to open their mind and improve their ability to think of better and more interesting solutions and experiments in ways of doing things.

Remember that the six thinking hats is but another tool. One that I plan to keep in my mental toolbox to pull out when the time is right. It is not a strict process to be followed, but something to give guidance. Use it appropriately.

If you haven’t seen this before, have a look at the following video found on the internet and count how many times the white players pass the ball.

https://youtu.be/vJG698U2Mvo

This video and similar ones started making their way across the     internet many years ago. You yourself probably have seen it. If you haven’t, you probably understand the title of this post now.

Our ability to narrow our focus is extraordinary. When concentrating on something, our mind can filter out all background information. Sometimes this is good, sometimes this is bad. I have been known by my wife to not hear our crying son when he was born while in heavy concentration and then get that look. He’s six now, so all is good. This can happen in our work lives. We get so focused on getting the job done, that we lose sight what is happening around us. Is our team happy? Are we actually generating value for our customer? Are we delivering what the customer needs or just following the plan?

There is no point saying that we are intelligent people, and we should know better. I’ve recently come across an experiment which used radiologists as the subjects. Radiologists are those people that look over your X-Rays and MRIs and look for signs of cancer. These people have to be highly intelligent, detail driven and very very focused.

The experiment was simple, they were given a series or X-Rays and MRIs to look for cancer.  They were given an X-Ray that is similar to this one:

Notice anything strange in the X-Ray?

There is a Gorilla in the top right hand portion of the chest x-ray. Yeah, I missed it too when I first saw this, even though the image quality was better.  The thing is that over 83% of the Radiologists that took part in the experiment also missed the gorilla.

The lesson here is that sometimes you need to stand back survey what you are doing and try to see what you are missing because you never know if there are any gorillas hiding in plain sight.

For more information on the Invisible Gorilla experiment see:

http://www.theinvisiblegorilla.com/

Article on NPR.

Some people think that being a Scrum Master is a part time job and that you can also be a developer during a project or the Product Owner can share the Scrum Master role as well. Well, the Scrum guide does not specifically rule this scenario out, but it is not ideal and especially if you are new to Scrum, I don’t recommended it. The simple reason is that the Scrum Masters role is more than just being a facilitator during the Scrum Events.

Being a developer on its own is a full time job. There are problems to solve, requirements to understand., discussions to be made. Adding on top of that the role of Scrum Master where the Scrum Master is there to help support the team, shield the team from shit etc, just adds more stress and complexity to the situation. It makes it harder to know which to concentrate more on. Even being a developer on another project still takes away from the Scrum Master duties. What happens is that one of the roles wins out. Usually but not always it is the Development role as deadlines and pressure increase and the Scrum “stuff” gets ignored.
The same goes for sharing the role as a product owner, project manager or even just being a normal manager. Something goes wrong and you either do both jobs poorly, or one job poorly. Never both jobs well.

The thing is, the role of the Scrum Master is to make sure that the team is continuously improving, To find better ways for the team to communicate and integrate. To clear the way for the team to work and grow. To run interference and remove obstacles and impediments from that objective. They do this by focusing on the team and its needs. They are the advocate of the Scrum Process that keeps the cycle of continuously improving and  when the team deviates and reverts back to their old ways, which they will when new to Agile and Scrum, the Scrum Master’s role is to bring them back. Teams will deviate, its human nature to revert back to something you know especially when you are under pressure, than to push forward into the unknown. Its the Scrum Masters role to push across the chasm to bring a team to be performing. A inexperienced Scrum Master facing two roles will likely do the same – not always, but is likely.

For a Scrum Master that shares the role of the Product Owner, there becomes a bigger problem. The two roles are in conflict. The Product Owner is trying to get the product completed as quickly and cheaply as possible. The Scrum Master this there for the welfare of the team. Which one wins out? Well, with a new Scrum Master/Product Owner new to the Agile principles and with the mindset of just get things done, then the Product Owner role wins out. You then get a Scrum Master who goes into Command and Control mode trying to push the team to get things done faster. Compromises in quality are made, and in the end everyone has a bad Agile experience. Mind you, you do not have to have a Scrum Master in a dual or even triple role for this to happen, but it is more likely to happen. It can happen and does happen regardless, but that is a talk for another day.

I have made this mistake. I’ve been a developer and a Scrum Master at both the same time, and even though I had every intention to be a good Scrum Master, I made mistakes. Development work took priority. Then again, there were times during the same project where I would focus more on the Scrum Master role, and the development side suffered. The end result though was that neither role was done extremely well.

Every situation is different, and it is possible that a Scrum Master can take on dual or triple roles, but I would expect that to happen with a highly mature agile team. Not one who is just starting out. I also realize that there may not be a choice. There wasn’t in my case. All you can do in this situation is do your best and look out for the welfare of those on the team. Not just those of the customer.

You know the drill. Your manager or someone higher up says “We are all one Team”, but something doesn’t quite sit right with you.

You may be all one team, but no one works together. Everyone is working on their own thing. They are working on tasks that are not related to what you are doing. Your task isn’t related to what they are doing. There is no coordination. No discussion, just work. Are you really in a team?

The most likely answer to this question is – No. You are not in a team. Despite what your manager says or his manager or anyone higher up. You are not working in a team.

Businesses like to group people into teams and rightly so. Teams are powerful entities. Teams helped put men on the moon. Managers know this, they are not stupid, but due to decades of misinterpretation, culture and misunderstanding, the real concept of “team” has been lost.

So, what are you if you are not a team? Quite simply put, you are in a work group.

Isn’t a work group a group of people working together? Isn’t a team a group of people working together? Aren’t they the same thing?

Well, not quite. All Teams are Work groups, but not all Work groups are Teams.

Huh?

Well, to put it this way, there are some fundamental differences between work groups and teams. According to Jon Katzenbach and Douglas Smith in their HBR paper “The Discipline of Teams” there are some differences.

Work Group	Team
Strong, clearly focused leader	Shared leadership roles
Individual accountability	Individual and mutual accountability
The group’s purpose is the same as the broader organisational mission	Specific team purpose and the team itself delivers
Individual work-products	Collective work products
Runs efficient meetings	Encourages open-ended discussion and active problem-solving meetings
Measures its effectiveness indirectly by its influence on others (e.g. financial performance of business)	Measures its performance directly by assessing collective work-products
Discusses, decides and delegates	Discusses, decides and does real work together

Let’s go through these one by one:

Strong, Clearly Focused Leader vs Shared Leadership Roles

With a Work group, you basically have your head of the group who is in charge. This is someone who directs those under him or her what to do. They are in this position all the time. Everyone underneath obeys, at least in the extreme case.

In a shared leadership role, everyone collaborates. Sometimes one person directs, sometimes another person. The person most appropriate – i.e. the person with the “expertise” at the time is in charge. Sometimes there is no one with expertise and discussion ensures – see later. Sometimes the “team” as a whole decides.

Either way, everyone has a say.

Individual Accountability vs Individual and Mutual Accountability

With a work group, you are pretty much on your own with the task you are working on. If you stuff up, you are to blame. If you succeed, you get the benefit. Achievements and failures are your own.

With a Team, you are accountable for the work you are currently doing, but the team is there to support you. Failure means that the team as a whole has failed. Not the individual. It is the team’s responsibility to help those in trouble. If there is success, it is the team as a whole that succeeds. Not an individual. Think of a team sport. It is not the individual that won or lost, it is the team. The whole team.

The Purpose, Organisation’s Vs Team’s

With a work group, the groups purpose is the same as the organisational purpose. In other words – there is no purpose other than the default one or the organisation. The group itself just is there to work.

With a Team, the whole point is to accomplish a goal. A goal that the whole team has agreed upon. It is specific to the work the members are currently doing. The best purposes are the ones greater than the team. One that if the members all work together have a hope of achieving as opposed to one for each individual.

Individual Work Products vs Collective Work Products

In work groups, everyone is working on their own. One member is working on project A, another member is working on Project B and so forth. Each is on their own.

In a Team, everyone is working towards the same goal. So, everyone is working on Project A. Everyone is working on Project B. How they accomplish that is decided by the team.

Runs Efficient Meetings vs Encourages Open Ended Discussion and Problem Solving Meetings.

For Work groups, meetings are efficient. This may seem like a good thing, and it can be. But the reason meetings are efficient is that the leader dictates the meeting. Knowledge flows from the leader down. Very rarely does it flow up. Even when it does, the leader still makes the decision. This is not necessarily a bad thing. It can be quite good.

With Teams, Problems are discussed. The team as a whole works out the solution through consensus. Each person has an opportunity to speak and be heard. Knowledge is disseminated from all individuals to all other individuals. This also gives the team as a whole ownership.

I’m reminded of the meeting Waigaya where some meetings – not all, are discussed this way. A Waigaya is a meeting where every member leaves their title at the door. No hierarchy – in fact it is forbidden and frowned upon if someone does use their title. Everyone has equal say. Important points are discussed until mutual solution by all parties has been found. Meetings can be quick – 5 min or less, or can last a long time. For hairy topics, they can go on and off (i.e, an hour here, 5 min there) continuously for years. Yes, I did say years. This may seem like a waste of time, but Honda puts more emphasis on getting to the best solution rather than “a” solution and based on the quality of their cars and motorcycles, I think it works. With an efficient meeting, a decision may be made quickly, but it may not always be the right one.

Measures effectiveness by its Influence on Others vs Measures by Assessing Collective Work-Products

Work groups measure based on outside factors that. For example, the performance of the company as a whole. How can they do it any other way. Individuals are working on their own. On their own little work areas.

With a Team, everyone works together, so measurement is based on the collective work that they have done together.

Discusses, Decides and Delegates vs Discusses, Decides and Does Real Work Together

Work groups, as discussed earlier with meetings, have everything sent down from on high. The members may discuss together, but the leader is the one who makes the decision and then delegates to the members.

With a team, there is no real leader like in the sense of a work group. The team collaborates together and does the work together. There is no one person always coordinating activities and delegating.

As you can see, with Teams, there is more of a mutual relationship. There is more collaboration between members. Everyone is working towards the same goal. Be it complete a product, win a game or solve a problem.

With a Work group, everyone works on their own thing. It requires coordination. Therefore there is someone in charge to coordinate, direct and delegate.

Is the Team Best Always?

No, Teams and Work groups do have their places, but the best place for a team is when performance is required.

Now, you are probably thinking that your group or team is somewhere in the middle. That may be the case.

Marie J. Kane categorises Work groups and Teams into different levels.

Work Group – As we have discussed above.

Pseudo Team – Not focused on collective performance, or trying to achieve it but it is needed. These are the weakest type of group.

Potential Team – There is a performance need. It is trying to improve, but has no purpose or goals.

Real Team – Its members have complementary skills and are working together towards a common goal. They hold themselves accountable. Performance impact is significantly higher than a work group.

High Performance Team – Like a Real Time, but also committed to everyone’s personal growth and success. They have transcended the commitment of the team and can outperform all other real teams. Think Navy Seals. They are the best of the best. Committed to one another.

Now these differences cannot be taken individually. For example, just because members help each other occasionally, it does not mean they are a team. Work group members help each other too.

When Teams Do Not Work

Ok, so you found out that you are not in a team. That is not necessarily bad. Work groups are a working form of group that is better performant than a Pseudo Team. A Pseudo Team is trying to be a team, but only doing it half baked. This actually turns out to be worse than being in a work group. This can happen if the “team” doesn’t even know what it is doing. If a team doesn’t agree at some point, things can stagnate, stall or be paralyzed from working. Getting agreement is a leader’s job and having a weak leader, one not willing to take professional risks in the team direction, can make it possible that the team won’t do a good job.

Then there is the problem where the team is always in agreement all the time. This creates another type of stagnation. One of lack of innovation. Having some conflict in the team – of a technical nature, not a personal one is good for the team. Alternative views are given. These alternative views must be explored and tested, not shot down, otherwise there is a lack of trust between team members.

Then again, sometimes teams that do have conflicts of a personal nature do thrive. Just look at the Monty Python team. They hated each other, but each member knew that the others had their back no matter what – when it counted. If your team is getting to the point where there is no conflict, and there is no innovation, then it might be time to switch things up a bit. Swap members with other teams. Bring in new blood with alternative views – a dissident who will “rock the boat”. Get the teams synapses thinking differently. The dissident also needs your support. They veer from the norm at great personal cost. No one wants to be the outsider, get shut down, get told to shut up. So rather than let them be silenced, let them speak out and listen because without them, your team can degrade to the point of being mediocre, but also make sure the dissident has the teams best interests in mind. You don’t want delinquency for the sake of it.

Another reason that Teams do not work is that they are not necessarily faster than work groups. For the simple nature in teams where discussion between team members is encouraged, teams can actually may be slower than work groups. The trade of though with teams is that they produce better.

Teams may not work when they are large. Large teams have to communicate with one another. The more members, the more communication channels are required, the longer it takes to disseminate information, to discuss, the slower a team gets. Teams that are small. Between 3-9 members are ideal.

Only having a “Real Team” or “High Performance Team” will give you the full benefits of having a team. Just saying that a group of people is a “Team” is not good enough to get the benefits. So, I request that if what you really want is a Work Group where you direct and delegate to members, call it a Work Group and not a Team. You are only confusing matters further and perpetuating the confusion with the term.

One more thing

Just to quote the late great Steve Jobs, there is one document that I have left to last on purpose as Teams are not specific to Agile. That document describes how to a team should work and it describes it very well. That document is the Scrum Guide. It mentions that Teams should be Self Organizing. Team members should be cross functional. In other words have all the skills to complete the goal.

Teams are altruistic in intentions. There is no hierarchical structure. Every member at least for the Development team has the title of “Developer”. There are no sub teams.

The Leader – the Scrum Master is there not to direct and delegate the team, but to support the team. Play interference and remove impediments from the team that prevents them from succeeding. No one but the team itself directs the team.

Accountability belongs to the team as a whole, not to individuals.

Jeff Sutherland and Ken Schwaber knew what they were talking about when they wrote the teams section in the Scrum Guide.

References

The Discipline Of Teams

Jon R. Katzenbach and Douglas K. Smith
Harvard Business Review
https://hbr.org/2005/07/the-discipline-of-teams

Organisational Work Groups and Work Teams – Approaches ad Differences

EcoForum – Volume 4, Issue 1 (6), 2015
http://www.ecoforumjournal.ro/index.php/eco/article/view/113/90

Turn Your Group Into a True Team

Harvard Business Review
https://hbr.org/2011/06/turn-your-group-into-a-true-te.html

How To Distinguish the Important Differences Between Teams and Work Groups

Executive Evolution
http://www.executiveevolution.com/docs/Work_Groups.pdf

WAIGAYA: HONDA’S SECRET TO SUSTAINED SUCCESS

http://quarterly.insigniam.com/wp-content/uploads/2014/11/IQ-Waigaya-Hondas-Secret-to-Sustained-Success.pdf

Why Teams Don’t Work

Harvard Business Review
https://hbr.org/2009/05/why-teams-dont-work

The Scrum Guide

http://scrumguides.org

I’ve been attending for a month or so a Lean Coffee group in my home town recently and I liked the format so much that I thought I would try it with my team.

We haven’t had a team meeting for quite a while, so I thought it was about time that we had one and I decided to use this format. I should mention that I am not the team lead, nor am I senior in the team. It was just something I thought we should do. My manager agreed to give it a go, so we did.

The Premise

The idea of the Lean Coffee is to let everyone have their say if they want to, the team themselves makes up the agenda. It is not set by anyone in particular.

So, how do we do it?

Tools needed

• A bunch of Post-It notes.
• Pens
• A timer (Usually a phone)
• That’s it!

Setup and Run

I create 4 columns, To-Do, Doing, Done and Actions using the Post-It notes. Much like a Kanban board.

Everyone gets to write on a post-it note any topic that they want to talk about. One topic per post-it. I didn’t limit the topics to work, but naturally it goes that way.  The topics are then placed under the To-Do column. At the moment, its first come first served, but we may add prioritisation if it becomes an issue in the future. I’ll go through that at the end. If for example, the manager has something to let the team know about, they raise it as a topic. If someone wants to know what everyone else is doing, they raise it as a topic. If someone wants to talk about the latest Miley Cyrus album, they raise it as a topic. No one has done that yet by the way.

We start at the first topic, We move the topic in the “Doing” column and we set the timer to 5 minutes, the person who raised it does a quick intro on the topic, then as a team we discuss. Once the time runs out, then everyone votes to determine if they want to continue, or drop the topic. We do this with “Thumbs up” to continue, “Thumbs sideways” if you don’t care and “Thumbs down” if you want to move on. Its very Democratic. If the conversation looses steam before the timer goes off, then we move on anyway. Once complete, the topic then is moved to the done column. If there are any actions that need to be taken, they are written to a new post-it note and added to the “Actions” column. Actions may be something that needs to be followed up, a little test or a piece of work that needs to be done. Once the topic is finished, we repeat the process for the next topic.

As the discussion progresses, ideas for new topics can come up. When this happens, you just write them down on a post-it note and add it to the end of the list. Sometimes they are tacked on to a topic that is already listed – as an addendum.

The process continues until the time-box runs out or there are no more topics to discuss. Currently the meeting is scheduled for an hour. We have very rarely gone over an hour and if we do, its only been for a few minutes.

I have deviated from the standard Lean Coffee rules slightly and borrowed a few Waigaya, a practice done at Honda.

The rules are:

• Everyone is equal during Lean Coffee. There are no titles.
• There is no blame.
• Ideas are debated until they are proven valid or rejected.

Its very simple, it gives everyone the opportunity to have their say and they have their 5 minutes of fame.

So far its working, but it is early days. Currently we are doing this weekly which personally I think is too frequently, fortnightly I think would be better, but it is what the team decided.

My challenge at the moment is to try to get the team to own the process. What I don’t want happening is that if I’m on leave or held up due to another meeting, that the meeting doesn’t happen or the team sits around waiting.

Prioritisation

I mentioned previously that you can prioritise cards. The way that is done is that everyone gets 3 dots that they can place next to a topic they wish to discuss. They can place them all on one topic, or distribute them to 3 topics. However they want. The topic with the most dots is first, the one with the next highest is second and so forth. Very simple. If you want, you can vary the number of dots based on how many team members you have, or time. For example decrease it to 2 dots or 1 dot. Or even increase it to 4, although that may get a little chaotic, I suggest leaving it at 3 dots or less.

In Closing

The Lean Coffee method seems to be a good way to manage general discussion meetings. I wouldn’t recommend it for a meeting on a specific topic, but it is a democratic way to let everyone have a say. Get their point across and most importantly, be listened to.

To learn more about lean coffee meetings, see http://leancoffee.org/ and I suggest looking one up in your city and trying it out. I find that at my local one, I learn quite a lot and get different perspectives from other people who do Agile in the community.

There is a feeling that a single dissident in a team should be overruled if the rest team disagrees with them.
The problem with that is, what if they are right?
If they are there just making trouble, then you have bigger problems.
If they are not, that person has shown courage to go against the grain and that should be respected. The reason for why they are going against the grain should be explored. The exploration should be in a manner that is scientific to either rule in or out the feasibility. What has made this person passionate enough that they ignore peer pressure? What do they know that the rest of the team doesn’t know? These are questions that should be answered.

One reason not to shut them down is that if you shut down the person and overrule then, then the next time they have an idea, they will be more cautious in sharing that idea. It may take time before they bring up ideas again. Let’s say a week for the first time. If the next time they are shut down again, then they may wait a month before they try again. Shut down again, it could be 6 months to a year. Shut down once more and it could be 2 years or worse, they will say the proverbial “FU all” and either leave or become the unruly dissident you were afraid of in the first place. That is if they do not conform in the first place. In which case, you have lost your independent thinker anyway.

On the other hand, had the suggestion be explored, it may have wasted a little time, it may have wasted a lot of time, but you still have your engaged employee, and possibly an idea that may have significant positive impact.

One of the reasons the ideas are not explored is that there are time constraints and there is not time to “Play”, no problem I say,  let the person do a small experiment. Let the person know they have a small period of time to show results. From that time evaluate and either make a decision or determine if more evaluation is needed.

Even if an immediate decision is needed, let the person explore the option after the fact. It becomes a learning experience for the next time.

Dissidents should be praised, not only for their courage but because they show that their thinking is different to the group. The debate itself could elevate ideas within the group, increase thinking outside the square and may lead to better solutions.

In 1957, the commissioning of the Sydney Opera House began. The project was to be complete on Australia Day, January 26th 1963 at a cost of £3.5 million ($7 million AUD, Australia used pounds up until 1966) . Construction started on the 2nd March 1959.
Well, 1963 came and went, the Sydney Opera house was not complete. It would not be completed until 1973. It was 1357% over budget, $102 million and 10 years late.

Why is it that no matter how much we try to plan, we always run late? Does this mean that we haven’t planned enough? Does this mean that we haven’t worked out every contingency? Well, actually it does, but it is not our fault. It is a psychological phenomenon called the “Planning Fallacy”. This was was the subject of a recent podcast on Freakonomics Radio.  (Thanks to @stefanw and his mail outs for Age Of Product for letting me know about the podcast.)

I was so intrigued with the subject because recently I gave an estimate of 3 days for a piece of work, 2 weeks later, I’m still working on it. So I decided to do a bit more research into the topic and read a few papers by Roger Buehler who appeared on the podcast and a few other sources of information.

The “Planning Fallacy” was first proposed by Daniel Kahneman and Amos Tversky in 1979 in their paper “Intuitive prediction: biases and corrective procedures“. It doesn’t matter how intelligent you are, it doesn’t matter if you are aware of the Planning Fallacy, If you are going to predict the cost, time of a piece of work that you yourself are going to undertake, you will most likely underestimate the amount of effort required.

Why is this? According to research, the simple reason is that we are optimistic. Even if we break down work, try to determine how long each piece is going to take, how much it is going to cost, we usually underestimate because we only think of the best case scenarios. This optimistic view of things is called “Optimistic Bias“. We basically think that things will go better than they really will.
Even if we are told otherwise, we will dismiss the negative views and go for the optimistic views. “That is not how it will occur, we will finish in 6 weeks, not 6 months like other projects!” and yet 6 months later, the project is near completion.

Even when we see that our plans are falling apart, we start to blame external factors.  “The server crashed!”, “We didn’t see ‘event’ coming!”. When it comes to planning the next project or task, we gloss over the past negative events and dismiss them as one offs. They won’t affect us this time.

This type of thinking where we only look at what is in front of us. For example, when we break down the work into components, then make up a scenario on how we will implement is called the “Inside View” according to Roger Buchler. We fail to consider alternative views. We focus on the end and ignore other events that may occur. We see the future and the past through rose coloured glasses.

The other view is the “Outside View”. This is where we look at external factors. “How have similar projects like this go in the past?” The best way to think this way is as an outsider, someone not involved with the task, someone who has no emotional bearing on the task. An outsider for the simple reason that they do not have the emotional attachment and thus more likely to take in external factors such as past performance of similar tasks and experience of others therefore giving a better estimate than a person on the inside.

So how can we improve our planning accuracy?

Adding incentives to improve predictability actually improves the prediction more than the result. We tend to become more optimistic. So, when you add rewards for completing on time, people tend to think they will finish a lot sooner than they really will, or would have originally predicted if there was no incentive in the first place. Actually, incentives can backfire where people intentionally give incorrect estimates in the first place. For example when bidding on a piece of work. The idea is that bidding under time and cost will win the job, then the contractor will charge through the nose for any inevitable changes that occur. This seems to be standard practice for any tender process. Its built in to the system, anyone who gives a realistic estimate is outbid by those who do not. So, in order to get the work, you must play the game.

The only real way to improve accuracy is to actually base your predictions on past performance. This means that you need to record the data of the projects and tasks that you do. Then work out an algorithm to predict the outcome of future similar tasks.

The more tasks/projects you do, the more you tweak your algorithm and add data, the better your estimates get. This is why when you buy something on eBay, they ask when you receive the order through the mail. This data goes back into the eBay algorithm to predict when a future order will be received.
It is not a guarantee, but the results become more accurate the more data that is added.

This is one of the reasons why in Agile methods such as T-Shirt sizing or story points comes into play. This is a method to group work into categories based on the amount of effort they will take. Extra Small, Small, Medium, Large, Extra Large etc. Then by recording the time that each task of a similar “size” takes, you gain a reference point as to how future tasks of a similar “size” will take. The more iterations you do, the better you get at estimating the relative size of each piece of work. As you do the work, the time spent on each size is recorded and feeds back into the previous iterations recordings giving you a better idea on how long future work will take based on your current estimate on the effort.  You still do not get an accurate measurement, but you end up with a better measurement than just by guessing time at the beginning, unless of course you are really good at estimating time in the first place.

How do you do your planning? Do you have a mechanism in place to review your estimates to see if they were accurate? Do you plan in a different way? Please let me know in the comments.

Have you ever been to the Supermarket when it is busy, you only have a litre of milk to buy and you try to find out which checkout to go to to get through sooner?

There is a choice of three. So you guess. Line up, then find out you chose the wrong one. The one you didn’t pick is flowing quicker and you are stuck where you are.

Where am I going with this? Well, each person behind the checkout has the job of processing groceries that go through the checkout. This is a basic oversimplification, and I apologise in advance to anyone who is or has works behind a checkout.

Each customer has a load of groceries that need to be processed. Some people shop for a week (Or longer) some only shop for a day or 2, some only get what they need then and there.

Now, our customers are autonomous, but let’s say that our shoppers are zombies and they need help choosing which lane to go through. We need help. Someone to direct and manage/assign people (work) to a certain lane (people).

Let’s call our person a “manager”.

Our manager is busily trying to juggle our zombies to different lanes to manage the workload. Our zombies with only a tub of ice cream would want to go through quicker, whereas our zombie with two trolleys is taking forever to get through the checkout. So, our “manager” reorganizes. Halts work midway through re-arranges everything and thus has to be hands on all the time. This will end in chaos. With people, you are more likely to end up with chaos as people will get irate. It seems crazy, but that is how work is usually organized in a traditional manner. We get large bodies of work. It is assigned to people. If everyone is busy and a priority piece of work comes along, someone is disrupted and the work is re-arranged. The priority is done and then the bulk load starts up again.

The system here is a “push” system. You push customers to a particular lane and they are serviced by that lane.

Now, if you look at the queues for some department stores. They are arranged differently. There is a single queue, and whichever register is free, services the customer.

Customers are slightly different with Department stores. They do not have anywhere near as many items is customers in Supermarkets have. They only have a few generally. They may have trolleys, but that is for big items. Not for a large amount of items – usually.

The system here is a “pull” system. As each register is free, a customer (piece of work) is pulled off the queue and serviced. You will notice that the queues flow a lot faster than they do in a supermarket too.

Now, Supermarkets have caught onto this and have tried a couple of methods over the years to fix the problem of improving the flow of customers through their registers. One methods was to use an express checkout. Customers who have only a few items (a small amount of work) go through the express lane. Whereas everyone else goes through the slow lane.

This can work, but there are times when you have the express lane queues snake a long way too again during busy times.

Another way Supermarkets have tried to alleviate the problem is through self checkout. Here, our checkout operator is replaced by a machine, but the queue structure is the same as the department store model.

So where is this analogy going?

Well, with the push method of working, large bodies of work – some pieces not needed for weeks or months are pushed onto one person. That person works on that piece of work and delivers it at the end. If a more higher priority piece of work comes along, things are rearranged, this causes disruption and the person then works on the higher priority piece of work. In some places, this is taken as being “Agile” because the higher priority piece of work was able to be worked on. Nevermind about the disruption.

A better way to work is to take the department store model. Smaller pieces of work – only what you need now, not what you need weeks or months later, is worked on. This requires breaking down the contents of those large trolleys into only what you need for the next day or two. If something of a higher priority is required, let’s say someone with a tub of ice cream that will melt any second because the aircon is out at the supermarket on a 45oC day, there is no rearranging of anything. That piece of work only has to wait a short time before it is serviced.

Break down your work into small chunks. Rearrange those chunks into priority order based on value, due date or whatever. Then have your people “pull” those pieces of work off the queue to work on them. You will get things done quicker. There is no need to manage the work, it will manage itself with only a few rules.

1. If you are working on something, complete it ASAP. Not later than possible (ie don’t cause intentional delays), not sooner than possible (don’t cut corners or do hacks), but as soon as reasonably possible.
2. If you are free, pick up the next task on the queue. No cherry picking.
3. Once you complete the task, go to step 1.

If there is a piece of work that a person cannot do because of a lack of skill, think of it as an opportunity to have that person learn that skill. They may require help from someone who has that skill, they may need significant help, but they will gain the experience and then you have 2 people with that skill.

If a person is on leave, it doesn’t matter, the work rearranges itself.

There is one overhead though, everyone needs to know everything about everything. It needs a level of knowledge dissemination, communication and collaboration, but that is what the Daily Standups are for. To help the team coordinate the work. Share knowledge and in the process eliminate handovers from one person to the whole team as the whole team knows everything.

Do you work this way? Does it work? Does it disintegrate into chaos? Let me know in the comments.