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 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.