Avoid false agreements and saying no with a yes. #TeamDeath


One of my favorite things about Agile is how it helps teams get committed toward a shared goal.  There are so many distractions and confusions, that we need to double down ways to help people get and then stay on the same page.  In some cases, it comes down to something as simple as word choice!

First, I feel like I need some explanation…

There comes a time in any disagreement when the team needs everyone to get on the same page even if they don’t agree.  As a rule, this should be a relatively small window (maybe 20 minutes max) because the team can defer issues by having a sprint long spike* or exploration story that collects more information to settle arguments down the road. 

Personal Experience Note: A team should NEVER spend much time arguing about the mid or long-term future!  It’s just not worth the time to convince someone that your vision is more compelling.  It’s more efficient to accept that there are MULTIPLE VALID FUTURES and that the team needs to watch to see which one(s) is  taking shape.  There is no need to be “right” about the future.

So, back to the fake agreement phrases that effective teams avoid.

#1 “Yes, but…”

This statement really means “Will you shut up already?  I don’t agree.”  The speaker says “yes” to acknowledge the first person has finished; however, it does not mean that they agree.  The confusing thing is the speaker typically does not even realize that they are sending you into a discussion death spiral. 

Anytime someone says “but” then they are disagreeing.   Just for fun, trying have discussions where people are not allowed to say but – it creates a whole new positive dynamic.

#2 “I don’t disagree”

This statement really means “You are full of shit and my opinion is more right.”  The speaker is trying to avoid addressing your points directly and refocus discussion on their opinion.  Agreement means that everyone believes the same thing.  There are many ways to not agree and only one way to agree.

This is one of my pet peeves because the speaker thinks they are rewarding you with some back-handed pat on the head.  In reality, they shutting your ideas down without validation or acknowledgement.

There are many such statements that waste team time and mask disagreement.  If you have some that bug you, please comment on this post and add to the dialog.  I’m sure that I won’t disagree with any of them!

* Spike stories are time bounded stories that have specific research or opinion deliverables.  They are intended to collect enough information that the team can take action and move forward.   Sometimes these are also called “time box” stories.

Agile Jumpstart – so you want to do agile?

A friend of mine is part of a business that wants to use Agile and he was asking me how to introduce agile to a team that has never used it before.

Even before asking, he’s already well on his way because his team wants to drive it as a business process not just for development (win #1), has a committed product owner (win #2) and likes the Agile Manifesto (win #3).

My advice surprised him because it was pretty simple and did not include ANY REQUIRED MEETINGS.  Here’s what I suggested:

  1. Have the product owner create a 1 page advertisement for the product that you are working on.
  2. Create a prioritized feature list (1 to N, no ties) that covers immediate and longer term items.
  3. Meet (ok, that’s a meeting) regularly to argue about the priority list as a team. I omitted that these would be sprints or iteration – the team will figure that out itself.

That’s it.  I also strongly recommend including retrospectives but I always recommend retros and he knows that part of the team building subterfuge that is Agile.

His primary question after this was how to schedule and estimate work.  My suggestion was to use a date driven release plan because it’s easiest to estimate billing if you use a calendar – cost = time * rate.   To make that work, you must give frequent demos to the customer so they are on board with the deliverables.    That’s the “easy” way.

If you want to predict when features will complete then use “story point” estimates.  Basically, each feature is estimated on an exponential scale (1,2, 4, 8, etc).  Big scary features will get big scary estimates.  When you are closer to starting, then you can decompose the big scary estimate into smaller units.  Ideally, you can decouple the work so that parts of the larger feature get done earlier and proven in the market.  It all ties back into your ranked list.

Splitting large features into smaller component may create a very useful interweaving where high value parts of features get done quickly where “bonus” components never get done.  Of course, this will drive engineers crazy because the don’t get to add those extras that create bloatware.

Overall, the goal of Agile is to create product the sells.  Now, that’s not too hard to understand is it?

Spoonful of Zietgiest

Do you want to have a winning team?  Bring a spoonful of zietgiest to your next meeting!

For me, Zietgiest is about how group dynamics influence how we feel about technology and make decisions.  It’s like meme, but I like Zeitgiest more because of its lower vowel ratio (Hirschfeld = 2:10).

Yesterday, my release team meeting had negative Zeitgiest.  Locally everyone was checking email while the remote speaker flipped through dense powerpoint slides.  It was like watching my divorced aunt’s family vacation slides via Webex.  We needed a spoonful of zietgiest!  That’s how I found myself explaining some of our challenges with the phrase “turd in the punchbowl” and getting people paying more attention to the real work.  A small positive spark and faked enthusiasm changed the momentum.  Yeah, it was fake at first and then become real zeitgiest when the other attendees picked up on the positive vibe.

The idea of seeding zietgiest is critical for everyone on teams.  It’s like the William James expression,feeling follows action: if you act happy then you’ll shake off the blues and start to feel happy.  Yes, this is 100% real.  The same applies for groups.  We can choose to ride or steer the zietgiests.

There’s no reason to endure low energy meetings when you can get out your spoon and stir things up.

Free Fall

Or elimination of pre-discussion bias

Learning Free Fall was the hardest of all the Agile comeuppance meted out to me.  Of course, it was not called free fall by the team teaching me about it.  Instead, it was the sinking feeling that I was always arguing the wrong side of every issue.  I was supposed to be the hot architect but my ideas kept getting shot down by the team.  They weren’t wrong per se, but they were not as good as the team could figure out during a discussion.

Meetings went like this:

Rob: “Hey guys, I’ve got this great idea that all of our SQL queries should leverage the zeitgeist feature because it will improve performance 25%.”

Team: “Um, yeah but zeitgeist requires us to perform green joins on the red data.”

Rob: “That’s a good point.  I thought that most of the data was yellow.”

Team: “That’s true.  What about meme queries?  They’re like zeitgeist but work for yellow and red data.”

Rob: “I really thought that zeitgeist was the way to go.  I think we can make that work if we limit the red data.”

Team: “Zeitgeist was a good suggestion, but we’ll go with meme.”

While my ideas helped the team, I could not get over the fact they did not go with my original idea.  Even worse, I would keep fighting for my idea after the team had obviously moved past it.  It slowed down decisions, made meeting more contentious, and caused our optometrist bills to skyrocket from excessive eye rolling.

All that changed when I learned how to trust my team and free fall during meetings.  Free falling (queue Tom Petty) is decoupling the problem from your idea of how it should be solved.  If you bring the problem to your team without a solution then you’ll get everyone’s brain working on ideas for the solution.  When I stopped being emotionally committed to the solution, I was much more ready to listen to other ideas.  More importantly, it was obvious to everyone else that I was more willing to listen so they were more willing to contribute and less interested in arguing.

When I started the discussion without having picked a solution, it was obvious to everyone that their ideas would be heard. 

We had more ideas, better discussion, and better results.  Generally, the team result was much better than my original idea and (bonus!) the team was always more willing to implement them after a free fall discussion.

Free fall takes some practice.  Find a buddy to help you stay on course by kicking you under the table when you’re reaching for your parachute.  Trust me – it’s like EPO for your team (and it’s legal!).