It’s amazing how the meaning of this simple word can dramatically change by how it’s written.   Agile (Big A) has structure and is comprised of set of disciplined practices designed to get results, whereas agile (little a) is simply ‘do-whatever’ with little or no discipline and structure.

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.

Related posts:

1. 4 Steps to an Agile Transformation I often find that people new to Agile have...

Related posts brought to you by Yet Another Related Posts Plugin.

I often find that people new to Agile have a tough time understanding that Agile processes are empirical and there really isn’t a one-size-fits-all model that will work for every organization.  Scrum, XP, Crystal, Lean and other Agile methods all have their practices that provide guidance and tools but none of them are going to tell you the recipe for success.

This is one of many reasons why hiring an Agile Coach is a good idea.  A good Agile Coach will practice what they preach and use these same methods to help with an Agile transformation.  If we are talking the talk, it’s probably a good idea to walk the walk.  For starters it shows you’re passionate about Agile and it proves you know the tools and how to apply them.  It’s also a great opportunity to lead by example.

There is responsibility and “do’s and don’ts” on the part of the coach and the organization to work together towards an Agile transformation.  Below are 4 simple steps with some tips that can serve as a guide for how to approach an Agile transformation.  Again, there is no one-size-fits-all approach but there are some basic fundamentals and common sense practices I have found useful that I wanted to share.

Understand: How do you know if you need a hammer for the job if you don’t understand the task in front of you?

Coach:

• understand why the organization wants/needs to adopt Agile practices
  • are they concerned about quality?
  • is their business in jeopardy and they fundamentally need to change how they operate?
  • are they simple tired of the status quo?
• understand the current state of the organization:
  • how the organization is structured?
  • where is the support for transforming to Agile?
  • what’s the skillset like?
• understand that the Agile transformation is about the organization, not you

Organization:

• understand that an Agile transformation is more about a culture change than an adoption of processes and tools
• understand that Agile is not a quick fix
• understand the an Agile transformation is costly and time-consuming
• understand that ALL levels of the organization need to be involved
• understand that you will not like some of the answers you get from your coach

Educate: This is important.  I find that often people just want the answer.  A good coach needs to educate the organization so they can apply that knowledge instead of giving them all the answers.

Coach:

• teach the 4 values
• teach the 12 principles
• conduct workshops that help the organization understand the meaning behind the values and principles
• make it fun
• Educate them on the use of the tools (both thinking and software tools) you plan to use based on your understanding obtained in step 1

Organization:

• be open to learning, don’t dismiss the education because “it won’t work here“
• reject the status quo,”look around, it doesn’t need to be this way” – Gerry Weinberg
• challenge and question the education, don’t simply accept everything the coach teaches, challenge those teachings to make them work in your environment.

Execute: Now the hard part.  Agile is easy, implementing Agile is very difficult.

Coach:

• start simple, you should understand how much of a shock the transformation will be, a simple approach may be best
• the organization will not always listen to you. You will serve the organization better if you can remain positive and objective
• collaborate with the team(s) and/or organization instead of giving them all the answers
• learn to ask powerful questions to help them relate the 4 values and principles to daily work
• refer back to the values and principles often, this helps drive the organization to think and apply these values and principles
• start internal user groups, blogs, wikis, get collaboration and discussion happening, spread Agile culture

Organization:

• remain optimistic, you will be frustrated at times but stick with it
• “embrace uncertainty ” – Jeff Patton
• expect to experience failure, but remember to learn from it
• it might sound crazy, but it just might work.  Give it a shot.

Reflect:  Use retrospectives extensively, and not just with the team(s).  Retrospectives will help the teams with daily ‘in the trenches‘ work and they will help management and executives inspect and adapt on their transformation plan.

Coach:

• this is a tough one, but be honest with yourself.  Are you the right coach for this organization? Do you need help?
• based on organization feedback, add new tools and practices as necessary to support these new learning opportunities
• help the organization learn how to improve in small increments

Organization

• try not to get overwhelmed, Agile tends to expose problems very quickly – use reflection to make small, incremental improvements and try to avoid the big-bang solution approach
• be honest with yourself, don’t ignore the problems that surface, attack them

Rinse and repeat often.  These 4 steps are cyclical.  Reflection leads to a greater understanding which leads to new learning opportunities that will likely require different tactics during execution.

Related posts:

1. A Week in the Life of An Agile Coach – Thursday 7:30am - I arrive at our head office early...

Related posts brought to you by Yet Another Related Posts Plugin.

One of my favourite scenes from Tombstone is when Ike Clanton says to Wyatt Earp, “Listen, Mr. Kansas Law Dog. Law don’t go around here. Savvy?”  After Wyatt replies that he’s retired, Ike reiterates “Yeah, that’s good, Mr. Law Dog, ’cause law don’t go around here.”

A common theme that has been emerging from the classes I’ve been delivering and conversations I’ve been having are along the lines of “wow, we need to change our culture” or “agile won’t work here because … <insert excuse>“  There seems to be a clear delineation between these 2 camps.

I blogged previously about the importance culture has with an Agile transformation and I make sure that I convey that to anyone I talk to that is new to Agile.

The first statement I usually use to combat this fear, uncertainty and doubt is the fact that there always must be a reason to transform to Agile.  Companies aren’t switching for the sake of being cool and hip, well if they are they have bigger problems, but instead they are switching because fundamentally, the way they are working is broken.

Transforming to Agile requires a deep organizational commitment and a fundamental shift in how companies operate and how departments and people interact with each other.

So underneath the skepticism and FUD, what’s the REAL problem?  What are people afraid of?  Here’s a brief summary of the top 3 excuses for why Agile don’t go ’round here:

1) We can’t have a SINGLE product owner, we need multi-level signoff and too many people are “the go to guy”

2) Agile won’t work here, everybody works on multiple projects at the same time.

3) Management tells us we HAVE TO launch with all these features on this date.

Hmm.  So what do we do?  Where’s the Agile checklist that allows us to fix these problems?  I’ve seen Scrum teams absolutely banging their heads against a wall trying to figure out why their fixed-date, fixed-scope projects either don’t make it or have terrible quality.  In this cas,e the ‘rapid de-scoping phase‘ happens in order to make the date but in that instance the damage is already done.  The teams inability to say no has rendered their yes useless, mis-trust ensues and the cycle repeats itself.

I’ve had this post brewing for a few weeks and decided to post it after our pilot team’s recent success and after reading Gil Broza’s great post entitled “so you think you’re Agile?”

While our topics do differ, the underlying tone is the same.  Organizations needs to understand what being Agile is.  They need to look to the manifesto, not to the Nokia Scrum test or a checklist.  They need to un-learn what has been instilled through so many years of the command and control approach.

AYE helped me change my approach from saying “here’s what you’re doing wrong and here’s the right things to do” to “what are you concerned about?  what are your challenges?  how can the knowledge and tools I have solve your problems”

Lately that approach is working much better and I find people who want help are more likely to accept help.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

I attended a great session on Agile vs Traditional last night with the Toronto Agile group and while there weren’t many traditional folks there, the session helped validate much of what I believe is the most important aspects of ‘becoming agile’.
The panel included Mishkin Bertieg, Scott Ambler, Colin Doyle, Orhan Kalayci and Winifred Menezes and you can see details and bios of these folks here.  Although the even was supposed to be a shootout between traditional vs agile methods, the discussions were skewed towards agile approaches.  Each panelist had the opportunity to comment or answer a question about traditional vs agile approaches in these categories:

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.

Related posts:

1. Agile Just Don’t Go ’round Here One of my favourite scenes from Tombstone is when...
2. The Agile Coach Manifesto The Agile Manifesto is the heart of soul of...
3. 4 Steps to an Agile Transformation I often find that people new to Agile have...

Related posts brought to you by Yet Another Related Posts Plugin.