RSS

Category Archives: Culture

How To Create Psychological Safety

22 Jan

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

 

Our Most Effective and Least Adopted Practice

27 Jan

Test Driven Development is one of the most effective practices from the agile community of practices, and also one of the least practiced regularly.  Why is that?  Why, 15 years after it’s introduction to the world via Kent Beck’s eXtreme Programming Explained, is one of the least adopted practices in the community?

Test Driven Development is One of the Most Effective, Yet Least Adopted Practices in the Agile Community

After years of practicing it and teaching it to others I have a few ideas on the subject.

First of all, Test Driven Development takes time to master.  It is conceptually simple, however, practicing test driven development on existing code, not written for tests tends to be very difficult.  And for some reason, even though there are some really great, and simple, techniques out there for working with legacy code (most prominently Michael Feathers’ book by the same title), people tend to be unaware or unpracticed with the well-known and well-documented techniques.  This means there is a skill-gap in using test driven development for existing, untested, code bases.

Most Developers are Unaware or Unpracticed at TDD Techniques for Code Not Written With Testing In Mind (Legacy Code)

Then there is the problem of the current way TDD is taught in the community.  We, the coaching community usually teach TDD on toy applications built for a classroom situation.  And students leave the classroom having learned the basic skills of TDD on greenfield applications and unable to apply them in their daily lives with aging code and tight deadlines.  The techniques of working with existing code are usually considered advanced and not broached until teams become practiced with the basics of TDD.  Unfortunately most teams don’t become practiced in TDD because they cannot apply what they’ve learned in class to most of their regular work.  Finally, although there are a few workshops out there where coaches teach TDD on their clients’ live code, they are by far and large the minority.

Most Students Leave TDD Training With The Ability to Practice TDD on Greenfield Applications Yet Their Day-To-Day Work Is On Legacy Code

For those lucky few, that learn TDD in a class, have follow-up coaching afterwards as they begin to master TDD in the few cases where it is possible, and advance enough to learn how to work with legacy code effectively there is one last hurdle. You need to make TDD a daily habit.  And making TDD a daily habit is easier said than done.  Even well practiced developers, who have been doing this for years, spend roughly 40% of their time writing tests and 60% of their time writing production code.  For those new to TDD, if they want to create such a habit, they will need to spend the majority of their time writing tests, not production code, to make things stick.  Add to that the existing deadlines.  Add to that managers that might become worried as velocity drops.  And, add to that, our own critics in our head that start to get worried that we are spending much of our time writing tests. To make TDD a habit, given such a large step size, we need an immense amount of personal and team motivation to make it part of our day to day lives.

Making TDD a Habit Requires Sustained High Levels of Motivation

Finally, if you learn TDD, get coaching to apply it to your existing code, are excited enough to sustain the levels of motivation needed to make it a habit, you have one final hurdle.  You are dependent on the rest of the team.  TDD is a brittle practice.  That is, we all need to be practicing TDD on the team to succeed.  If I write a test, and someone else breaks that test and does not fix it, then the TDD habit isn’t going to last.  Also, if I am the only one writing tests on the codebase, and my colleagues aren’t, we won’t ever reap one of the great benefits of TDD – a safety-net of tests that enables us to refactor regularly and changes the cost of change curve for our project so that is affordable to make changes late in the game.

TDD Is Fragile – Success Relies On the Whole Team Practicing

With all this stacked against us: a big learning curve, ineffective training techniques, a need for sustained levels of high motivation, and fragility, it is no wonder most of us in the Agile community do not practice TDD. We need a new approach to learning and practicing this most valuable of skills.

We Need a New Approach to Learning TDD

I’m not writing this blog as a lament; I’ve been working on parts of the puzzle for a few years and the last piece is now sliding in place:

Training: TDD is a difficult skill.  Teaching it effectively even more so.  We need to reconsider how we train TDD.  The current method has proven ineffective. We need to either go back to the old XP immersion classes which jam-packed a team into a shared workspace for 2-weeks of intense work, or we need to start teaching legacy code techniques at first encounter – preferably on live code – so students can transition to daily work after class.

Teach Legacy Code Techniques In Introductory TDD Classes

Building habits: the latest research on making practices into habits gives us new ways to be more effective in transforming the way we work.  One very effective technique is to take ridiculously small steps to reduce the levels of motivation needed and build the habit first.  Once the habit is there, then we can layer-on sophistication and complexity.  Specifically to TDD, we need to find the smallest possible step – an MVP of TDD training – that we use to build our habit first.

Design and Use an MVP of TDD Training

TDD fragility: Because TDD needs the whole team to work together effectively, we need to create a culture that encourages individuals on a team to write tests regularly.  The work I’ve been doing with Steve Peha on agreements-based culture is an effective way to make that a reality.

Leverage Agreement Based Culture Techniques To Get Full Team Participation

By putting those four techniques together we can, as a community, start benefitting from our most effective technical practice.

 
Leave a comment

Posted by on January 27, 2014 in Culture, TDD, Teams

 

Tags: ,

Estimates Are Always Low and Dates Are Not Met

16 Dec

Estimates are always low so dates are not often met.  That is a common occurrence in today’s software environment.  There are many, many approaches to this age-old question.  Relative estimation, no estimation, ideal days, and some fancy-shmancy techniques that are mathematically sound (given a few unsound assumptions) that are significantly impressive to those so inclined.

Whatever technique teams choose, they are often still disappointed.  So what gives?  Is there a practice out there that can save us?  My answer is both yes AND no.

The no part is easy. No, there is no one practice out there that can give us accurate estimates. Estimation is fortune-telling.  And all fortune-tellers (at least in software) are wrong.  Estimation is a lie.  Pure and simple.  But it is a very useful lie, because it really helps to have some indication about what and when we’ll get things done.

The yes part is a little bit more involved.  And it comes at the problem side-ways.  Instead of considering the estimation practice itself, let’s take a closer look at how teams typically fail with all estimation techniques – and then address the commonality instead.

Choose any single technique out there.  Whether it is relative estimation or anything else, there is a really good chance it is not just marketing fluff or bullshit.  In fact, there is a really good chance that some really smart effective people used it successfully and have probably helped others use it successfully also.

So what gives?  Why were these techniques successful in some places and unsuccessful in others?  Well, there could have been many reasons, here are some of the most common ones:

  • The original context was different, and it needs tweeking for the current context,
  • The technique was modified because it didn’t “fit” into our context, instead of trying to take the (usually negative feedback) and change the way we work,
  • We weren’t very disciplined in using it, because it was too hard, (check out We tried baseball but it didn’t work)
  • There were significant failures, and instead of taking that as a sign of the method giving us feedback, we took it as a sign of the method failing,
  • etc…

So let’s get back to yes, these methods actually work.  What I’ve found, again and again, when it comes to estimation, is that we are not able to effectively manage our agreements around how we will estimate and manage those estimates together.  We are not able to handle failures when they happen.  We are not able to confront issues when they arise.  We are not able to be disciplined in what we do.

These methods, like any methods, can be seen as agreements made amongst team members about how they will work together.  So if estimates are always low, then perhaps we need to look at our agreements; especially those we have broken.  And, perhaps, there is a reason that we are constantly giving low estimates.  Here are some of the ways some of the invisible impediments get in the way:

  • Safety:  Perhaps the #1 culprit when it comes to estimates.  If I don’t feel safe giving what I *really* believe something will take then you won’t get a good estimate from me.  If I don’t feel safe calling out an unreasonable estimate early – then there will be a problem.  And, perhaps the most common instance of all, if I don’t feel safe to say “I was wrong, I need more time” early on – then I’ll just soldier-on.
  • Respect:  Many times we don’t respect each other.  Take the common “Us vs. Them” mentality that is so prevalent in today’s business culture.  If the “Us” is managers, and the “Them” are developers, and we see them as incompetent, they will get that.  They will probably see us as being unreasonable and not able to understand the intricacies of software development. They will also act accordingly.
  • Ownership: Do we have a mentality of a whole team?  Do we have a shared task that we cannot complete alone?  Is our mindset that of “I own the results”?  If not, then it is all too easy to be in an obligation mindset and do estimates a year out because “you HAVE TO”.  And if you do that, then you disconnect from the results and can easily convince yourself “well they were asking for something unreasonable anyway, so I gave it to them although I KNEW it was the wrong thing to do”.
  • Intent: Why are we REALLY doing estimates?  Is it our intention to just get the managers off our backs?  Or, as managers, is our intention to hold people accountable (and even CYA?) if things go wrong even though we know estimates are a fiction?

So, if we are doing some sort of estimation method and it is not working, perhaps we need to look at the team dynamics.  Perhaps we need to look at how we work together as a team around our agreements.  And perhaps we need to look for some of those pesky invisible impediments and start on fixing them first – BEFORE we look at the estimation methods themselves.

 
Leave a comment

Posted by on December 16, 2013 in Culture, Organizations, Teams

 

Is It Safe?

20 Aug

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

Agile Adoption, Second Order Change, and Mindset

22 Jul

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?

17 Jun

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?

05 Jun

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

17 May

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