RSS

Category Archives: Individuals

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

 

Those Pesky Invisible Agreements

The Story

One of the things I do with my clients early on is work on team agreements; basically an explicit “how we work together” document.  And, not infrequently, I get people rolling their eyes and telling me that this is too heavy and mechanical.  “Are we trying to solve a non-existent problem?” some would ask.  And every once in a while I let up, and think that “we have it together, maybe I’m just overdoing it”, and I am always quickly reminded of why.

This happened to me again this week.  Let me tell you the story of how I caught myself and my team suffering from un-agreed-to agreements, and how we’re working on the solution.

I lead one of two teams – my team is primarily focused on consulting and working with clients, and the other team is primarily focused on making our eLearning application great.  We frequently work together and cross team boundaries and have a great working relationship – most of the time.

On my team we have different skill-sets and passions.  One of the people on my team is very passionate about coding and learning new languages.  We also have an internal tool that a few of us are great at, and many of us (like me) are not.  So, based on our experiences, and our passions, and the fact that we’ll be working with this tool very heavily over the next few months, when this guy said “I’ve got an idea of how to make this better” we (his lead and I) jumped on the opportunity and asked him to make it happen.

In a day he had a working prototype.  In just over three days he had something that is ready for daily use and already significantly better than the current solution.  So you would think this is a raging success – right?  Of course not, if it were, I wouldn’t be writing this blog post.

Our team member was so proud of his work that he shared it with the rest of the teams immediately so they could use his tool and give him feedback on how to make it better.  Unfortunately this wasn’t well-received.  Some members of another team became frustrated.  They felt that we have more important things to work on than something like this and they thought it was not time well spent.  They felt that our team should have involved them early on and that would have led to us putting our time to help them with what they need done – which is much more important and urgent than our project.

Getting that type of feedback hurts – especially when you are really happy with what you’ve produced.  You feel unvalued, and you can easily become angry.  And as one person described it, “this is beginning to look like politics in large organizations”.

As for me, I also got sucked in and felt that my team member was attacked and the conversation should have been with me.  I authorized this and if there is a problem then it should be solved with leaders.  (It does sound like big-office politics, doesn’t it?)  I fired off an email voicing these concerns and my anger.

I should have known better.  After sleeping on it, I saw our situation as a microcosm of what happens at work everyday.  I realized that we were behaving as if our expectations were agreements.  But they weren’t.  I was behaving like the other team had no right to talk to us about what we should and should not do – but there was no such agreement.  And, the behavior of the other team seems to indicate that they had an expectation of us checking with them before we wrote any code, and, of course, there is no such agreement.

Blame and Ownership

I had easily fallen into a trap that I’ve been in before.  I was getting upset because people were not meeting my expectations – invisible agreements.  Which led me to see them as obstacles, instead of people doing their best to make our organization successful – just as I am.  And I began to see things as “us” vs. “them” which is the bane of all large organizations.  I was blaming my peers.

But, from Christopher Avery, I learned how useless blame is – and how it can easily lead into a vicious cycle.  So, I asked myself instead, “how did I contribute to this problem?”  That led to a completely different way of seeing the problem and my colleagues.

Well, it turns out we had a bunch of assumptions about how things should be done that we never really brought to light.  Our actions lead me to believe that these might be those invisible, un-agreed-to, agreements:

  • Team A should ask Team B if they have spare time on their hands before they do something on their own,
  • Team B’s leadership should only talk to Team A’s leadership,
  • Team A doesn’t have enough visibility to know what is the most important thing to work on, they need to ask Team B,
  • Team B has no right to tell Team A what to do.

But the fact is we didn’t agree to any of these.  And this upset was not an unusual thing.  Upsets are to be expected.  How we handle upsets separates the highly effective from mediocre teams.

This wasn’t a totally bad thing, it was actually pretty good.  It told us we are transparent enough to know what other teams are doing.  It told us that we felt safe enough to disagree openly.  And, because we caught ourselves and are looking at our expectations of how we work together, it is a great example of leveraging upsets for improvement (thanks Christopher Avery!).

Personal Agility

If you’ve read any of my blog posts, you’ll know I’m all about the human dynamics of software development and creating a high performance culture.  One of the best individual tools I know for this type of situation is the Personal Agility Pyramid that we created at Gemba Systems.  (I know, it is not the best name, but it really works!)

Image

Here’s how the personal agility pyramid applies:

  1.  When you have a problem or an upset, you need to start with yourself before you send that angry email or tell someone about how they screwed up and you are frustrated.  Before you do anything check your a) safety, b) respect for the other person, c) ownership of both the problem and relationship.  Do not do anything until you are in a good place here.  (I missed that one and the angry email got out.)
  2. If you are like me, when you are upset you are very clear on what you don’t want, but not so clear on what you do want.  So step two is to get clear on what you want.  For me, it was “those who do the work decide how to do it”, “let’s create some very specific expectations and re-org the two teams so that we don’t need to go to each other before we do most things”, and “before you tell me why I made a mistake, ask me why I made the decisions I did.”
  3. Now that you know what you want, that doesn’t mean that is how it is going to work. In step 3 you need to go ask for what you want.  But remember, before you go ask what you want you really need to check step 1 – you’ve got to be safe, respect the other party, and come from ownership.  We are still in this stage.  We’re talking and aware of what we need but still haven’t reached on an agreement(s) to keep this from happening in the future.
  4. Make an agreement.  Now you have a concrete, visible, real agreement.  Congrats.  You are now potentially aligned.  Agreements – especially when you are new to this – aren’t always cut and dry.  People interpret them differently and can still be misaligned.  No worries, you’ll come back here at the next upset 🙂
  5. Confront a missed agreement.  Step 5 is not addressed until the next time you have an upset and you go through the steps and realize there is already an explicit agreement in place.  Unfortunately, this is where we usually start when we are upset.  This happened when I sent an angry email without going through step #1 and taking ownership of the problem and the relationship.

I’ve found this extremely effective for problem-solving and iterative and incremental alignment.  By doing this regularly when you have an upset it really helps your team continue to get better at the mushy stuff.

 
2 Comments

Posted by on August 27, 2013 in Individuals, Interactions, Teams

 

Tags: , , , , ,

Is It Safe?

The Scaled Agile Framework (SAFe), based on the work of Dean Leffingwell and his team, is a hot topic these days, and the discussion about it is characterized by hot language on both sides. Some people love it, others not so much. Taking sides on something like this is to be expected. But is it productive?

SAFe may not be the safest thing to talk about right now. But when it comes to discourse in the Agile community, we tend to be civil about it. So we thought it would be safe to come out with our own thoughts on the framework based on our experience of working with it, of reviewing the materials that describe it, and our  experience with Agile adoptions and implementations in general.

Getting the Big Picture

Over five days at the Agile 2013 conference, we had many opportunities to study “the big picture”. And each time we did, we felt like there was something missing. We realize now that that something is people.

In the Agile community we value individuals and interactions over processes and tools. We know that processes and tools are vital, but we acknowledge that their vitality is predicated on how people work together as they use them.

When we think about individuals and interactions, we think about organizational culture. Without a healthy workplace culture, processes and tools—even the very best—don’t work as well as we hope they will. We believe this is why so many Agile adoptions struggle and often fail.

Lots on “What”, Little on “How”, Less on “Who”

SAFe provides a detailed blueprint of what organizations can do structurally, but it is much less detailed about how things can be done, and it offers almost no information about interactions and individuals and the workplace culture that might support their success. This appears to have been a choice made with regard for the focus and scope of the effort as Mr. Leffingwell wrote in a recent blog post:

SAFe is largely quiet on the topic of implementation, change management and evolving corporate culture. We are focused on the framework content and continually understanding, and codifying best practices that people like you, in the field, discover. That is more than enough charter for us. However, we do understand that changing corporate culture to better reflect the behaviors and aptitudes of a Lean|Agile enterprise is a critical aspect. But, in our view, this is best achieved as result of success and better outcomes, rather than an object of attention to be addressed directly.

Let us consider this last sentence carefully. Is positive culture change best achieved by improved outcomes that result from new practices? Or are improved outcomes more likely to result from positive changes in culture?

We believe this is a false dichotomy. In our experience, the greatest successes and the most spectacular outcomes (the extraordinary productivity increases that research on Agile often describes) are achieved when culture and practice support each other in a positive feedback loop.

The Ever-Present, the Foundational, the Inseparable

Merely choosing to begin any type of Agile adoption is, in itself, a phenomenon of culture. An organization’s decision to trade one set of practices for another is only possible if the choice is culturally viable. Culture and practice are inherently intertwined and in play simultaneously. Our best chance of winning the game comes from leveraging both.

Culture is the soil in which the seeds of change are planted. To maximize our chances of success, we must tend to the earth as much as we tend to the business of getting things out of it. If the soil isn’t fertile when we start, and if it isn’t tended carefully along the way, growth is stunted, change withers on the vine, and in many cases, new initiatives die altogether.

SAFe is a strategy for change. It is a set of strategies, actually—a large and very impressive set that brings obvious value to organizations considering or executing large scale Agile adoption. But we have heard many times since organizational luminary Peter Drucker coined the phrase, that “Culture eats strategy for breakfast.” Why? Because even the best seeds have low yields in bad soil.

Back to Our Roots

We don’t have to go back to the Dust Bowl days or read The Grapes of Wrath to understand the importance of soil and, by extension, the importance of culture in advancing strategy. The soil of culture is where strategic change is grounded. Nor do we have to go back to the world-saving work of Norman Borlaug to know that the highest yields come from inspired and careful cultivation. But we must go back to Snowbird, Utah and the work that was done there in February of 2001, to remind ourselves of the fundamental ideas upon which Agile is based and why so many of us were so attracted to it in the first place.

When we do go back—when we read again the Manifesto and the Principles that define our work and enumerate the values of our global community—we see a group of people at the center of the software industry expressing the idea that people are at the center of software development.

Through all the projects and products we have contributed to and all our years of coding and coaching, we have come to believe that individuals and interactions matter, not only more than processes and tools, but more than anything else.

Culture is Complementary and Crucial

Culture without practice is daydreaming. Practice without culture is a nightmare. For SAFe—or any set of practices—to be optimally effective, a complementary cultural component is vital.

In affirming the importance of culture in Agile adoption and implementation, it appears that we are not alone. Mr. Leffingwell seems to be considering this as well. In the same blog post, he writes: “So maybe I’m wrong about just waiting for results before worrying about culture.”

To us this is neither a matter of right or wrong nor of waiting and worrying. Culture exists; it is here, now, in every organization where we work. It has mass and velocity; it is always moving in some direction whether we know what that direction is or not. And where it is moving always matters.

Just as we can make conscious choices about practice, so too can we choose to shape culture with commensurate intention. When we do, we bring under our control a force for powerful change while simultaneously reducing  risk. Is this a larger charter than attending to practice alone? Certainly. Do we think the effort is justified? We do.

We are happy to see that Mr. Leffingwell is also thinking about culture. It is our position that if we separate culture from practice, focusing on one to the exclusion of the other, we miss the opportunity to maximize results and minimize risk.

Haven’t We Known This Since the Very Beginning?

In pondering the interconnectedness of culture and practice, we we see why the dialog about SAFe has been so heated. In fact, we think Jim Highsmith saw this back in 2001, when he wrote:

…while the Manifesto provides some specific ideas, there is a deeper theme that drives many, but not all, to be sure, members of the alliance. At the close of the two-day meeting, Bob Martin joked that he was about to make a “mushy” statement. But while tinged with humor, few disagreed with Bob’s sentiments that we all felt privileged to work with a group of people who held a set of compatible values, a set of values based on trust and respect for each other and promoting organizational models based on people, collaboration, and building the types of organizational communities in which we would want to work. At the core, I believe Agile Methodologists are really about “mushy” stuff, about delivering good products to customers by operating in an environment that does more than talk about “people as our most important asset” but actually “acts” as if people were the most important, and loses the word “asset”. So in the final analysis, the meteoric rise of interest in, and sometimes tremendous criticism of, Agile Methodologies is about the mushy stuff of values and culture.

We too believe that people are most important. We believe that culture is the engine that drives the most extraordinary results and that inattention to culture is the most common impediment to the success of Agile adoption and implementation.

What Will Make SAFe Safer?

The question is not whether SAFe should be used as the strategic basis for large Agile adoptions. The question is this: What will make those adoptions most successful? We believe that culture is the answer to this question; we believe that culture is the key to making SAFe safer.

Culture is not a replacement for strategy; it is a complement to, and an enabler of, strategy. It is also the true scaling agent of large-scale change. Without sufficient attention culture change, strategic change is all too often gamed, and then thereby undermined, sometimes to the point of total failure.

Through our work, we have come to value interactions and individuals over processes and tools. That is, while we believe that there is value to the latter, we value the former more.

Amr Elssamadisy and Steve Peha

 
4 Comments

Posted by on August 20, 2013 in Culture, Individuals, Interactions, Organizations, Teams

 

Tags: , ,

Fooling Yourself About Ownership

Last week I was the agile conference in Nashville.  I had one session to present.  Unfortunately (and very fortunately) it was the very last session on the very last day.  That meant I had all week to worry about the presentation AND that the people attending would be exhausted.  Oh yes, and finally, I was up against Arlo Belshee and Esther Derby in two other sessions.  (I’m a very good complainer.)

Oh, the good part, I was co-presenting this with Steve Peha.  And Steve is a perfectionist.  To put it mildly, I’m not.  So Steve and I spent all week preparing for this session – one that I had taught in multiple forms over the years.  And I thought that there wasn’t much more to add or any new insights.  Boy, was I wrong!  So wrong, in fact, that I’ve got multiple blog posts that I’m sure are going to result from the week of preparing together.  This is the first of these blogposts.

Image

Ok, enough rambling (for now).  Let’s dig in.  Ownership.  Yes, we all know it is important.  In the software world, we’ve all learned from Christopher Avery about the responsibility process model and how we go through several stages: blame, justification, shame, obligation, and finally ownership.  And we know about this in all disciplines – business, education, government, etc….   Ownership is a well known (although not so well practiced) behavior for success.

So what’s new?  Well, it first came out in a discussion late Sunday night over coffee.  We were using some of our own life examples about what safety, respect, and ownership meant to us and testing my theory that if you have these three things, you are in a much better position to get great results – especially in a team.

And so as we were working through Steve’s example:

I was having a rough relationship with a more senior product owner in the company.  We couldn’t seem to work together.  He’d give me some requirements to take to my team and I thought I’d understood them.  At the end of the iteration, he’d say that we’d failed to meet his goals and I felt dejected.

And it kept happening.  No matter what I did, I couldn’t find a way to get aligned on what he wanted.  It was pretty bad.  I felt unable to do my job well.

It was so bad, that I basically said “ok, I’m just going to take notes without discussion and then do my best to work on this myself offline.   I’m going to make the best out of a terrible situation.”

So I’ve known Steve for several years, and he is really smart – I mean the type of smart that you wouldn’t believe.  Plus, he is humble.  He is a domain expert in the field – in fact he blew anyone away at the company in that regards.  He knew the domain significantly more than the senior product owner.  And so, for me, I could see that he probably intimidated the hell out of the other product owner and the other guy was just acting out; trying to feel less incompetent by pointing the finger at Steve in this way.

But Steve couldn’t see that, I could see he was still frustrated by the situation.  In fact, he felt he had taken ownership of the situation and made the best out of a very bad situation.  And, in a way, he had.  He had taken ownership of the requirements to be written.  But that obviously did not lead to success.

What Steve had done was the easy part.  It is also the part that doesn’t really matter as much.  As we talked about it Steve came up with a new insight:

I blew it!  I fooled myself into thinking I had taken ownership of the situation, but all I did was create more work for myself.  I dropped the relationship because it was too painful.

Steve had not taken ownership of his relationship to the senior product owner.  He just let it go.  And, in a team, that is exactly the wrong thing to do.  If you are in a team setting, you will be much less likely to succeed if you only focus on the problem – or your part of the problem.  Even if you focus on the entire problem – your part and everyone else’s part – you are still in a bad spot.  You’ve created more work for you and ignored your relationship to other team members.  You need them to succeed.

So, to maximize your chance of success, you must own the relationship also.  No, you can’t control anyone else’s actions, and I’m not suggesting that you do.  What I am suggesting, is that for successful teamwork you must own the relationship as well.

Once you’re there mentally – owning the problem and relationship – you are ready.  That means not blaming others for the failed relationship; not justifying why it deserves to be a bad one because the other person is an asshole; not making any excuses.  You roll up your sleeves and work on possibly the single most challenging and rewarding work there is on teams; working on relationships with your colleagues.

The ‘how’ of fixing relationships is covered in many books, and I’ve got much to say on the subject.  But that will come out in later posts.  What I want you to remember is this: true ownership is ownership of the problem and your relationships to your team members.  All too often we fool ourselves into thinking we are coming from ownership by only owning the problem.

 
1 Comment

Posted by on August 13, 2013 in Individuals, Interactions, Teams

 

Tags: ,

Agile Adoption, Second Order Change, and Mindset

I’m currently rereading Change and trying to see if I can learn to apply some of the ideas.  At a very high level, the book makes the argument that there are two types of change.  The first type of changed is described by the common saying:

The more things change the more they stay the same.

And this is described as first order change.  The second type of change – second order change, has a more lasting effect.  If we are dreaming we are being chased, there is nothing we can do within the dream to escape the dream.  We must wake up – which is a completely different state of being.  Or if we are driving a car, the gas pedal can only take us so far.  To accelerate beyond the given boundaries we need to change gears.  Second order change is like waking up, or changing gears.

I hope you’re with me so far 🙂 Theoretically this makes sense.  And being in the agile transformation space, I can see most of the current agile adoptions suffering from the fact that they are only first order changes.  Therefore, little really changes in terms of end results.  However, in the few great successes – it  is like being in another world.  Things are different, and can’t be explained as a result of just the agile practices.

So, what does it mean to create second order change on a team or organization?  What does that mean in business?  What is second order change in software development?  How does this theory translate into something concrete?  An example from Change makes a good illustration:

One of the changes affected by the Red Guards during the early stages of the Chinese Cultural Revolution was the destruction of all public signs (of streets, shops, buildings, etc.) which contained any reference to the reactionary, “bourgeois” past, and their replacement by revolutionary names.  Could there be a more radical break with the past?  But in the wider context of Chinese culture this break is fully in keeping with that basic rule which Confucius called the rectification of names and which is based on the belief that from the “right” name the “right” reality should follow – rather than assuming, as we do in the West, that names reflect reality.  In effect, therefore, the renaming imposed by the Red Guards was of the first-order change type; it not only left an age-old feature of Chinese culture intact, but actually re-emphasized it.  Thus there was no second-order change involved, a fact that the Red Guards would probably have had difficulty appreciating.

That’s what I’m exploring.  I’ve  participated in several successful and failed agile adoptions.  I have observed  the keys of success were in the individual human dynamics and the culture created by leadership.  So it seems to me that the change of mindset of the individuals and the change of culture have created that second order change.

The change of mindset supported by culture creates second order change.

By changing our perceptions of the world, we “shift gears” or “wake up from the dream”.  Changing mindset, however, is a very intimate event.  It is the moment that the proverbial light bulb turns on.  And that lightbulb can easily flicker off if not followed by actions and feedback that feeds that initial spark (yes I’m mixing metaphors – sorry).  This is really cool!

But for me, as a change agent, it is still unclear.  I cannot consciously repeat it, even if I have unconsciously, by gut, done so over the past several years.  I know there is something here – and making it concrete help me and my clients, and help me communicate it to others and if I’m extremely lucky be a real contribution to our community.  I am increasingly sure that this way of seeing the world of change is a piece of the puzzle.

So here is my proposal: let’s all go back to the moment(s) where the light-bulb turned on and we drank the kool-aid.  Let’s describe those moments.  Here, on you personal blog, or an email to me.  I’ll create a catalog and we can look at them for patterns.  I will publish the results and make them available to all at regular intervals.

 
1 Comment

Posted by on July 22, 2013 in Culture, Individuals, Interactions

 

Tags: , , ,

Why are most Agile Adoptions Failing?

I’ve moved this post to Industrial Logic’s blog.  I’ll continue to share my thoughts on my personal blog here and share the more mature articles to Industrial Logic’s site.

– Amr

 
1 Comment

Posted by on June 17, 2013 in Culture, Individuals, Organizations, Teams

 

Tags: , , , , , ,

How Self-Organizing Teams Get Stuck

Self-organizing teams are those teams that are given a goal and decide amongst themselves how best to solve the problems at hand to achieve the goal.  In the agile world, these teams also work in small cycles and use feedback to learn quickly and adjust course as needed.  When things go well – these teams do extremely well.  In software that usually means building great software that delights the customer.

But things don’t always go so well.  I’ve been on many such teams that don’t achieve those levels of performance and sometimes fall flat on their face and fail miserably.  What happens?  Here are some common stumbling-blocks that I’ve observed:

  • Lack of safety.  When individuals on a self-organizing team feel unsafe to share their thoughts and experiences and ideas the team is unable to leverage that expertise to make decisions and learn quickly.  Therefore the teams learn more slowly and make more mistakes and are blocked.
  • Lack of ownership.  When individuals don’t take ownership for the success of the team, they watch mistakes happen within the team and “don’t step up” to fix them because that is not their responsibility.   However, self-organizing teams kick-ass because they are able to leverage the diversity of the group.  They make great decisions and learn quickly because everyone takes ownership for the success of the group.
  • Not addressing problems early.  No matter how safe things are, or how much ownership you take, if you don’t see problems and address them when they are small, you have no chance of achieving high performance.  The problems grow and become significantly harder to solve.
  • Not caring about human dynamics.  Sometimes we get annoyed with each other.  Sometimes we have disagreements and some bad feelings linger and may fester.  Great teams don’t let these things build up and have the difficult conversations quickly.  However, for the rest of us, this is the beginning of the end.  We end up spending too much of our time working with things.  We start to feel unsafe around others.  And we disengage.
  • Not using consent.  Self-organizing teams do the best they can to get everyone’s input and make it real.  That is best done by consent – not majority rules – or leader rules – or more experienced rules.  You miss too many opportunities to do the right thing and catch mistakes early if you discount someone’s ideas.  They have legitimate concerns even if they are the in the minority.  Effective teams take the time to listen and address those concerns.
  • Not able to confront and learn from failure.  Knowledge work is all about creating something new.  And creating something new is always fraught with mistakes and missteps.  However failure is often unsafe and painful.  Teams that are unable to confront failure will not learn from those opportunities and will often take much longer to get to a less effective solution than teams who fail fast and learn from those failures.

And, if you manage to get it right at the team level – how does this scale?  Or does it?  In many organizations, a small team doing well will only be a blip on the radar and won’t really affect the success or failure of a product, let alone the organization.  But that’s a topic for another post, stay tuned….

 
Leave a comment

Posted by on April 26, 2013 in Individuals, Interactions, Teams

 

Tags: