RSS

Follow the Energy

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

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

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

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

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

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

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

 
Leave a comment

Posted by on January 12, 2014 in Uncategorized

 

Use the Product to Build the Team

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

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

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

– Thanks Tim and Ashley!

 
Leave a comment

Posted by on January 10, 2014 in Uncategorized

 

Tags:

How Do We Manage Changing Priorities?

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

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

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

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

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

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

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

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

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

 
1 Comment

Posted by on January 9, 2014 in Uncategorized

 

Tags: ,

Two Birds with One (Safety) Stone

We recently received a health bonus at Industrial Logic.  Each employee was given $500 to spend on his or her health with two conditions: a) we spend the money by the end of 2013, and b) we report back to the rest of the company on what we spent and why.

At first I was a bit skeptical.  I’m in my mid-forties and have been steadily getting out of shape over the past 5 years.  And I’ve got many failed experiences with diets and exercise programs, although I know it can be done.  More specifically, I had built a running habit that I kept for 15 years and used to have a much better diet – so I knew I could do it even though I have failed to do so over the past few years.

Also, I know what doesn’t work for me.  Gadgets don’t work – I’ve got many unused gadgets.  Gyms don’t work, I’m self-conscious at gyms and don’t really like taking the time to go to one far away.  Diets don’t work, I always yo-yo back.

So all the obvious routes have already been tried and didn’t work for me.  And I just don’t have the motivation or belief that trying the same thing again will work this time around.  So what can I do differently?

Well – I know that if I can build a habit – like the one that I broke with running – then it really becomes easy.  But how?

A bunch of internet searches and a cool TedX video later and I’ve got a plan that I’m working on for health and fitness.  Then I started thinking about all the great ways that this idea – of getting really good at building habits – can help us do a better job at helping our clients get the most out of our products and services.

At Industrial Logic, we’ve been working steadily on creating an Anzen culture – a culture of safety – for our clients and ourselves. One of those ways has been validated learning – i.e. making sure all of our offerings not only deliver valuable content, but result in observable behavior change.  Which is where all the habit work comes in – the best way we know to make behavior changes stick is to form a habit.  And by leveraging the latest in behavioral science, we can really make things safer – and better – for everyone.

 
2 Comments

Posted by on January 2, 2014 in Uncategorized

 

Inverting Traditional Approaches to Teaching TDD: A Ridiculously Small Step to Build the Habit

Recently I had a conversation with Ingmar van Dijk who is one of the most talented technical coaches out there, and we were discussing how we can do best for our clients in our testing and refactoring classes.  More specifically, we had agreed that most of our clients are not working on green-field codebases and although learning testing and refactoring skills is a good first step, it is not enough to really tackle the hard problems.

We were discussing how mastering TDD, and making it an everyday habit was a multi-month process for both of us from the moment we were introduced to it, until the time we had the skills and abilities to actually perform TDD on all our code.

And we agreed that this probably one of the major reasons that the technical practices like TDD and BDD are not as widespread in the community.  They are difficult and that impedes them “catching on”.

Ingmar had suggested the idea that we start with the skills needed for working with legacy code FIRST, and then perhaps go back to the intricacies of TDD and refactoring later.  It seems like putting the cart before the horse….   But after a couple of weeks away from the conversation I think he is right.

Think about it – one of the reasons we don’t build a habit is that we don’t have the ability to do TDD on all our code after we are introduced to it.  So it is hard to pick one regular trigger.  But what if we learned a few micro-skills that would allow us to work with existing code first.  And then AFTER we built the habit of writing (very simple) tests for our code before we touched anything, THEN we came back to honing our TDD skills.

This would mean, we would start with:

1) Breaking dependencies in existing code,

2) Creating characterization tests,

3) Build the code in a test-after method regularly.

Then, after the habit is built for testing all code that we work on, we go back to test-first development and refactoring and refine our skills?

 
3 Comments

Posted by on December 29, 2013 in Uncategorized

 

Tags: , ,

Test Driven Development and Habits

Habit-forming is my new (short-term?) obsession.  And I’m looking back at some of the practices in agile development and what I can learn from the habit=f(motivation, ability, trigger) equation.

Technical practices – test first development, refactoring, requirements driven development, etc…,  are some of the most valuable practices in our toolbox, yet, unfortunately are the least commonly practiced.  We all know that they are difficult – but is that enough to keep us from doing what we know to be the right thing to do?

The motivation is usually there to certain degrees.  In fact, looking back, the most successful teams are those in crisis and they have really serious motivation to help them go through the huge learning curve (i.e. ability in habit-speak).

And the triggers are pretty simple – write a test before you write code.  Write an acceptance test before you start the iteration.

The real problem here is the ability – it is a really high bar.  If we remember that ability needed and motivation required are proportional – then we need to bring the ability needed down so that you don’t need great motivation.  Here’s what we’ve tried so far:

  • immersion classes (in the early days of eXtreme Programming)
  • training classes
  • eLearning (such as Industrial Logic’s technical albums)
  • mentoring
  • coaching
  • pair programming
  • katas
  • etc…

But the fact is, those things reduced the hurdle, but evidence shows it is still too high.  So, I’ve been thinking, “what ridiculously small steps can we take to help people build the habit first?”.

And since I am currently writing in ridiculously small steps to build my own blogging habit, then I’m not going to worry too much that I don’t have the answer now.  But I think I have a really good question.  And I’ll let my subconscious work on it for a bit and blog ideas as they come up.

But please, if you think this is worthwhile – think along with me.  What ridiculously small steps can we take to make the technical practices habits with more teams and individuals?

 
Leave a comment

Posted by on December 27, 2013 in Uncategorized

 

Tags: , ,

An Experiment in Habit-Building

I have a theory that I want to test out and would like to invite you to come along for the ride.  I want to blog more regularly.  In fact, I want to create a habit of blogging – I have wanted to do such a thing for multiple years (maybe you have too?).

The theory is based on someone else’s theory on habit building: Habit = f(Motivation, Ability, Triggers).  What’s cool, is that Motivation and Ability are proportional.  That is, if you are trying to build a habit for doing something trivial, then you need very little motivation; all you really need is a trigger.

So, how do you do something trivial?  Take a ridiculously small step.  Ridiculously small is in meditating for 2 breaths, doing 2 pushups, or ….  Or writing 2 paragraphs and blogging them.  Just two paragraphs.  No reviews.  No agonizing on whether this is the right thing to say or how dumb I’ll look to the reader.

So here we go.  This is the first such blog.  And my trigger will be writing before I go to bed.  That’s it.

 
Leave a comment

Posted by on December 26, 2013 in Uncategorized

 

Tags: , ,

Estimates Are Always Low and Dates Are Not Met

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

 

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