French Fries! (important and fun team habits)

I work in a company that values work/life balance. This means that when people need to work from home for a good reason, they do. But this in turn means that they have to dial in for our standup and other meetings that day. Sometimes, it is hard to hear on the phone from home, especially when 3 people in the meeting room are looking at each other and talking over one another.

"FRENCH FRIES!"

Yeah, that would probably get your attention if someone yelled it out in the middle of a meeting, wouldn't it? Well, that's the phrase that the team created for our standup to state... "hey guys, you are making it impossible for me to be an equal member of this discussion; or even follow along". This is typically caused by people talking at the projector screen instead of the phone (too quiet), but it has other good uses also.

It's a silly phrase. It might seem unprofessional to some... but it's part of our culture. (Don't ask how we came up with the phrase, I honestly don't remember.)

My point?

Have fun in your team. Find ways to help the chemistry of the group work. Make sure people respect each other, and provide ways for them to communicate feedback in a constructive way.

The other day, a higher level manager yelled French Fries in a meeting where most people in the room hadn't heard it before (not people in our standup). It made me laugh because it shows that the idea is effective and is spreading.

Buy a Feature - How poker chips can help with planning

Today I ran an exercise some call the "Buy a Feature" game. It's a very simple but valuable approach to brainstorming an area and building a backlog.

We had an area of our system that we realized we had let lapse over the last few years. We'd focused so much on wringing profit out of the engine that we'd lost sight of the fact that our core feature had been left behind in comparison to our competitors. For the sake of not ticking off my employer, I'll not name the feature here.

Here's an overview of how we tackled the problem:

We collected the stakeholders together into a room. This included the CEO, those tech folks with the most insight and history of this area, and the representatives/advocates of the users of this feature. I facilitated.

• Step 1 - Collection - Everyone wrote ideas (features/stories/backlog items) on an index card. They read it aloud and put it on the table for everyone to see. We did this round robin until everyone felt they had made a good list of ideas to improve this area. It helped greatly that everyone came to the meeting with a list pre-authored.
• Step 2 - Refactoring - We took a moment to look at the list and group or break up items that overlapped. We wanted to insure that items were stand-alone. We also wanted to make sure that items that would be built together (because they had to be), were prioritized together.
• Step 3 - Buy a feature - I gave everyone in the room 10 poker chips (it was a list of about 25 items) and said they could put all the chips on one item, or each chip on a different item. They should "spend" their money as they saw value.
• Note: We could debate whether everyone's money was equal (example: the CEO's?) but you'll see in the following step that this didn't turn out to matter. The goal of this exercise was to get to consensus within one hour.
  
• Step 4 - Tally and Discuss - The features with zero chips were grouped and quickly confirmed as good ideas for a future release (not right now). The features with a large pile of chips were grouped, and the team agreed that they were not worth debating since it was easy to agree that they had to be built soon regardless of cost. This simple approach kept us from discussing any of the items (cost, design, etc) where we all easily agreed on the outcome. One of the big things I see when facilitating teams is that they spend time discussing the wrong things and never get to the tough stuff.
• Step 5 - Repeat - For all the items in the middle band of votes (they were all chip piles of 2-3), I gave out another 5 chips to each person and had them spend on only those. This provided the same outcome, but only on the middle set from the first round.
• Step 6 - Close - We got really lucky. I color-coded and sorted the list in an excel spreadsheet (documenting the meeting) and asked the team if they had issues with it or supported it. Amazingly, the group agreed that the list made complete sense. I proposed that this "mini-backlog" be a project, that the top band was in, the bottom band was out, and the middle band was scoped based on the estimate that came back from high level design. Again, the group agreed and we were done with our meeting in an hour.

So... in one hour we took a team of people and tackled this problem. We came out with a release 1 backlog for the project and knew exactly where to go next. I have to say it is the quickest we've done this. Normally we spend a lot of time discussing and we run out of time before we can prioritize and agree.

What was the one thing I'd do better next time? I'd have a different color poker chip for each person so that they could move chips around if they changed their mind. People couldn't remember where they had placed, so they couldn't easily move their chips... although this could be good and bad.

Have fun with it... the tactile/physical interaction from this definitely aided the exercise.

Agile 2010 Wrap-up

Unfortunately, I was only at Agile 2010 for Tuesday and Wednesday due to family obligations. But, I was able to catch up with a lot of people during that time and take in a few really good sessions. I also presented a session myself (see prior post) and I got some really positive feedback. Below are some of the notes I took from some of the sessions I attended.

Dave Thomas' keynote on Tuesday

• When you are certified, you are useless, you just now have the body of knowledge in your head but it takes 10-30 years to learn how to use it.
• Certification does not provide confidence... this is what craftsmanship can overcome.
• Practicing leads to sub-cognitive action and muscle memory.
• You have a QA team because you didn't care enough at the beginning.
• If you can't do it with an index card, then you can't do it with fancy tools.

Effective Questions for an Agile Coach by Arto Eskelinen and Sami Honkonen

• Coaches exist to create awareness and responsibility.
• Don't inflict advice, ask questions, invoke change
• Good coaching questions cause exploration (what, when, how much, how many), aim at a descriptive answer, avoid judgment (how, who, why), and avoid an unproductive state of mind
• When tackling problems, use the G.R.O.W. approach (Goal, Reality, Options, What to do)
• Goal - describe desired state, insure it is high enough of a bar, be positive, be meaningful (what's in it for me), be specific
• Reality - are assumptions tested, explore different angles, expose feelings
• Options - existing ideas stated, limitations challenged, "stupid" ideas discussed

Great quote from a session when a team member was distracted - "I'm sitting out for this because I'm in the middle of deploying software... for the president... no... the President of the United States... yeah, we're waiting for Barack to login and accept the deploy." Yeah, he was serious!

Another great quote - "worst level of management" defined as "far enough away they can't help, but close enough to interfere".

Hiring doesn't have to be Random by Rod and Arlo Belshee

• Hiring is the most permanent change you typically make in your organization
• It's expensive
• Candidates have skills (learned), traits (personality), and behaviors (reflections of traits).
• Focus on traits by interviewing for behaviors
• Behaviors are data points for proof of traits you want (they can lie and say they have certain traits, you need examples, the more specific, the more real)
• Best assessed by doing, have them code during interview process
• Before interviewing assess your team for what traits they have. Determine what is required for a new person to fit in, and what you are missing that you need to find in a new team member. (What do you value - must haves, what do you need - additive.)
  
• Focus less on skills, this can be taught.
• Avoid labels, these say more about the interviewer than the interviewee and can lead to legal issues.
• "If you missed it in college, I can train you on the job, if you missed it in kindergarten, not my problem"
• Your team is a system with behaviors within a context. You can modify that system.
• Add a reinforcing capability.
• Balance out an excessive trait.
• Fill in a missing trait.
• Put the interviewee at east so you can collect data. Gang/Panel interviews don't do this, they could destroy your data collection.
  
• Why isn't your team talking about and defining what the team needs in a new hire?

Arlo's story about problem solving (and measuring level of problem complexity):

• A one beer problem is when you and another person go to the bar and drink a beer and quickly uncover the solution.
• 2 beers may help.
• Sometimes, it may take up to 5 or 6.
• After 6, it is clear that you need a higher distillation level.
• Try whiskey, it requires you to pass it around and share it (problem solving included).
• After 6 shots of whiskey, if you haven't solved the problem as a group, it's clear that additional alcohol isn't going to provide the necessary clarity.
• Time to switch to narcotics!!!
• Wait, maybe that's a sign it should be left to the professionals...

It was a great conference, as always, maybe next year I can present again and stay for the whole week.

Agile 2010 Talk: Agile Transitions- Cannonball and Stealth Approaches Exposed/Compared

Description: You've discovered agile and are excited! You are a leader within your team or company. Your next question is "How do I ignite this fire and get agile to take root in my organization?" After experiencing two extreme opposite transitions, I will tell the story of these approaches along with their successes, failures, and lessons learned. One transition occurred in a regulated global 50 company including offshore teams which dove headfirst into Scrum and XP within 3 months. The second is a stealth transition in a small .com startup company that is still ongoing after 3 years.

Time: Wednesday, 11 August 2010, 11:00 - 12:00

I've finished my slides and just have to do a few practice runs. If you are interested in this topic, then I'd really love to have you in the audience! I'm going to set up the talk with an overview of the two company environments and how each affected the potential of an agile transition. I'll then tell both stories, and end with the lessons learned from both. I've put a lot of planning into this one, so it will definitely be one of my best talks yet!

It's coming! (Agile 2010)

You can find my presentation summary here.

Startups are agile by their nature?

Yesterday I had the privilege of presenting the topic of Agile to the portfolio of new companies being mentored by a company called DreamIt Ventures in center city Philadelphia. It's a great program, and I'm proud to have taken some time to support it. I'm sure that some of these smart folks will be successful.

The interesting thing I noticed when walking through their space was how they worked. Each "company" was a group of 2-4 people sitting around one table next to wipe boards filled with thoughts, requirements, plans, etc. The energy levels were high and everyone was focused on the short time they have together to ship this new product and form the foundation of a future company.

One of the disadvantages to selling the agile philosophy to this type of audience is that they aren't overcoming a legacy of problems. Instead of talking about the "downfalls of traditional management" and sucking them into the "wonders of agile", you have to focus on a completely different issue. Instead of saving them from their past, you are instead trying to save them from their future.

It's almost like startups are agile by their simple nature! And it's our job to point at the things they need to protect as they grow (team culture). We have to point at the guardrails they should put into place today before they are too large to recover (examples: focus on technical debt and backlog management). Their team behavior is such that they "just do stuff".

It's very similar to the environment I'm in now. It worked well under 30 people. But when my company grew to 60+, suddenly we needed some process. So, what does all this tell me? It tells me that it's time to start working on those slides for Agile 2010, because this is the exact topic I'll be talking about (Agile Transitions). See you then!

Update on me & 3 things that motivate people...

I know I don't blog much anymore, it's mostly due to my shift in technology and daily focus. Twitter, Facebook, and other realtime environments have become much more immersive ways for me to interact with people. Also, I'm more focused on action than talking/sharing now. I still share via Twitter, but I'm more active in coaching and evolving process at work, and I've picked up a few speaking engagements. A few months ago I did an Agile talk at a local PMI chapter, in a week I'm doing another in downtown Philly for a portfolio of startup companies sponsored by a mini-VC. In August, I have the privilege of speaking at Agile 2010 (I really need to get on those slides!). These are smaller audiences, but it helps me connect with people that I can interact with and provide something of value immediately. So, if you need something like that and are near Philly, feel free to contact me (kschlab [at] gmail [dot] com).

But I will still share great stuff when I see it! Below is a great video about motivating employees and the negative impact of cash incentives. This has been a recurring theme in the culture/team discussions within agile for years (Linda Rising, Diana Larsen, Mary Poppendieck all come to mind), but it's a good research driven summary. Check it out: