RSS

Author Archives: samadisy

About samadisy

Dad. Global Citizen. Egyptian. American. And, oh yeah, software guy focused on the human dynamics and cultures of high performance teams.

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: , , , , , ,

Is it Safe to Fail?

Yesterday I was working with a group that was struggling with the balance between product owners and developers. It wasn’t an “Us vs. Them”, but a common tension that I’ve observed on teams working to get real results out of agile practices and processes. This particular team was using Scrum and we were discussing the question of when to review work during an iteration. Should the product owners wait until the end of the iteration to review the work? Or should they be reviewing work during the iteration as it gets completed? And what happens if they find something that doesn’t meet what they need?

In this particular situation, developers were often upset when product owners reviewed things that were still in-progress because “they weren’t ready yet.” They wanted product owners to hold off until they – the developers – said it was “ready for review”. The product owners, on the other hand, wanted to review things early so that if developers were going down a blind alley, they could tell them early on. Also, if there was a mistake – on either the product owner’s side or the developer’s side – that it was caught early and we didn’t spin our wheels working on something that would eventually get thrown out.

This is not an unusual situation. This particular scenario is one of the common reasons many teams find Kanban so attractive – because the artificial time-box of an iteration seems to keep us from doing the right thing and recognizing and responding to change early and often. But I wonder if this particular problem is not related to iterations at all.

In fact, I’m going to suggest that the root cause is the lack of feeling of SAFETY in and on the development team. Let me take a few steps back to explain:

I’ve been lucky enough to be on several high performance teams in my career. And these teams are phenomenal – they  are significantly more productive than your average development team. They do much better work from many points of views: quality, time to market, visibility, etc…. They also enjoy their work much more.

These teams are great at software development which means that they are extremely good at learning from failure. They use agile methods to build software, get feedback early, and respond to that feedback accordingly. A large portion of that feedback is based on failure: writing software that fails tests and gets fixed, building features that don’t meet the user’s needs and has to be re-designed or completely trashed, putting in technical solutions that don’t scale, and hundreds of other issues that come up. Those teams don’t get caught-up in the potentially draining tensions and stresses associated with failure.

Why not? What is special about these teams that they are resilient to the dragging and draining effects of failure – let alone regular and repeated failure?

You probably won’t be surprised to hear from me that I don’t have the entire answer, and the answer I do have falls into three categories: agile practices, individual human dynamics and culture.

Let me explain further. Failure – for most of us – is not an enjoyable experience. However some of us have become good at it. And the major reason behind this is SAFETY. If we feel safe to fail, and are rewarded for it regularly, we can find ways to fail fast and learn quickly.

Here’s what I’ve experienced and observed in teams that have the skill of failing fast and often and learning from those failures:

  1. Leaders create a culture that rewards small failures and the successes that come after them. They celebrate the successes and failures and lead by example.
  2. Individuals understand that failure is a milestone the road to success. They have experienced it multiple times and are not intimidated by it.
  3. Teams use software development practices that make failure SAFE.

Let’s look at #3 a little more closely. Consider different types of failures: failure in private and public failure. Failure in private is much easier to handle (although still not easy). Also consider that small failures are less overwhelming than large failures. A small failure is easier to recover from.

Now let’s consider some concrete practices that make it safer for us to fail:

  • Think of test driven development (TDD). How much easier is it to fail privately at your desk with a red bar, fix it, and then check in working code? How much less intimidating is it to find a mistake after a few minutes of work than a few days or weeks? Also, the other half of this coin, is the success and frequent, small celebrations of success when a developer sees a green-bar indicating tests pass.
  • Think of test driven requirements (aka TDR, automated acceptance tests first, behavior driven development/BDD, etc). How much easier is it to work incrementally with some FIT or Gherkin tests to make them pass and fail at the privacy of your own desk than it is for someone to manually review your work with you and point out your mistakes (or even worse, in the middle of an iteration demo with execs looking on)? Also, just like TDD, a passing test is a celebration of success.

The complaint from developers in the beginning of this blog were about product owners calling out their failures early and often. It was painful for them to have these issues brought up in public.  However these conversations with product owners have the potential of accelerating the learning of the team and thus accelerating their performance. The same developers on a team that practice TDD and TDR have fewer of those circumstances happen yet get the same feedback because these failures happen at their desk.

So, in the end, one of the best ways to encourage the learning from failure practice that is always found in high-performance teams is to make failing safe AND to celebrate successes. We can do this on multiple levels: at the cultural level, at the individual human dynamics and mindset, and with the software development practices we use. A few agile development practices are extremely good at this, specifically test driven development and test driven requirements because they allow us to fail privately and create small reward loops where we constantly celebrate small successes.

 
3 Comments

Posted by on June 5, 2013 in Culture, Interactions, Organizations

 

The value of Values

Values.  Really?! Come on!

Introduction

Values are one of those over-used ideas that many of us roll our eyes when we hear it discussed (I strongly resemble that previous remark).  To me, it lands in the same category as “empowerment” – over-used, rarely beneficial, mostly BS in the work world.  However….

However, I’m writing a blog entry about values.  As an individual, I have values that I feel very strongly about (even if many times they are implicit and I’m unaware of them).  And I find that if I am in a place where my values don’t fit with the mainstream then I begin to not enjoy the work.  And what may have been enjoyable and fulfilling in other circumstances is now a chore.  For me personally, it grates enough that I end up leaving the situation if I can’t change it.  And how do you change the values of an organization anyway?!

A Theory

The values of a team or an organization are pretty heavy stuff.  What are the values of an organization anyway?  The real ones, not the ones on a plaque – what are they?  Here’s an idea: they are the culture of that organization.  The culture of an organization is defined by the values of the group.  They are usually invisible and likely different from the official ones written by the leaders with the help of expensive consultants.

But it gets a bit messy here because the values of the group are not necessarily the values of the individuals in that group.  The values of the group are the expectations in the ether.  (Sorry, don’t have a better definition, ping me if you do.)

Ok, so far we have:  Values of the individual are present – we all have them and feel strongly about them – although we are not all aware of them. Values of the group are there also.  However, they are not the total sum of the values of the individuals since we often find conflict between the values of individuals within the group.

When values of the group align with the values of individuals, something magic has the potential of happening.  I don’t know if it always does – but those “magic teams” that I’ve personally witnessed and have been part of – have it.  They have alignment between the individual and group values.  Now, if those values happen to help produce great software – wow!

A Concrete Instance

So, I had a conversation with a very good friend of mine about his software development team and how there is a huge Us vs. Them between the business analysts and developers.  The developers are not happy with the requirements – they are not concrete enough – and they want them right the first time.  The business analysts are afraid of the developers since they sometimes provide less-than-perfect requirements.  And if they ever change their minds once something has been built, and fail a story, even though it met the letter of the law, all hell breaks loose.

So, is this an agile team?  Ok, I don’t really care that much if they are agile, but if we look at the behaviors we can see the following values executed:

  • We succeed and fail alone – as individuals – not as a team.  Developers are upset when business analysts fail a story even if the act of testing the code shows that the requirements were wrong.
  • We prefer getting things right the first time over iterating. Developers want business analysts to get the requirements right the first time around and are upset when they don’t.
  • Achievement is more important than respect and a safe environment. Business analysts are intimidated by developers and will sometimes overcompensate on their story writing creating waste.

My judgment may seem a bit harsh, and it is probably missing many of the nuances that are really happening on the ground.  However this is not the first time I’ve seen this dynamic (sometimes reversed) and it is not unusual in software development teams.

Remember I said that “being agile” is not important, but creating software is very important.  This is a product team, and innovation is extremely important.  The lack of safety and lack of ownership evidenced here will always be in the way of this team’s ability to be innovative and become a high performing team.  No amount of technical prowess can remove this dynamic; in fact, if there was more technical prowess on the team it may accentuate the problem.

I have been talking about individual behaviors leading the way to individual values.  But if we trace back just a bit, to the culture and environment of the organization, we can learn some things too.

  1. There is no clear negative consequence to creating an unsafe environment.  Does this mean that safety is not a priority?
  2. There is no clear negative consequence to claiming individual success while there is a failure in another part of the team.  Does this mean that team success is not rewarded?  Or maybe that individual success is rewarded much more than team success?
  3. There is no clear negative consequence to pushing for things to be “done right the first time” as evidenced by the backlash against business analysts changing their mind.  Does this mean that there are people who are allowed to make mistakes (developers through the development cycle through TDD) and people who aren’t (business analysts getting feedback from working software and changing their minds)?

What would happen if ….?

What would happen if this team had a culture that values:

  • Iterative learning.
  • Learning through failure.
  • Succeeding as a team.
  • Ownership.
  • Safety.

And furthermore, what would happen if these values were clear, upfront, repeated by management again and again whenever addressing difficult problems?  Would people change? Maybe.  Would everyone stay at the company?  Probably not.  Would they build better software?  Absolutely.

In the end – it is much easier to poke holes into something out there when you are not that close.  My friend who related this story is one of the single best managers I’ve met in my life.  He sees these issues and works on them, and in the end, I’m sure he’ll find a path to lead his team out of these difficulties.

 
3 Comments

Posted by on May 17, 2013 in Culture, Interactions, 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:

On Transparency and Openness

We all want to be transparent and open on our teams – don’t we?  Well, at least we want the benefits that come along with it such as:

  • not being surprised at the end of a long project that we are off-course,
  • ability to recognize change early in order to respond to it,
  • a way to build trust in what we are doing,
  • a mechanism for estimation
  • and many more….

However, achieving transparency and openness are more difficult than they might seem to start off with.  One of the primary reasons, is that if you are transparent and open about the work you do, the agreements you make, and the results (or lack thereof) you achieve, you also open yourself up to publicly failing.  And that public failure is extremely painful for most of us.

If you are a coder, can you remember the first time you ever had to pair-program?  If you are a product owner, do you remember a time when you had the team working on the wrong thing and was questioned about it?  For the rest of us out there, can you remember the last time you had someone review your less-than-perfect work?

For most of us – it is uncomfortable having someone review our work and see our mistakes.  But that is what we are asking of people in the agile world:  to pair-program, to build in iterations, to meet the definition of done, to estimate and openly miss those estimates.  And not only that, we are saying that people should do more of it, fail more often so that those failures are smaller, and confront those failures and learn from them.  That’s a TALL order for anyone.

(Unfortunately?), transparency and openness are absolutely necessary for sustained high-performance.  And being able to fail quickly and learn from our mistakes is a hallmark of great teams.  Every single team that I have witnessed achieved hyper-productivity has achieved this state has found a way to be comfortable with failure and leverage it for learning and success.

So, how do you get past that discomfort, pain, and fear?  Well, in many ways you don’t, it will always be there for many of us, however we can make it more palatable and increase the chances of truly achieving and sustaining the benefits by making things safe.

the state of being safe; freedom from the occurrence or risk of injury, danger, or loss.

In many ways, we feel a risk of injury, danger, or loss when our mistakes are made public.  Are we going to be blamed if our mistakes are visible?  Will it affect our review at the end of the year?  Will someone roll their eyes and say that they can do it much better?  Will we be humiliated or will we lose standing on the team?  These are things that exist in many of our lives at work.  And when they do, we feel unsafe.  And when we feel unsafe, we will shut down and shut down transparency and openness along with it.

So what can we do about this?  Well, we need to make things safe.  How do we make things safe?  As always I don’t have a recipe independent of context, however, here are some effective tactics:

  • Be reflective.  When there is an issue or problem ask yourself how you are part of the problem.  Listen – really listen.  When people feel listened to and acknowledged, they feel valued and they feel more safe – even if they end up being wrong.
  • Respect people.  No matter what you say, or what you do, your opinion of the people you are working with seeps out; sometimes through body language and sometimes through the tone of voice and other means.  You can’t fake respect and everyone can sense it.  So, if you want to create safety, you genuinely have to respect others and see them as equals.  (Anatomy of Peace is a great book on the subject.)
  • One thing my friend Steve Peha does when he is facing a problem with someone else, he addresses himself and his perception of what’s happening and his reactions to the issue at hand instead of (as most of us do) pointing the finger at the other person and telling him/her how they have goofed and upset us.  Christopher Avery’s work on Responsibility Redefined is spot on here.
  • Trust people.  You don’t have to be nieve about it, but start with trust.  You can always re-evaluate if you’ve misplaced your trust.  Trust in another person shows that you see they have value.
  • Focus on the subject – not the people involved – and be ready to be wrong.  It’s ok.  None of us have it all figured out.  So instead of arguing who is right or wrong, focus on the work; the subject – instead of yourself or the other person.

Looking back on this list, it feels woefully inadequate for such an important subject.  But it is what I have today.  Maybe tomorrow I’ll have better answers.

 
4 Comments

Posted by on April 19, 2013 in Individuals, Interactions

 

Tags: , , ,

How To Be Mediocre Without Even Trying

INTRODUCTION

Have you ever been on a team of aces – the best of the best – and failed? Have you ever been on a team that consisted of average people, found your rhythm and exceeded expectations? Have you ever been on a highly successful agile team and then later used the exact same practices with another group of people, but failed to get the desired results? Why do the same practices work really well with one team and not another? What is behind this?

There is a frequently self-fulfilled stereotype among technical professionals that we are not good at interpersonal skills, that such are traits of one’s personality, and consequently un-learnable. Many of us feel uncomfortable with the topic so we tend to underplay its importance, which is evidenced by our characterizing such skills as touchy-feely. We focus on our work – the real work – of writing code, coming up with and maintaining designs, and architecture. The touchy-feely things are unimportant and frequently get in the way. The technical practices are the important thing.

Hereʼs the [hidden] truth: we are wrong. Agile methods constantly bring up problems and upsets. Agile methods do not ensure success alone. Our ability to respond to problems effectively as individuals, teams, and organizations is the real key to success. The answer to success is therefore not in the technical practices but in the human dynamics beneath our methods. Human dynamics are the difference between a failed team, a team that gets by, and a hyper-productive team. Unfortunately, many are unaware of these practices, and therefore using different agile methods alone becomes a hit-or-miss gamble.

The good news is that these human dynamics are learnable. In this article I will explain why this skill set is so important to highly productive software development and give you a simple model to better understand what these skills are, and when they should be used. But before we dig into the skills, letʼs take a look at software development in general.

LEARNING IS THE MOST COSTLY PART OF SOFTWARE DEVELOPMENT

Here is a hypothetical situation that I have presented to many of my students:

Suppose I was your client and I asked you and your team to build a software system for me.Your team proceeds to build the software system. It takes you a full year – 12 months – to deliver working, tested software.

I then thank you and your team and take the software and throw it out. I then ask you to rebuild the system. You have the same team. The same requirements. The same tools and software. Basically – nothing has changed – it is exactly the same environment.

How long will it take you and your team to rebuild the system again?

When I present this hypothetical situation to my students – many of them with 20+ years experience in building software – they typically respond with estimates that are anywhere between 20% to 70% of the time. That is, rebuilding a system that originally takes one year to build would take only 2.5 to 8.5 months to build the second time around. This is a huge difference! Do you know any one factor that can affect software development that much?

So, what was the problem? What was different? The difference was that the team had learned. They learned about each other as a team and have gelled over the year. They learned about the true requirements – not just those written down. They also learned to use the toolset, the idiosyncrasies that come up during all software development. Basically they worked through all the unknowns until they built and delivered a successful software system. Learning is THE most costly part of software development.

Thatʼs the main reason that agile practices (sometimes) work so well – they are all about recognizing and responding to change. Agile practices from test-driven development and continuous integration, to iterations and retrospectives are all accelerating feedback to enable the team to learn faster. By cycling at every possible instance, agile teams have the opportunity to accelerate learning and address the most costly portion of software development.

But learning is not automatic and it does not come for free. Anything that impedes our ability to learn will take us down the road to mediocrity. That is where human dynamics come in. If we donʼt know how to leverage problems individually and as a team and organization, then we cannot benefit fully from agile practices – no matter what those practices are.

WHY ARE HUMAN DYNAMICS IMPORTANT?

Software development is a team sport; we either all win together by producing great software, or we all lose together by not achieving our goals no matter how well we execute individually. For software teams, there is no such thing as “it is not my problem”. Believing that a problem belongs to only one member of a software team is as invalid as for people on a plane to say “it is not my wing on fire”.

These skills are important for everyone, even purely technical roles such as developers and architects. Consider the following scenario as an illustration:

I am a developer on a team who gets the architecture and/ or design handed down from above. I just got out of a meeting with our architect where he explained the reasons behind why things were set the way they were. He was very polite and said all the right words; but I did not feel listened to.

I brought up what seemed like important issues of things that are infeasible given the current libraries we use. I was unsatisfied with the architect’s answer. He just explained the issues away as though brushing them aside. On the surface I can’t really argue, but I feel frustrated because his ‘words’ are right but I still have a sinking suspicion that things are not right. I am also a little annoyed that my architect didn’t take me seriously and I have started thinking of him as disconnected and an ivory tower architect.

This has several effects on our productivity:

• I may not do my best at solving the problem his way and will be glad if it fails and say ‘I told you so’.

• I may ignore the architect, because of my new perception of him, and that will cause an inconsistency in the code. If I am right, people coming to work on the code after me will have a harder time understanding it in a larger perspective. If I am wrong, then I’m wasting my time on a solution that will not work and impact the architect’s perception of me.This, in turn, will make me more resentful.

• I work much more effectively when I’m bought in and excited. When I’m doing things out of obligation I do what’s necessary to get by. It is also more difficult and stressful on me, which directly affects my productivity.

• The architect will not trust me no matter what choice I make. If I do what he says slowly (because I’m coming from obligation) he’ll think I’m slow. If I don’t do what he says he won’t trust me at best and will consider me an obstacle at worst.

This scenario shows how sincerity (the architectʼs and later mine) affects ownership. I abdicated ownership in the scenario when I did work out of obligation. My perception of the architectʼs insincerity reduced my trust in him, and my actions will reduce his trust in me. All of this happened because I perceived a problem but did nothing to confront the issue or correct it. All of this happened in an environment where ʻarchitectsʼ hand down the law to ʻdevelopersʼ – an environment that leaders in the organization have created and maintained.

My part in it, even if I am a lowly developer, is that I have chosen to join such an organization, and I let my upset affect my work and did nothing to resolve it.

In all of these scenarios I have impeded my ability to learn and the ability of others to learn by not confronting the upset and working it out. The odds are good that if my architect reacts negatively and does not address my upset that the problem will fester and grow and continue to affect our ability to learn and thus our productivity.

AGILE METHODS EXACERBATE UPSETS

Now, as I said before, agile practices are especially good at bringing problems to the forefront because of the numerous inspect and adapt cycles. How we react to those problems, both individually and as a team, makes the difference between hyper-productivity and mediocrity. To that end, when we encounter a problem there are several fundamental, learnable skills that deeply affect our effectiveness as technical professionals in a team environment because they equally affect our ability to learn.

If the scenario above was on an agile project, my code would be quickly used by others and the problem would be brought up again and again no matter which route I took. This would have been likely to increase the animosity between the architect and myself. We might very well have ended up in a difficult confrontation that would have entrenched us in our positions because we saw each other as obstacles.

Or it may have been solved – if either of us were skilled in the human dynamics of regularly solving these types of problems. The teams that are successful with agile methods are the ones that have members who are adept at leveraging such problems for their benefit and that of their peers.

IMMEDIATE AND LASTING RESULTS BY PUTTING HUMAN DYNAMICS FIRST

Iʼve shown a typical scenario in which an upset impedes learning. However it does not have to be that way. Every upset is an opportunity to grow and learn, both individually and as a team. If I could solve the upset and take ownership of the problem I would keep from impeding my learning and that of the team. And if I could find a way of doing this myself – without having to rely on anyone else to change then it becomes feasible. Those are two pretty big IFs, but those are the skills that we must master to succeed. Those are the skills that will turn our losses into wins and make every problem an opportunity for success. Those are the skills that are more important than the technical agile practices.

Furthermore, it is not only the skills that matter, but when we use those skills. For example, I put the blame on my architect before asking how I had a hand in creating this upset. I put the solution to my upset squarely on the architectʼs shoulders since he is at fault for my problem. Now the only way to solve the upset is to change the architect and since I see him as incompetent anyway then Iʼll have an extremely hard time of doing so. So the first category of skills that we must address, before anything else, is working on ourselves. Can we take ownership of our own problems? Below are five categories of human dynamics skills that we must address in the proper order to reliably and repeatedly leverage our upsets for improvement:

  • SELF. By far, the easiest person to change is ourself. This is our greatest point of leverage in solving a problem. Instead of blaming the architect and starting down the road of either working out of obligation or doing my own thing, I should look at myself first. If I take ownership of the problem and see the architect as a team member and not stereotype him as an ivory tower architect I can prevent a vicious cycle.
  • CLARITY. When facing a problem we are often very aware of what we donʼt like about it. We are aware of the problem. But are we aware of what we want? I was very aware of what I did not want – I did not want the architect dismissing my ideas or looking down at me. But what did I want? It was clearly more than just presenting my solution. Feeling disrespected and undervalued had a large part in my upset and my actions moving forward.
  • ASKING. Once we are clear on what we want, chances are we havenʼt asked for it. The next step is to ask for what we want from others explicitly. I did not ask the architect for respect I just assumed he did not respect or value me and subsequently I lost respect for him.
  • AGREEMENT. Asking for something does not mean you will get it. Have we reached explicit agreement? If we let problems be, the best we can expect is that they will linger and many times they will fester and grow as they may with the example above.
  • CONFRONTING. Once we have asked and agreed upon something then it is appropriate to call someone on a missed agreement. Many of us are extremely uncomfortable with confrontation and are not skilled in doing so in a constructive manner.
    This means that many of us either shy away from confronting others or are so uncomfortable with confrontation that when we finally get the courage to do something we do so under great pressure.

The above categorization is an umbrella for a large set of human dynamics skills that are learnable and applicable to our day-to-day work. There are many models and discrete practices that fit under each of these categories that help us implement these actions. I would like you to remember that order matters. Before you call someone on something you believe they did wrong, go through steps 1 through 4 before executing step 5. How did you help create the problem? Are you clear on what you want? Have you asked for it? Did you get explicit agreement? Only then is it fair and proper to call someone on a missed agreement.

MEDIOCRITY HAPPENS ONE SMALL STEP AT A TIME

Beware that small upsets that go unaddressed build up. Agile methods can be painful and counter-productive if we donʼt address the upsets that come up frequently because of the cyclic nature of many of the agile practices. That in turn, impedes our learning little by little, which can slowly bring our progress down to a halt and put us in a situation worse than before we started adopting our agile method of choice. Since learning is the largest part of software development, we need to figure out how to learn from every upset instead of allowing upsets to slowly bring our productivity to a near halt.

 
1 Comment

Posted by on April 16, 2013 in Individuals, Interactions

 

Tags: , , ,