RSS

How To Create Psychological Safety

Our feeling of safety is largely under our control – it is a point of view.  That is good, because that means we have a chance to improve it.

By practicing being vulnerable – putting ourselves in a position where we can potentially be hurt – we can increase our feeling of safety.  Some examples are:

  • Say “no” when it is uncomfortable doing so.
  • Share a mistake you made with a colleague.
  • Ask for help when you don’t fully understand something.

By repeatedly taking these small risks, our feeling of safety increases.  If the reaction from the other person is good, then you have increased your feeling of safety.  And even when the reaction is negative, if you can accept it, then your safety will increase even more.

To prepare yourself for a negative reaction you might try:

  • Being prepared for the worst that can happen;  if you can accept the worst case scenario, then you will be able to benefit regardless of the other person’s reaction.
  • Realize that you are at choice – you have chosen to have this difficult conversation to incrementally build your safety muscle.

Finally, if being vulnerable is too large a step, then consider meeting with people in your team and sharing stories of when you were in a difficult situation.  You will realize that you are not alone, and we all find ourselves feeling unsafe sometimes.  And that feeling of “it’s not just me” will prepare you for the initial vulnerability exercise.

 
1 Comment

Posted by on January 22, 2017 in Culture, Individuals, Interactions

 

Psychological Safety

In this video I discuss the importance of psychological safety to effective teamwork.  Psychological safety is the degree which I feel comfortable being fully myself in a situation.

This type of safety is essential for software development and other knowledge-based teams.  Safety allows a team to benefit from the expertise of all of its members

  • Is it safe to make a mistake?
  • Is it safe to say “I don’t know” and ask for help?
  • Is it safe to learn from failure?

Learning is crucial to the success of these teams.  Without safety, teams cannot learn effectively.  High performance teams are masters of learning quickly and effectively from mistakes and failure which require a high degree of safety.

 
2 Comments

Posted by on January 21, 2017 in Uncategorized

 

Interviews for a High Performance Team – Part 1

We all want the best people for our team.  There are many effective ways to interview, and I’m not here to tell you the best way, but to add some perspective in and share some of my experience.

What I’ve been doing for the past few years is incorporating questions about human dynamics as well as technical and leadership prowess.  What do I mean?  Specifically, I ask about:

  • Safety – how does this person work in a safe/unsafe environment, as well as does this person create safety for others?
  • Respect – does this person respect others on their team?
  • Ownership – does this person take responsibility for his decisions and for his teams decisions or does he act from obligation/blame/justification?
  • Agreement management – What is this person’s ability to make/keep/renegotiate agreements?

I rarely ever ask direct questions.  And in this blog I’ll share some examples of how I check for safety and what clues I look for.

So, safety – psychological safety – is very important for a team to share (especially sharing mistakes early) and learn together.  To get clues how a person reacts to safety and/or creates it I usually ask them to tell me about their past projects (even school projects if this is a fresh grad).  And then I ask them to tell me about a few instances where something went wrong and how they dealt with it.  And then I listen carefully.  Here are a few scenarios:

  • If they have a hard time coming up with examples, then I have to question their ability to feel safe in stressful situations.  This is a big red flag.  When things go wrong – and they always do – we need to be able to face the mistakes early and deal with them as a team.
  • If they tell me how something went wrong but it wasn’t their fault, then a little warning light comes on.  They don’t feel safe around mistakes and the way they protect themselves is to blame others.  That won’t make for a good team dynamic.
  • If they tell me the details of the problem and are comfortable talking about their part in helping cause the problem and solve the problem, then this person is a good candidate.
  • If they tell me the details of a problem and their part of it AND how they went to the team for help then I really start to get excited.  Not only do they feel safe making mistakes and fixing them, they also feel safe going to others for help.

 

Well, that’s it for exploring safety in an interview (at least for now).

 
Leave a comment

Posted by on February 15, 2016 in Uncategorized

 

Asstimations!

Don’t you just love it when managers pull estimates out of the air and expect software development teams to meet those estimates?

Then they get upset that the team is moving too slow.  Too slow to meet the estimates that they pulled out of their ass – ASSTIMATES.

Asstimates are hazardous.  Asstimates, cause us vs. them.  Asstimates create fear.  

Please.  Please.  PLEASE!!!!  Stop creating ASSTIMATES and expecting your teams to meet them.

(These remarks are completely fictional.  Any resemblance to any of my friends/colleagues/clients is completely coincidental.) 

 
Leave a comment

Posted by on August 13, 2014 in Uncategorized

 

The Coolest Thing EVER! (for Lean geeks)

Lean thinking and theory of constraints have gone hand-in-hand in the agile world for as long as we’ve been stealing/borrowing ideas from the manufacturing world.  If you aren’t very familiar with how these things fit together with agile practices a good starting point is this InfoQ article (it is a little dated but still valid).

So Lean tells us we should reduce waste in our system and focus on throughput and cycle time, but doesn’t really do a good job telling us which waste to focus on first.  And that is a big-ass problem – because if we focus on a part of the system upstream of the bottleneck we can adversely affect the performance of the system by increasing WIP consequently increasing cycle-time and decreasing throughput.  Ouch!

Theory of Constraints comes to the rescue by telling you which waste to focus on first – the bottleneck!  The slowest part of your system is where you should start because, by definition, any improvement you make to the bottleneck directly impacts your cycle time and throughput.

So for years that’s where I left it when describing it to my clients and students.  The question of “How do you find the bottleneck?” never had a straight-forward answer.  That’s where you bring in the consultants or spend significant time and effort understanding and measuring your system so that you can find that all-important bottleneck.  An activity that has always seemed nebulous.

Okay – here comes the coolest part ever!  There is an insanely simple way to find the bottleneck.  Every. Single. Time.  (If I stop here it would make a great cliff-hanger wouldn’t it?)

  1. Draw/create your value stream map.  Pay special attention to identifying the queues in your system.
  2. Then, starting from the right-hand-side, traverse the VSM and find the first queue/inventory.
  3. The process to the right of that first queue from the end is your bottleneck.

Ta Da!!!!  That’s it.  Insanely simple way to find the bottleneck.  I’m sure this must have been written up somewhere before, but I’ve managed to miss this little tidbit throughout the years (and so have many of those I’ve been checking this with over the past few months).

“It can’t be THAT simple!”, I hear you exclaiming.  But think about it, if this is the very first queue from the end of the VSM, then any improvement flows directly to the user with no blockages because there are now queues downstream.

Feel free to poke holes in my theory and disprove this statement and I’ll be grateful because I will learn something along with you.  But if you can’t, isn’t this really cool?

 
2 Comments

Posted by on May 17, 2014 in Lean, Organizations

 

Tags: , ,

I’m Back – Here’s What’s on My Mind

Blogging has always been a challenge for me.  Sitting down over coffee and having a conversation…. well that’s really natural and I do that effortlessly.  I’m not there yet with writing.  So, here we go again.

I write this blog sitting in the KLM lounge at Schiphol airport in Amsterdam on my way to Beijing (yeah, being a consultant definitely has its up-sides).  There are a few topics I’ve stored up in the months since I’ve written my last blog, and I’ll be writing about them soon:

  • Fixed price contracts and agile methods,
  • Creating a culture of safety,
  • The importance of integrity,
  • A 9-week bootcamp program for creating high performance teams,
  • Programming for old farts,
  • Whatever I learn at the XP conference in a couple of weeks,
  • The awesome-est way to locate the bottleneck in your system,
  • Playing world of warcraft with my 6-year old daughter,
  • The state of Agile in Egypt,
  • Lean start-ups,
  • The Culture Engine – the book and it’s progress,

Now I’ll leave you with something really cool I recently read that I hope you find as useful as I have.  But first a little background: I cringe whenever I hear the word “measurements”.  I have flashes of huge excel spreadsheets, entering the number of minutes I’ve been working on a particular task, and a stochastics final back in college.  So, it is with great hesitance that I picked up a book on measurements on a recommendation from my good friend Ruud.

So far it is an interesting read.  The author starts out giving some stories of some pretty remarkable measurements that were very light-weight but clever (for example Eratosthenes approximating the circumference of the earth from shadows and the distance between my hometown (Alexandria) and Aswan).  And here is the gold nugget:

If you take a sample of 5 people in your organization and ask them the same question, then the median of your entire population is within the interval represented by the largest and smallest numbers in your sample with 93% confidence.

Here is what it means practically for me:

If I have a question, such as, “how much time do we spend on defects every week”, I can ask 5 developers at random in my organization and they answer 5 hours, 10 hours, 30 hours, 4 hours, 8 hours then we know a huge amount.  We know the median lies between 4hrs and 30hrs with 93% confidence.  I don’t know about you – but that is amazing!  And that little rule will allow me to be able to have some really great discussions with my teams and clients.

– Amr

 
1 Comment

Posted by on May 10, 2014 in Uncategorized

 

Throughput, Value, and Inverting the Tasking Question

Two people on a plane.  One looks over to the other, points, and laughs!  “Ha! Ha!  Your wing is on fire!”

The plane goes down and they both die.  Bummer.  This has always been how I introduce the importance of team results instead of individual results as a management technique.  And, when this works well, teams excel instead of just trudging along.

An individual should not “Succeed” if their team fails.

Last week I was introduced to yet another perspective on this problem by Tim Ottinger.  Instead of asking how many tasks can a person do, we invert the question and ask “how many minds can work together to solve this problem?”  The idea behind this wasn’t obvious to me, so let me explain briefly.

How many minds does this task need?

In general we think of a task as either done or not done.  And, in the lean world, we think of throughput as volume delivered to the customer.  There is a more effective way of thinking of throughput – as value delivered to the customer.  And two items delivered to the customer may have more value.  In fact, especially in knowledge work, the value delivered by the same feature in two different applications may be completely different.

Throughput should not be defined as volume delivered to the customer.

Many tasks can be done much better – that is deliver much more value to the customer – by having many minds work to solve the problem.  That’s why pair programming works.  That’s also why self organizing teams, when they get it right, can create much more value than the same number of individuals working in a different fashion.

Tasks can deliver different value to the customer depending on how well we solved the task.

In summary, the value delivered by a task completed is not static.  That can be affected by the number of people who work on solving the task together.  So, before you do your next task, consider asking “how many minds does this task need?”

 
Leave a comment

Posted by on February 18, 2014 in Uncategorized