Are You Fighting Others or Creating New Options?

Is it fiercely competitive for you to be successful? Do others have to lose for you to win?

Below is my first blog post from 2004. I was a manager trying to get projects done. I had only glanced at agile. There was no iPhone yet. But some things haven't changed. Leadership Coach Tim Sanders is still great, The Leadership Summit is still awesome (I already bought my tickets for next year) and my views of how and why we should work have only deepened.

Be sure to get the free PDF chapter of Tim's new book at his site. Good stuff, easy read and it can change how you work and interact today. Also, there's a great interview of Tim by Dave Ramsey at the Entreleadership podcast site. At the podcast site are also interviews of Jim Collins, Patrick Lencioni, Dan Cathy, Steven Covey and more.

Recently I was reminded of Tim's lesson while reading Zappos! Delivering Happiness - A Path to Profits, Passion and Purpose (great book - now in audio and comic book form, too). The author wrote about playing the card games at Vegas, and how in life we have the ability to "create a new table" - to create opportunity. Be sure to check out the free Zappos! Culture book, too.

-----------------------------------------------------------------------------------------------------
At the 2004 Leadership Summit, Tim Sanders, Leadership Coach for Yahoo!, shared that we often don't have faith in our people or ourselves. There are those that have an attitude of 'scarcity', driven by fear of competition and filled with a sense of lack, what they don't have. It's the difference between social networking for other's benefit and networking for personal gain (which he said is actually prospecting or brokering).

He gave a good word picture by saying "It's the difference between being a gardener and a butcher." Tim said that at Yahoo!, if you are driven by scarcity (nay-sayer, doom and gloom), they will literally stamp a piece of paper with "Chicken Little" and stick it to your back, to be left there all day. Tim made me think how often I look to the negative side of a situation. In software development, we need to look at the possible concequences, but really only as risk analysis.

Even then, the downside should perhaps only be considered, noted, and then everyone should move forward on the project focussing on the upside. This doesn't mean be unrealistic, niave, or wear rose-colored glasses, it only means that we decide to concentrate our energy on the possible positive outcomes, encourage others, and be a contributor to the solution.

And an IT project, we could all agree, is much more than flowcharts and code.

6 Common Wrong Ways to do Scrum

There's a lot of differences in how people are doing Scrum. Some (not many) differences are with the core framework, and more are outside of it. I get very concerned with any changes with the core framework.

If a company decides they need:

•  a role of Technical Product Owner or Proxy Product Owner, or 
•  a five week sprint, or 
•  a services team creating only web services for other teams, or 
•  a design team doing UX work, or 
•  an architect team doing look-ahead work, 
•  or are writing stories that span two sprints because the testing process alone takes over a week.

I want to talk with them about why. Although they are breaking part of the core framework, to me it's less about breaking the rules and more about violating the principles underneath why Scrum works, and to help them see and understand that. It's more important that they understand why Scrum works rather than are they or are they not following the rules.

For example, a team has a Technical Product Owner because neither the Product Owner nor team members understand the system well enough to make educated decisions. Do they want the team members to have that knowledge? They usually say yes. Then that is the goal (and the issue), and not the Technical Product Owner role. Ask why the work-around is there, and then see if that root cause shouldn't really be the focus and problem to solve.

Growing up, I was trained to turn the wheels when parking on a hill. I didn't understand the importance of that until one day I drove up the hill to school and saw what used to be Karen's VW bug. She had parked it at the top and but the parking brake had slipped, and the car had rolled down the hill, gained momentum and flipped several times. Had the tires been turned, the car would have just bumped in the curb and then stopped. Rules and principles can be disregarded if there's not an understanding and respect of why they're there.

For variations I've seen outside the Scrum framework, I'm interested but not always concerned. For example:

•  the user story format
•  how non-functional requirements are handled
•  the estimation point sequence
•  whether estimation is done using planning poker or team estimation
•  whether the stories are broken down into tasks or not
•  how project work is approved
•  the role of the Project Manager, managers or architects

These topics become conversations about what works best for the team, and that's who I'm primarily listening to. If it works for them, they'll do better work, and that's a win for the business.

People Problems

Change is hard. Change is even harder in a large organization (or one that is old, or has a long average tenure or is successful in some way).

If you haven't experienced the difficulty, and time involved, and patience required, and politicking needed, you perhaps are blessed with a change-ready (or hungry) organization, or the changes haven't been very big or, truthfully, important.

For those that have experienced these challenges, I'd like to offer some recent, and completely untested, thoughts on what this is all about for those people who are required for, and likely resisting, the change agile is bringing about.

Story.

It's all about story. And character. And plot. And setting. Do you recall these terms from English class from high school or secondary school? What's really happening in their world?

I've used the phrase "The issue isn't the issue," when describing conflict management. That is, usually what we are arguing about isn't the problem that needs to be resolved. Ever feel like you logically addressed the point someone made, only to have them bring up yet another point? People with these issues can be a bit like Jell-o. You push down one issue, only to have another bulge out somewhere else. That's because there is something happening underneath the surface with this person, but it's either something they can't say or don't even realize they're saying.

One time I had to deal with a manager who walked out of the middle of a release planning meeting. She obviously didn't plan the morning thinking "I need to make sure my people are ready for the big release planning meeting. And if I don't like how it's going, I think I just I'll storm right out. I also need to meet with Joe and Sarah about the Christmas party decorations." Buuut, she also wasn't telling me, "I'm feeling insecure about my ability to lead my team through so much change, especially when I don't have a solid, working knowledge of it. I'm afraid of making bad decisions or looking foolish so visibly - in front of my team and on such a critical project. It didn't help that I oversold my ability to handle change, too." I don't think you'll see that kind of honesty and transparency unless you're at a team building offsite and just finished holding hands in a circle and singing Kumbaya.

But the truth is, they respond from how they feel much more than what they're thinking. And the better that we can listen and put together the puzzle pieces of the context in their world and from their perspective, the better that we can help each other. We don't need to always be right, but we should always be understood.

For more on this, checkout Crucial Conversations and Emotional IQ. And make sure you understand your personality type, too - either your strengths, Myers-Briggs, DiSC or the new Action and Influence behavioral and team profile by agile coach and trainer Peter Saddington