« Conference Prep| Main | Technology is Heroin »

Tell me What I Know

| | Comments (0)

Right now I've got about 16 teams that I am coaching to some degree. Some I attend weekly meetings. Some I watch the team emails. Some I attend showcases. Some I am helping get started and setting up a backlog.

As part of my coaching job, I also do daily stand-ups with the other coaches and listen in on how another 50 or so teams are doing with adopting Agile.

I've been doing this for a year or two.

So what lessons have I learned over that time?

  • Be careful of people who already know it - Over and over again, whenever somebody says something like "No problem here, chief, I've already got agile." I cringe. Whether you think you're agile or you think you understand why agile is the bane of software development, if you think you already know everything, you're not open to change.

    And it's the guys who know agile that are worse than the ones that know agile won't work. That's the crazy part. You'd think the anti-agile guys would be the big problem, but no, it doesn't work that way. Anti-agile guys? You can present them with information to show how most people start off thinking it's some kind of gimmick but over time figure out what the deal is.

    Pro-agile people who already know it? They're impossible. Agile is about always adapting, always learning, always changing to meet actual conditions. Really, if you think about it, it's something you do, not something you know. I'm not trying to sound like yoda here (Agile am I. Force you will use). Don't confuse being able to do the practices of agile with actually being agile. Working with these guys is like trying to describe color to a blind person. You can talk in generalities, but it's hard to get traction.

  • The biggest factor of team success is team members - This is a real kicker: I bet 90% of your team's performance is already decided when the team is formed. People are that critical. Good teams challenge everything and are always looking for shortcuts and ways to optimize process. Bad teams are order-takers and do everything according to a script. That's stuff that's part of the personalities of the team members. You just can't fix it with training.
  • It's not where you are, it's where you are going - Many teams get upset about outside constraints. The project is going to be waterfall. The Product Owner isn't available. There has to be a review cycle which takes six weeks.

    You never can help those things. What I look for in a truly agile-performing team is where they are going: what changes are they constantly making to work with constraints. Again, being agile means what things are you doing to increase velocity? Agile teams solve problems. Sometimes the real problems is all the constraints the organization puts on the team. In those cases, agile teams adapt, overcome. Can you cheat? Can you find a workaround? Can you shortcut a long review process with something else, perhaps a voting system? Where you are is luck. Where you're going is agile.

Those are the top three things I've picked up. Teams still get it all backwards, however. They'll talk about retros, or standups, or other rituals and miss the entire point of what they're supposed to be doing.

Things will change, however. It just takes time.

Leave a comment

About this Entry

This page contains a single entry by Daniel published on February 5, 2009 2:16 PM.

Conference Prep was the previous entry in this blog.

Technology is Heroin is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Powered by Movable Type 4.23-en
Daniel Markham