The power of NO

Written today for a work situation... wanted to keep it around for myself- 

A random philosophical thought-

When we have more desires than our budget can handle, we know that some of those desires won’t be achieved. And if we strive to achieve all of them, we may cause none of them to be achieved (or none achieved well).

Budget is not just money, but also people, and time.

Every time we say “NO” to something, we are in fact protecting a “YES” we’ve said elsewhere.

The sooner we say no, the more we stay focused on the yes we promised, and the sooner we achieve that promise.

In this way… a NO insures a YES.

I wish we could build everything we dreamed of, document everything we knew someone might benefit from, and wow every customer contract that came our way, but…

As a a project manager, I want our teams to achieve success, deliver great things, meet their deadlines.

As a scrum master, I say no to things when I know the desire at hand puts something at higher priority at risk. If I suggest a “no”, ask me what the “yes” is that is happening instead!

Help make the higher priority happen sooner, and maybe the no will turn to a yes. Or maybe our knowledge of priorities needs to change (a great conversation!). Simply saying yes to everything and hoping it will happen though… that is a probable path to failure.

Why do I randomly share this here, today? Because after what will soon be 6 months in this great company, I want to help us do more, faster, with more quality… and I truly believe saying “NO” every now and then is one of our paths of getting there. I've suggested "no" a few times recently, and I wanted to share my motivation.

Sometimes we must shine a floodlight into the darkness to uncover what we are missing, but it is a laser that we need to imitate when driving our team focus. "No" can sometimes clear a path for this.

Product Owner vs. Product Manager

Great article, should really check it out...

"Product Managers must quickly adapt to the Agile methodology, or face becoming sidelined. It is critical to understand the relationship between traditional and new roles within a delivery organization, particularly between the Product Manager and the Product Owner."

Link: http://www.pragmaticmarketing.com//resources/the-mythical-product-owner?p=2

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.