RSS

Category Archives: Uncategorized

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.) 

 
1 Comment

Posted by on August 13, 2014 in Uncategorized

 

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

 

Safety – Easier Said Than Done

Safety.  Number two on Maslow’s Hierarchy of Needs – right after eating and breathing.

Safety.  The primary focus of Alcoa’s famous rise from the ashes.

Safety.  The gateway to excellence in software development.

(Lack of) Safety.  The first of the four invisible impediments to high performance teams.

Safety.  Something that is completely internal.  Some people feel safe in a burning building.  Others are afraid to walk across a busy street.  In the last year, our focus at Industrial Logic has been safety as a gateway to excellence.  And the more we explore, the more it resonates.  The more it is surprisingly true.

For me, I’ve had a really long weekend.  I made a mistake at work that upset one of my colleagues and may have negatively affected our standing with a client.  Bummer.  It happens.  But it was the weekend.  And I’m 10 timezones away so it has taken three days for us to get together and talk about the problem.

However, since Friday morning I’ve been stressed.  I haven’t been able to focus.  And I have used a huge amount of energy to continue doing work that needs to be done for an upcoming deadline.  If I weren’t feeling so unsafe, I’d have been able to focus and would have been done by now.

And the interesting thing is, I know rationally there is nothing to worry about and even if there was there is very little I can do at this moment.  But my rational mind doesn’t mean very much to my emotional fear.

So, the question is, how do you feel safe?  How do you readily get from feeling emotionally unsafe to relative safety?  For me, it has always been (relatively) straight-forward: I man-up and face my fear.  If I’ve upset someone I pick up the phone and have a conversation.  If I’ve broken something, I do my best to fix it.  And so on and so forth.

But what works for one person, doesn’t always work for another.  And what about when you find yourself in my position this weekend when something isn’t immediately fixable or that person isn’t available for a conversation?

That’s what I’ll be focusing on over the next two weeks.  I’ll be reading up.  Having conversations with people who know this much better than I do.  And learning to more effectively create safety for myself and share what I learn with others.

Because Safety really is important to our work together.  And without it things break down and we become so much less effective than we can be.

 
Leave a comment

Posted by on January 19, 2014 in Uncategorized

 

Tags: , , ,

The Four Invisible Impediments

There are 4 common blockers to achieving high performance:

  • Lack of Safety,
  • Lack of Respect,
  • Lack of Ownership,
  • Lack of Intention

Each of these key ideas can be stated simply:

SAFETY

The extent to which I feel I can be myself in my work; say what I need to say; do what I need to do; and be accepted for who I am.

RESPECT

The extent to which I regard others as human beings and not as “types” or “things” that are keeping me from getting what I want.

OWNERSHIP

The extent to which I acknowledge that I am responsible for my results and my experience; I do not find fault, nor lay blame; nor do I act solely out of obligation.

INTENTION

The extent to which I am clear—with myself and others—about the results I want to create and how I want to create them.

Notice that each of these ideas is 100% internal.  The extent to which I am clear.  The extent to which I regard others.  And so on.  One of our biggest mistakes is externalizing our safety, respect, ownership, and intention.  Once we internalize them and consciously choose them, we are in the a much more effective position as an individual, and as a member of a team.

You can read more at http://cultureengine.net.

 
4 Comments

Posted by on January 15, 2014 in Uncategorized

 

Follow the Energy

At Industrial Logic we have a diverse team that is distributed globally. We are all very experienced software and agile practitioners that have been around the block several times with helping teams and organizations vastly improve the way they work together to build software.

Last week we were away for our annual in-person meetup/retreat and it was phenomenal. I’m writing this on the last leg of a 30 hour trip back home to Cairo and I’ve never been so energized. The next few blog posts will contain many things I’ve learned and relearned.

What I’d like to discuss today is something truly marvelous. It is the idea of “following the energy” instead of following a strict agenda and timeline. If it sounds a little un-professional and un-businesslike to you, it did to many of us. But boy did it make a difference in our results.

Stated simply “follow the energy” means follow your own energy and that of the group. When you are tired, rest. When you’re not feeling it on one topic or task, go do another. When you need to nap, by all means, go ahead and nap.

What this enabled us to do was to bring our WHOLE SELVES to everything we worked on. That means we were fresher, more engaged, and much better able to work as a team. The results were amazing – we completed tasks as a team and took them to completion regularly. And the quality of those tasks were much higher than we would have gotten if we were working on it because we had assigned something to be done.

Now don’t get me wrong, this wasn’t a free-for-all. We had well-defined tasks and we had them prioritized. We didn’t go work on task #10 before we were done with task #1. But what we DID do is agree as a group what we would be working on. And we had a few things that we were doing in parallel. So that if your energy ebbed on one task, you were able to move to another. And if you needed some time to decompress and do something else, it was absolutely safe and ENCOURAGED to do so until you had your energy back and were ready and eager to dive back in.

So, “follow the energy” is one of our new team agreements and we will continue to work that way as a team. I expect we’ll have better results and enjoy doing so much more than we have in the past.

 
Leave a comment

Posted by on January 12, 2014 in Uncategorized

 

Use the Product to Build the Team

Most people use the software development team to build the software product.  And that makes a lot of sense.  Begin with the end in mind – focus on the product and make sure that is clear to the team – and they will build it well.  Unfortunately, and unexpectedly, this is painful and ineffective.  I have never seen a team reach high performance by doing that.

Instead, all of the teams that I have witnessed achieve high performance have done something differently.  They focused on the individuals and their interactions; the focused on the team and how they work.  The fact that they had a shared goal – the product – was the mechanism used to Build the Team.  When the team was built – the software was built as a by-product of the focus on the team.

So focus on building the team.  Use the product as a way to build a high performance team.  Do THAT and you will get a great product.  Every.  Single.  Time.

– Thanks Tim and Ashley!

 
Leave a comment

Posted by on January 10, 2014 in Uncategorized

 

Tags:

How Do We Manage Changing Priorities?

There are generally two parts to changing priorities: 1) how they fit within the mission of the team and the project – that is are they really changes that need to be made, and 2) the ability for the team(s) to respond to this vision.

For the first part to be even possible, there must be a clear direction and alignment of the team around the purpose and goals for their project.  That is called the mission in chartering as used by Industrial Logic.  Or, as the shared task, as defined by Christopher Avery.  No matter what you call it, everyone needs to be aware of where we are going together.  With that knowledge, they can review their current backlog of work, change priorities appropriately, and say NO to things that no longer fit in this shared understanding.

The second part, is the technical ability for the team to choose very thin vertical slices of functionality and take those to completion.  Saying vertical slices is easy.  To be able to do them effectively pulls in almost every major skill from the agile toolbox:  writing effective user stories, test driven development, behaviour driven development, working effectively with legacy code, and perhaps continuous deployment.

There are several areas that will affect the ability to manage changing priorities effectively:

1)     Degree of alignment within the entire team.  This serves as the backdrop for all the work we do in the future.

2)     An effective product management group that is engaged with the team.  Product owners must be skilled at creating effective user stories and working well with the rest of the team.

3)    Visibility of current state is important to be able to make decisions about when to change priorities.  This is as easy as saying we will post our work regularly on physical information radiators.  The difficulty is in building the habit that comes through repetition and creating a safe culture that encourages sharing even bad news early.  Tools may or may not be considered at this point depending on the needs of the teams on the ground.

4)    Reduce work in progress and prefer finishing to starting.  This is difficult and also needs a habit.

If you have these two major areas, then you will be able to recognize and respond to change effectively.

 
1 Comment

Posted by on January 9, 2014 in Uncategorized

 

Tags: ,