• organizational culture type
• type and temperament of the influential people or ‘change sponsor’
• flow of power throughout the organization

I am still learning about this and refining that theory.  Here’s a quick example, suppose you, as a change artist, are brought in to transform an organization to Agile.  Suppose this organization is a control culture (likes rules, process, stability, hierarchy and power) and the change sponsor (VP or Director or whoever brought in Agile, let’s call him Rick) has MBTI preferences that lend themselves to align with the attributes of a control culture.

Rick may be more likely to see ‘Agile’ as a set of processes and practices over a set of values and principles.  As a change artist, an Agile Adoption approach may make more sense.  ’Adoption’ and ‘Transformation’, IMO, are different.  Transformation is transforming an organization’s culture to build a learning culture or Agile mindset.  Adoption is adopting Agile practices and processes for perceived benefits that are (or at least seem) concrete.

As a change artist providing a less ‘fluffy’ and values/principles approach in favour of a more pragmatic approach of a list of processes and practices with benefits, possible outcomes and an implementation plan increase the odds of a successful change.

Today at AYE we had a small open space session and talked about MBTI and temperaments, how each temperament (SP, NT, SJ, NF) are affected by change using the Virginia Satir change model and how those temperaments may naturally fit into the different organizational cultures.  Susan Davis brought up using MBTI function pairings instead. (ST, SF, NT, NF).

First we talked about temperaments:

NT: Rationals, Visionaries – use logic to make decisions, have grand visions of what’s possible

SP: Artisans, trouble-shooters – like to solve problems as quick as possible to find the next problem to solve

NF: Idealist, catalyst – want to make sure everyone in the group is ok and feels included

SJ: Guardian, organizers, stabilizers - like rules and plans, certainty

Of course these are paraphrased, there is a great wealth of information about types and temperaments, these descriptions will suit the purpose of this post.

Next we related temperaments to the Virginia Satir change model.

NT: see the vision of the change and want to progress quickly through chaos.

SP: want to move through chaos as quickly as possible to get to the next problem and adapt quickly

NF: want to make sure everybody is ok while they move through chaos and want to get to the transforming idea so people will be ok.

SJ: may question the need to change and move back to the status quo

Each person will move through the change model at different rates and intensities.

Next we looked at Organizational Culture Types:

Control: rules, process, certainty, power, hierarchy.  ”we succeed by establishing and maintaining control”

Collaboration: teamwork, synergy, interaction.  ”we succeed by working together”

Cultivation: purpose/faith, creativity, let things evolve.  ”We succeed by growing people who fulfil our vision”

Competence: efficiency, craftsmanship, expertise.  ”We succeed by being the best”

For a fantastic description of culture types, check out Michael Sahota’s post here.

Next we talked about how some temperaments may have a more natural fit in certain cultures.  For example, NF’s may fit more naturally in a Cultivation Culture which emphasizes people and possibilities.  This culture is in direct conflict with a Control Culture and people who relate more to Control Cultures may have a hard time adjusting to a Cultivation Culture or they may not adapt at all.

What clicked for me was when Susan Davis brought up mapping MBTI function pairings with organizational culture types.  Quick side note on MBTI, my type is ISTP:

E/I: Introvert/Extrovert (Energy – Attitude)

N/S: Intuiting/Sensing (Data  - Function)

T/F: Thinking/Feeling (Decision – Function)

J/P: Judging/Perceiving (Action – Attitude)

My temperament is SP (Artisan).  My function pairing is ST.  I am a 50/50 split on N vs S so my temperament aligns well with the NT temperament.  I like solving problems, I like inflicting help, I like stuff that is awesome and in the end, it’ll all work out, whatever it is!  You can read more on function pairing here.

I will make a better diagram, here’s what we drew up.  On the Y axis of the organization culture type, “Reality Focus” for organizations aligns well with people with “S (sensing)” function while the “Possibility Focus” aligns well with “N (Intuiting)” function.  On the X-axis, “People Focus” aligns with “F (Feeling)” while “Company Focus” aligns with “T (Thinking)”.

I’m sure that sounds confusing.  Here’s what clicked, which is my theory.  If you as a change artist understand the culture of the organization and the teams (organizations will have sub-cultures on different teams, departments, social circles etc) and the MBTI preferences of the change sponsor and people in the organization, you may be able to come up with an Agile Adoption or Transformation plan that as a higher chance for success.

The reason I theorize that is solely based on experiences I’ve had and the theory of culture types and MBTI temperaments. In a control organization where the change sponsor has an ST function paring (SJ for example), selling him/her “Agile” as a set of values and principles and creating a learning culture or Agile mindset might not be as effective as selling “Agile” as a set of processes and practices with tangible benefits.

These pieces started coming together during Don Gray’s ‘Reading the River: Understanding Organizational Currents to Get You Where You Want to Go‘ session.  It helped me understand how to find leverage points and how to ‘speak the language’ of change in the right way to the right people.  If you have a deeper understanding of organizational currents, you can use the knowledge of that organizations culture and people to help take you through the change more effectively than swimming against the current by using “Agile Transformation” approaches when an “Agile Adoption” approach may be a better choice.

To wrap up, no culture is ‘better’ than another, same for type and temperament.  Agile-ists will often say “once size Agile doesn’t fit all” and I believe the combination of organizational currents, organizational culture and type/temperament of the influential people in the organization are the keys to figuring out how to work through a change more effectively.

Michael Sahota has written some fantastic posts about organization culture and I’m excited to read this book to expand my knowledge about culture.

What I’m more interested is how those cultures develop, after all, it’s the people in your organization that create your culture. Schneider describes 4 major culture types (Collaboration, Cultivation, Control and Competence):

To describe this digram, Cultivation culture focuses on forward-thinking and being more people focused whereas Control cultures focus on here and now and are more process oriented.  Michael’s post goes into more depth about explaining those cultures than I will in this post.

Taking a very simple systems example, you can have an organization with a Control culture and have teams within that system that have a Collaboration culture:

I was working for a large organization that exhibited the symptoms typical in a Control culture, however the team I was working on fit into the description of a Collaborative culture.   An organization or team’s culture is not absolute, that is, if your organization is a control culture that doesn’t mean it can’t exhibit attributes of another culture type.

I have a theory that cultures are developed based on the types and temperament (and obviously other factors) of the people in those cultures.  Here’s an example, the MBTI temperament “SJ” (sensing/judging) has preferences that fit well into a control culture.  ”SJ’s” don’t like change, they like process, control and predictability, in particular the ESTJ type.  As leaders, “SJ’s” like to be in control.  My theory is that if you have leaders with an “SJ” temperament you are more likely to develop a control culture and the harder it will be to adopt Agile.

Similar to cultures, a person’s MBTI preferences are just that.  Preferences.  It doesn’t mean an SJ isn’t able to collaborate, it means that an “SJ’s” natural preference is order, control and process.  ”SJ’s” are also very hard workers who expect a great deal of themselves and therefore the people that work under them which can further strengthen the control culture.  SJ’s rely on past experience for decision making and generally are not forward, or “out of the box” thinkers.  You can read more about SJ temperaments here.

Assuming there’s some merit to this theory and an organization identifies as control culture and the leaders are “SJ’s” with a strong “J” preference (that is, they exhibit control freak type behaviour), Agile is most likely going to be seen as a set of processes and tools.  That means your approach to Agile is likely going to be more about “adoption” and less about “transformation”.  If you’ve heard from a manager that “we can’t do that because our process says we can’t” you’ve likely got an SJ on your hands!

In this scenario, values and principles and building learning cultures are more likely to be resisted and some processes, such as Scrum, won’t fit into that culture.  Scrum is what I like to call a “black box” methodology.  ”The business” puts some stuff in one end (ok, the team pulls it in…) and some stuff happens and then some software comes out the back end.   What goes on in that black box isn’t generally known from the outside.  Cultivation and Collaboration cultures would “get the spirit” of Scrum and it  may  have a better chance to deliver successful results whereas Control cultures wouldn’t be able to manage the disruption it causes.

Even worse if, in this scenario, you are using Scrum and NOT seeing disruption, you’ve simply adapted an iterative based process that you’ve labelled Scrum.  This is what us folks in the community call “you don’t get it” syndrome.  That doesn’t mean you’re bad, it simply means your approach to Agile will be different.  You may be better off not using the “A” word at all.

I wanted to write this post for a couple of reasons. One, to put a stamp in time with my thoughts before reading the book so I can come back to this post and compare my assumptions with what I learned from the book, and two to prove to myself how smart I am if it turns out there is something that relates cultures and MBTI!  I’m not aware of any material that has tried to link the two of them.

In my next post, I’m going to talk about the opposite scenario which would be Cultivation culture and “SP” temperament.    The biggest difference between SJ and SP when it comes to Agile is the J vs P preference.  J’s are the planners that like control and process.  P’s (which I am a strong one) are open-minded, free-spirited, creative, love change (because it’s exciting), like to keep busy and are action oriented.  Whereas J’s want to plan and have defined processes for everything, P’s want to try shit out and adapt.  The latter is more conducive to “transformation”.

I’m still developing my thoughts about this and would love to hear your thoughts.  Understanding your organizations culture and the temperaments of the people on your team or department can give you a significant advantage to being successful with Agile.  Once you understand where you are, you’ll be in better shape to create a more effective path to adopting or transforming to Agile.

Look for another post next week.

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.

I’ll share the presentation as well, however I really stressed the importance of a creating a “no blame society” as when you are talking about problems, different people are going to have different perspectives which is going to influence their understanding of the problem and the causes of the problem.  A key statement I learned from Michael Sahota is that people are doing the best they can with the resources they have.

What was interesting was a sample “Cause Map” I created about a slip and fall accident where there were 2 causes:

1) Maintenance didn’t fix a leaky ceiling pipe (I didn’t go deeper into WHY maintenance didn’t fix it quick enough since this was just to get an understanding of what a cause map is.)

2) Cheap valves were used because a manager was given an incentive to reduce costs which was mandated by executives.  Of course that’s fictitious, if the mandate is to reduce cost would there really be an incentive put on top of it?

Our CEO made a slightly defensive comment about the root cause being an executive deciding to reduce costs since there are other ways to reduce cost they wouldn’t jeopardize people’s safety by using cheaper values.  I made a point to raise that observation in a safe way.  I said “I sensed a bit of defensiveness there, that seemed to hit home for you.”  He agreed and we used that a discussion point to re-enforce the value of creating a safe environment when you start to talk about real problems.

I asked the group to imagine the impact had this fictitious scenario been real and stressed that when we start applying this tool, it’s important to talk about what personal safety means and the importance of making it very clear we are here to solve problems and it WILL be un-comfortable.

The moral of the story is, if you’re a coach, manager, executive or team member, perspective on problems matter.   Put yourself in the shoes of the other person and try to understand their perception, that’ll go a long way into forgetting about what doesn’t matter (blame) and focus on what matters (fixing the problem).

The company I’m working for tracks time.  We track time because every year we go through a SRED (Scientific Research and Experimental Development) audit as we do a ton of experimental development.  This government program gives credits to businesses that meet the criteria and basically it’s a detailed tax audit.

Personally, I think time-tracking is useless in most cases.  There are much better and more effective ways to visualize work in your organization than relying on time-tracking.  Here’s an example.  Suppose you have a 1 full time customer support person working for you.  There’s lots of hearsay about the need to hire somebody.  So you decide to have them track their time.  I would assume the time-sheet probably looks like:

Week 1 – Joe – 40 hours

Week 2 – Joe – 40 Hours

Possibly there’s a breakdown by client or type of issue or something like that.  Do you need a new person when Joe records more than 40 hours?  What if Joe only works 39.5 hours, does his pay get docked?  Since Joe is a full-time support person why do his hours matter?  Shouldn’t he always be working 40 hours?  What if he’s up at night working, are you going to pay him overtime?

Again, you get what you measure.  Here’s a more effective alternative for time-tracking in this situation that might work better.

Week 1:

Opened Cases: 5

Closed Cases: 15

Joe is doing pretty good, although you could wonder why 15 cases were closed.  Was there a big backlog last week? Did Joe forget to close some cases and bulk closed a bunch?

Week 1:

Opened Cases: 15

Closed Cases: 5

Hmm, something wrong is happening here.  Is there a huge backlog?  Are these all new cases? Visualizing this data will give you insight into being able to ask the right questions.

That’s going to get you much more effective data than time-tracking will.  It’s a simple case of input vs output.  If your demand exceeds supply in customer support, you have a problem and the problem likely isn’t support related anyway.  The problem is likely somewhere else such as crappy software, bad infrastructure or other causes that customers call about.

I remember doing a test at a company I used to work for.  We looked at the flow of issues over time.  In a given month 85% of the issues closed were on maintenance and support.  15% of course on new features.  This company mandated time tracking as well so someone argued you can’t measure flow, features take more time than maintenance does.  So we ran a time-tracking report.  Same result.  Ok, similar, it was an 83/17 split.

So is time-tracking good or evil?  Depends, I suppose.

Good Things:

- tracking for tax purposes (in our case SRED)
- tracking for client project costs (also in our case)
- tracking for other regulatory purposes
- tracking for time and material projects

Bad Things:

- getting data about how well or not well your company is doing (support, development or otherwise)
- using it to keep tabs on your employees
- doing it because, well, you don’t really know but everybody else does right?

As with all things, common sense prevails.  Understand why you want to track time or whether there’s a more efficient way of getting the data you need.  Do be careful though, you will get what you measure.  Employees forced to track time without knowing why will get you a bunch of timesheets with “Joe – Week 1 – 40 hours” which is pretty much useless.

One of the characters in Berry Land (Orange) discovered a new game called Dandy-Ball. They had a ball stuffed with Dandelion seeds that they started hitting around.  Everybody loved it.

They realized they needed some rules so they created nets to keep score and made up rules as they went along.  This new game was incredibly popular so much of the work the characters used to do weren’t getting done anymore.   One of the characters, Blueberry asked Strawberry to help her clear out part of the field to make space for her dance recital.  Strawberry is like “the manager” in Berry Land, she asked Blueberry why she couldn’t use the space she normally uses.  ”Because Dandy-Ball is being played there now“, was Blueberry’s reply.

Strawberry decided that they needed some planning to schedule all the games and work in Berry Land.   Strawberry asked for volunteers and Orange offered to help but the other characters piped in and suggested Lemon do it because she was great at schedules.

Lemon created a schedule and they tried it out.  After the first 1 hour scheduled session was over, the group was staring at the alarm clock waiting for time to expire.  Strawberry asked them why and they said “Because the schedule says we have to wait until times up before we can start our game”

Strawberry so she went to see Lemon who was completely buried in paperwork and scrambling to get the schedule under control.  Strawberry said that having all the activities running for 1 hour didn’t work because some take longer than an hour and some don’t need a full hour.

Again Orange offered to help but the group decided to give Blueberry a shot at it since she was great at schedules.

Blueberry went off and created a really complex schedule and even did a presentation to the group.  She figured out a way to fill up 100% of the time to get all the activities done.  The group was confused by the schedule but decided to go ahead and try it.

The next day CHAOS ensued!  Nobody knew what activity needed to get done and all the characters were doing whatever activity they though needed to get done since they couldn’t understand the schedule.

The group went to Strawberry, the manager, to get her to create the schedule.  Strawberry suggests that Orange give it a try since she volunteered before but the group disagrees.   Orange was nervous and didn’t think she could do it either so Strawberry asked Orange to describe the work she does (Orange runs Berry Land’s general store).   Orange explained what she does to run the store and they all realize that she’d be great at creating a schedule for Berry Land’s activities.

Orange unveiled her plan and said that they can start with one activity and when it’s finished, move on to the next one.  She said she broke the work into small chunks, figured out on average how long the activities took to finish and then planned a season for Dandy-Ball.

The group loves the idea and Strawberry said “The only way to figure out what you can do well is to try it!”

We Need Process and Rules

The characters found something that provided Berry Land more value.  They put rules and process in place, blindly followed that process and then tried to fill up capacity to 100% to get everything done.  Eventually they ended up in complete chaos and nothing was getting done.

Does this sound familiar?  We need more process and control to get all the work done instead of focusing on what has the most value.

Strawberry is a Helluva Manager

Strawberry recognized early that Orange was motivated to figure out how to make it work but I supposed being a kid show if she just decided to let Orange do it in the first place the episode would have been over in 5 minutes.

Orange wasn’t sure she could do it and Strawberry encouraged and motivated her to help Orange understand she did have the skills and knowledge to be successful.   Throughout the episode, Strawberry sees the big picture, listens to the other characters, identifies what isn’t working and promotes change while leveraging the skills of her ‘workers’

She also recognizes the best way to learn is to try stuff out and see what happens.

Berry Land is Lean!

Orange discovers limiting work in progress gets stuff done.  She analyzes cycle time and figures out a ‘release plan’ that’s based on data and flow control.  She also breaks work into smaller pieces and recognizes Dandy-Ball is the most valuable so the activities in the release plan are planned in context of maximizing that value.

The Natural Evolution of Things

Berry Land went through a pretty substantial change model in this episode that is similar to what I see in organizations.  A more valuable project came along and instead of deciding to prioritize, they decided to try and figure out how to do all the regular work and pile more on top of it.

They focused on filling capacity instead of doing what is most valuable.

2 project managers (Lemon and Blueberry) “got fired” because their schedules didn’t work, Berry Land descended into chaos and they finally realized they couldn’t sustain the way they were operating.

In the end Strawberry had the leadership qualities that demonstrated how to solve problems Berry Land was facing and she displayed courage and patience with allowing the group to fail so they could realize how to fix their problems.  Strawberry demonstrated Agile’s values and principles and it helped Berry Land implement Lean.

Who’s the Strawberry in your organization?

I often find that people are confused by the differences.

Want to be Agile?

• educate yourself:  understand what it is and what the impacts will be to your organization
• educate yourself:  no, that isn’t a typo.  Get educated.
• hire a coach:  no, not because I am one, but because it’s really a good idea.
• listen to your coach: we don’t have hidden agendas.  We want progress.  You are the people doing all the hard work. A coach can help guide you there but they can’t change your culture, define your requirements, develop and test your software and automate your deployment process.
• do not fear failure: through failure comes learning.  The saying  “failure is not an option” should be rephrased to “failure is not optional”
• empower your teams and invest in people:  managers need to foster learning and lead by serving. Help your people.  Get them training and cultivate those relationships.
• attack your problems: Agile will create visibility.  Deal with it.
• resist temptation to panic:  Agile will not fail you.  You will fail Agile.
• be open to crazy ideas:  it might sound nuts to have a programmer and tester sit beside each other and work together, but it just might work.

Want to be agile?

• do it yourself:  don’t hire a coach or even better, hire one and ignore everything they say.  The benefit of this is that you can waste more money.
• use agile as an excuse:  are your processes too bloated? Spent too much time planning and only have a week to build a system that will probably take 6 months?  Call the project ‘agile’ so you can fast-track it and skip all the internal bureaucracy.  Then blame Agile (yes, big A) when it doesn’t work.
• strive for mediocrity: want crappy results only faster?  agile will get you there.
• don’t listen to the teams: duct-tape that 8 year old application together at all costs.  Time spent improving the code would be wasted when you can be adding more features.
• don’t plan: change priorities early and often to be as ‘nimble’ as possible.
• buy lots of expensive tools: the pricier the better.  If they cost a lot, they must be able to make you agile.
• invent solutions to problems that don’t exist:  force process onto the teams to make your life easier, even if it means longer time to market, increased cost and overhead.
• multi-task: if you have one high-performing team, take away team members to work on other projects at the same time.  Since they are high-performing, they will definitely be able to handle it.

Agile is comprised of a disciplined set of tools and practices.  And they work.  While there are subtle differences between Agile and agile on paper, the difference between becoming Agile vs becoming agile are the differences between great success and catastrophic failure.

1. Agile Evaluation: What do you expect to see when you first visit an agile organization?
2. Project size: Which approach works best based on the size of the project?
3. Estimating and Planning: Which approach is more accurate?
4. Requirements Management: Which approach is more effective?
5. IT Governance: which approach addresses this better?
6. Distributed Development: Which approach makes this easier?

Obviously the panelists’ opinions were skewed towards Agile having the ability to approach these more efficiently, but the key message overall was that even with using an Agile approach, culture, learning and constant improvement are the corner-stones to succeed with Agile.  To be successful in the areas being discussed, focus on building trust, relationships and make a commitment to improve.  They all really drove this point home in each topic.

Regardless of discipline, framework or methodology being used, it was pretty clear that corporate culture was the key.  There must be a mutual respect across the organization and within  teams and there must be a commitment to learning and constant improvement for Agile to really work.

I’ve always had the opinion that using Scrum, XP, Lean, Kanban or whatever you want to use is irrelevant if the culture doesn’t buy into the concept of what it really means to be Agile.  I’ve read many articles where people debate the use of Scrum vs Lean and nitpick about stuff that doesn’t matter such as “well, you can’t be Lean and use Scrum, they are 2 different approaches with different attributes.”

Who cares?

Yes, that’s right, who cares?

Being Agile is all about finding a better way to work and move forward as one team or organization, not worrying about whether or not you’ve followed the Scrum checklist (not that there is one, but we all know people love lists that tell them what to do).  This isn’t some hokey notion or religious argument, it’s common sense.  Give people the opportunity and trust them to do the right thing, and more often than not, they will.  Succeed as a team, fail as a team…but LEARN from the failure and move on.

This has been quoted many times by Agilistas, my apologies for not knowing the source to credit them, but the saying goes “It’s not my problem, the hole is in their side of the boat” This is the type of thinking that must change in order to be successful with Agile.

Now the challenge becomes, how do you help people adopt Agile culture?  Let me know what you think or drop me a line with how you’ve approached changing culture when adopting Agile.

Oh, and look for a follow-up on extremely short sprints for small teams, we learned quite a bit but I’ve been a bit swamped lately to follow-up.