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.

Uncle Bob (A.K.A Bob C. Martin) posted an interesting thought about his keynote from Agile 2008.   The idea was a metric for code quality as measured in “WTF’s per second”.  That is, during a code review, how many times you see code that makes you say “What the F***?”

I like that idea, but I don’t agree with the proposed 5th Agile Manifesto Statement “Craftsmanship over crap” or “Craftmanship over Execution”.  Like all Agile statements we don’t NOT value the item on the right, we just value what’s on the left more.

I’ve always thought that the underlying principal of Agile practices, particularly Scrum, already preach about quality software.  The goal is always potentially shippable and bug-free software so maybe it’s the optimist in me, but shouldn’t the programming methods used in Agile development (pair programming, TDD etc) already police against writing crap?

If developer A writes crap and then code reviews it with developer B, I would fully expect developer B to point out what’s wrong.  I don’t think anybody wants to churn out crap for the sake of getting something done and  I can only see lack of knowledge or experience being the culprit.  This lack of knowledge or experience should be able to be fixed through Agile processes.  If a team member is struggling, help them.  If a team member is knowingly churning out crap, try and help them or boot them off the team.

I don’t think we need to update the Agile Manifesto to state the obvious.

No related posts.

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