I managed to go to a few sessions and spent most of the time in the hallways and Coach’s Corner. I love talking to people to see how they’ve implemented Agile, what challenges they’ve had and how they over-come them. I was super-excited to finally meet Lisa Crispin as we have been trading tweets for the last year or so!

My boss asked me yesterday what my one take-away was. After the first day attending Lisa Crispin and Janet Gregory’s session titled ‘Yeehaw, we’re Agile testers, now what?‘ and David Hussman’s and Tim McCoy’s session titled ‘Integrated Product Development‘, my takeaway was clear.

Culture is important.

Let me explain. When I was new to Agile, I attended a local event a couple of years ago the panel at the meetup were unanimous in their opinion that companies with the right culture can really leverage the benefits of Agile. Lisa and Janet’s session, while on the testing track, were about the effects poor culture and structures have on testing outcomes. An example they used was a discussion around issues attendees had with “QA keeping up”. The discussion at my table was with people in larger companies (although I’ve seen the same effect in smaller ones) and they had similar problems:

Given the discussion at my table it was clear there were severe system related problems contributing to this outcome:

• whole team doesn’t participate in planning – a ‘lead’ and/or ‘managers’ plan the sprint and hand it over to the ‘team’.  The reasons at the table were because “it’s a waste of time to have the whole team in planning, they should be doing real work”.  Oh that’s a beauty, I’ve seen that in every organization I’ve worked in.  That’s called the 100% Utilization Trap.
• The testers are 9 timezones away because it’s cheaper to hire point/click testers offshore
• Organizational structure that prevents cross-functional team creation and optimization (IE: functional silos with different objectives and purpose.  The job of development is to push changes out, the job of QA is to be a ‘gate’ to those changes and the job of IT is to prevent anything from changing)

I could go on, but I think that frames the problem(s) nicely.  So you are left with what I consider ‘Agile Adoption‘ and not ‘Agile Transformation‘ or  ’Tactical Agile‘ (Thx Michael Spayd for the definition).  In my session I talked about how your organization size, culture, structures and people affect your Agile implementation.  Organizations with more rigid process/politics and top-down pushed initiatives will not understand Agile values and principles.   When you hear people in the Agile community talk about organizations  that “don’t get it” I will bet this is the type of organization they’re referring to.  You’ll hear managers in these organizations say things like “we can’t just have people do whatever they want” or “that can’t possibly work here” or “we can’t do that because…”    These organizations also tend to have strong functional silos and people are more concerned with their title than delivering value.  One person at the session had actually removed all titles and people were considered ‘team members’.

Agile Adoption may be more suitable in this case because Agile may be seen as a set of processes and practices and not a mindset.  On the flip side, Agile Transformation is more about evolving a new mindset that is based on Agile values and principles.  I have another post brewing about that since it was the gist of my session.

If you’re interested in learning more about culture, check out The Re-Engineering Alternative by William Schneider…after finishing reading my post by the way.

David and Tim’s session on Integrated Product Management was a bit more subtle.  My takeaway from that was “Product Driven Outcomes over Process Driven Outcomes“.   Again this speaks to culture.  Process driven outcomes generally follow a pattern where you are ready to release and there’s no technical reason for not releasing other than you can’t figure out how to push it through your process.  That’s just an example.  I’ve experienced the joy of working in a product driven outcome focused team twice in my career, the energy and culture is drastically different than companies I’ve worked in that follow a process driven outcome process.

That may be confusing, here’s a better explanation.  Organizations that want to know ‘how Agile they are’ or how closely they are following Scrum likely have a more process driven approach because of the structures in place (hierarchy, functional silos etc).  These structures have been created by management and they are extremely hard to change because these structures have been setup to enforce the behaviour you’re getting.  From my experience, organizations tend to put more structures in place to try and circumvent the poor outcomes they’re getting as a result of creating these structures in the first place.

Never was this more clear than when I was talking to a fellow who was asking me how they could start using Agile, in particular Scrum, in their organization.  You can read the details here and I can tell you that his department was one that “got it”.  They are actually leveraging the benefits of Kanban and have a ‘Kaizen’ (continuous improvement) mentality.  Of course the mechanics needed some work, but they really seemed to understand The Agile Mindset based on what he described.

To make a long story short when I hear phrases like “one Agile size doesn’t fit all” and “agile is hard“, I don’t find them helpful.  It took me years to start to begin understanding why it’s hard and with each step a new door of learning opens. It’s exhilarating and depressing all at the same time!  There are so many factors that help shape what you think Agile is and how you can incorporate Agile into your organization.  Everything from the type of business you are, what types of products or services you offer, your size, culture, people, state of technology and more.  Once you can learn how to understand your organization, you’ll be in much better shape to figure out how to shape your path to more successful outcomes whether it be via Transformation or Adoption.

As have many others, I’ve seen different interpretations of what Agile means to different people in different environments.   From my experience, people generally consider Agile to be a ‘state of mind’, a particular practice or a set of practices.  I worked with a team in the past that considered themselves to be ‘very Agile’.  They were Agile enough to have a 4 day sprint after a 2 week sprint because all the work couldn’t get done in time.   I’ve worked with teams that had development and testing sprints.  I’ve worked with teams that had programmers that would account for re-working bad code in any story that was going to require changes in those areas.

Does that describe what Agile is?

I dunno.

The interesting part of those 3 stories is that the environments and culture created those versions of Agile, for the lack of a better phrase.  The 1st team that couldn’t seem to finish work in any sprint thought they were really Agile.  They thought this because there was no impact to missing the sprint commitment.  It didn’t really matter when the work was done or when it was released.  Using ‘sprints’ was just a way to break the work into 2 week chunks.  I’d call that iterative, not Agile.

The 2nd team I mentioned was in a larger company with very strong functional silos that were stronger than the team itself.  Some call that ‘mini waterfall’.  I don’t know what I’d call it other than that was the best these guys could do at that particular time.

The last team I mentioned was one of the best teams I ever worked with.  They all got along well, they all understood the application from a technical perspective and a user perspective and most importantly, they gave a damn.  They were a passionate group of people who challenged each other and just liked doing what they were doing despite the constraints they had as a result of their environment.

So is Agile a state of mind?  A single practice? A set of practices?  A couple of years ago I wrote a post about how I learned organization culture is the most important aspect of becoming Agile.  That seems to still ring true for me.

To me, Agile is like the old Lexus slogan from the 90′s.  ”The Relentless Pursuit of Perfection”.  I went to the Toronto Agile open space this past weekend.  That’s what Agile is all about.  People giving up their free time and time with family and friends to share ideas and learn about something.  There’s something special about these people.  There’s something intrinsic that drives these people to be better.

You can’t package that up and install it into an organization.  You can, however, package up and install a set of tools and practices into an organization.

My Agile is the former, yours may be the latter.  And that’s ok.  Just be aware of what you and your organization is capable of and choose your Agile adoption path to align with your culture and values.

Technically I’m on vacation and since I don’t really consider what I do a ‘job‘ (read: I love what I do), I’ve been catching up on email, forums and other conversations on Linked In.

Is the Agile community sending the wrong message?  Do people just not get it? Why does it seem there is this overwhelming need for something to give the gold stamp?  Are Agile values and principles at odds with fundamentally how the humans behave?

Dramatic?  Maybe.

From metrics to methodology, what seems to get lost is doing the right thing or doing what’s necessary for a project/product to succeed.  Reflecting back on previous lives of being “in charge“  I don’t know how many times I’ve either talked out of my, ahem… or flat out asked the team what they think we need to do in order to be successful.  It hasn’t always worked of course but I’ve worked with some great folks who could take the data presented to them and do what they felt was the right thing at the time.

Stakeholders, project sponsors and customers really don’t give a shit if you’re using XP or Scrum or Waterfall or Shabadoo Methodology (that one is mine, TM pending…), they want results.  Whether the goal is project success, more money or whatever, however you get there doesn’t matter.  Chances are the next situation will be different so doing the same thing again probably won’t work.

This has been a source of confusion and frustration for me a few times with clients, but I think there comes a time when you work for a boss or organization that seems to get it.  Sometimes you find a boss or leader who is very much a catalyst, somebody with that “it” factor.  Somebody that knows the direction of organization whether is be selling off the company so we all get rich or somebody who understands the market and is trying to blow a vertical wide open.   I feel lucky enough having experienced this rare phenomenon  twice and whatever the goal was in those situations, it was loud and clear.

Strong leadership and a purpose seem to drive how we get results, not a process or methodology.   So what’s the point? Am I just rambling on or what?  The point is, the manifesto was created for a reason.  Use it as a guide, not the rule.  Sometimes you need less rules and process, sometimes you need the reverse.  At the end of the day, people are complex.  Teams are complex.  Throw them into another system (read: the organization) and the waters get even muddier.

That’s why I love what I do.  Each situation is unique, each challenge is different and I really dig that.

Experiment. Fail.  Learn, move on and get better next time around. That is what “being Agile” is all about.

There is no magic formula or checklist to make an Agile adoption successful.   It’s up to how willing the individuals are to accept help from a coach or how open they are to getting out of their comfort zone to improve on something that isn’t working.  Class after class I get bombarded with questions that range from how QA integrates with an Agile team to “how does Agile tell you to deal with the expense of buying a developer a laptop?”. (yes, that was a REAL question I was asked once).

Esther Derby posted a few months ago about 5 reasons to hire an Agile Coach which leads me to ask what actually makes a coach successful?  What makes a coach worthy of self-labeling himself a coach in the first place?  These are the top 3 attributes I consider to be the most important:

1) Self-less:  A coach must care about the team (and organization) and morally and ethically do what is right.   A good coach must possess the desire to work their way out of a job for the greater good of the organization that has invested time, money and most importantly trust in the coach’s abilities.  Now in the real world I am quite sure there are some folks who want to extend the gig as long as possible for security or other selfish reasons, but IMO that’s not the point.  If you are trying to teach and organization how to build trust, that lesson starts with the coach.

2) Honesty:  A good coach must be clear that the road may (and mostly likely will) get rough and there is a chance adopting Agile just will not work if the organization doesn’t want to change.    You can say “honesty is the best policy”  is a rally-cry or fluffy sounding but it rings true.  If you set the expectation that you will be honest regardless of how painful that honesty may be sometimes, a coach will stand to earn the respect and trust of the organization which is a first step towards having that spread throughout the rest of the organization.

3) Guide, Not Dictate:  Ok, so this isn’t so much an attribute phrased like the other two, but it’s important nonetheless.  As I mentioned at the start of the post, lotsa folks want the “how” without wanting to think about it first.  It’s important a coach help the organization/team/person get to the right answer for their situation.   An organization needs to learn how to becoming a learning organization and the best way to accomplish that, IMO, is to use the tools, knowledge and frameworks to help people find the answer that works.   If teams or individuals are making real attempts and showing true desire to adopt Agile practices, give them the freedom to apply what you have taught them.  Let them experiment and maybe they’ll fail, but if they have the desire and motivation, they will learn and improve.

I’ve always bought into the thought that skill and knowledge is never a problem.  Skills can be taught and knowledge can be obtained.  Motivation and desire are the most important attributes that help organizations or individuals commit to constant improvement.

Agree?  Disagree?  What other attributes do you think make a coach successful?