Career Kaizen #6 - 5 Agile Sayings to Empower Your Team's Success

This week we'll walk through some common sayings in agile and explore their meaning a bit.

Monday - The Wisdom of And

Even if you are an expert, you'll benefit from hearing
and getting input from others.

When I worked at BigVisible, one of their coach's conference themes was "The Wisdom of And." This is drawn from Jim Collins work when he talks about the wisdom of "and" and the tyranny of the "or". The point is that there are often more choices available to just either/or choices, sometimes called "sucker's choices" or "false polarity," if neither option in its entirety or alone gives everyone what they're wanting. For example, "Well, we can either go over budget to build X, or we can lose all our best customers to the competition." That's a fool's choice. There's something in the middle.

If a group is sitting around a table, the best option doesn't lie with one person. It more likely lies somewhere in the middle of the table. Even if you are an expert, you'll benefit from hearing and getting input from others.

To get more input from a quiet group, ask questions such as "Anything else on this to consider?" "Are there other options?" "Any unanswered questions?" "What are we overlooking?" "What assumptions does this depend on?" "Is there another approach?" "How could this fail?" "Let's get at least two options on the board for this issue."

And you can control difficult people by replying to their solution with, "I'm sure that's a great option, I just want to hear what others have to say." or "Yes, and I'd like to just gather additional information and input."

Homework: Practice replying to positions and opinions with "Yes, and…" instead of "Yes, but…"

Tuesday - Art of the Possible

We often think things are impossible, but in actuality are possible and likely take a lot of hard work and a long time.

For example, for many of you, running a marathon might seem impossible. It might be if it were this weekend, but if it were six months away, and you started getting up in the morning and lacing up the shoes...given enough time and effort, you could do it. And if you did, what a sesnse of accomplishment that would be. It's a big deal. That's why people put the sticker on the back of their cars with 26.2. They don't put stickers that say "I walked around the block today." That's no big deal.

Most anything important, that's of value, takes some investment of time and effort. And that journey is actually part of what changes you, grows your character, and gives you a story worth telling, a story that others want to hear.

Homework: Watch the amazing transformation of a man who commits to running the Boston marathon:

Wednesday - No one of us is as smart as all of us.

Scrum depends on team. If the team isn't all in, if they're not involved in estimating the work, collaborating with the Product Owner on what, why and options in the requirements, and if they're not committing to the work, then we are missing a lot of the magic. When it comes to ideas, options on approaches, the architecture and more, no one person has all the answers. No one person is as smart as everyone else put together. One person might have more knowledge in a particular area, but others can learn that, too.  I've been amazed at how many times the new person on the team has had the best idea.

The same is true for us. On our own personal journey, on our own goals or challenges, we'll always benefit from hearing ideas from others, getting feedback, hearing their stories. We're built for community. Help yourself by getting connected in the local or online agile communities or coaching circles.

Homework: Do a quick search for local meetings or meet-ups for agile, Scrum, project or product managers, lean start-up or business sector you're in, and do the same for groups on LinkedIn, Yahoo, Facebook and other social sites. See anything interesting?

Thursday - Create your own Reality

We need to empower our teams, our team members, and
ourselves that we can create the reality we want

When I worked at Rally, this was one of their core values and sayings. And they lived it. If you felt that you needed something to do your job, if you wanted to grow into another role, they supported you in creating that reality.

I see my wife doing something similar with our two younger kids. When they say, "I'm thirsty," she replies, "So what are you going to do about that?" When they say they can't get ready because they don't have their shoes, she answers with "You can solve that problem."

We need to empower our teams, team members and ourselves that we can create the reality we want, we can solve our problems. I'm often met with the opposite in companies, a response of "Management won't let us do ____," but when I ask if they have actually asked for it, it's usually "No, but they know this is a problem." A particular training exercise I do highlights this. I do the ball point game, and the vast majority of the time, the participants don't move around to where the spacing works best for them. They just accept the circumstances or constraints without even asking me.

Homework - Think of the team, a team member, or yourself, and ask "What if..." and see what comes.

Video Fridays - What's the simplest thing that will work?

Breaking down life into what moves it forward today, not what's the best, comprehensive solution. A little like the debt snowball or weighted short job first.

To look at the entirety of the mountain to be climbed may seem overwhelming, but there is truth both in the saying that the journey of a 1,000 miles begins with one step and that the joy is in the journey.

About the big challenge or goal in front of you, what's one part of it that you can do today? Even better, what's something on it that you can do before noon? You might say that that one thing isn't the most important or highest priority. True, but also perhaps not true. It is a priority in the sense that you getting a "less important" task done actually gets the motivation and confidence going to tackle, and succeed, at the big thing.

Often our risk aversion, all the unknowns, take us out of the game of tackling big and challenging goals. But the very fact that the goals are big and scary are what make them worth doing, noble even. And through that challenge of tackling what is too much for us, we are transformed from someone who could not, before, into someone who can, afterwards.

Homework: Watch the amazing transformation of a man with a broken neck learning to walk again.

Weekend Warrior
Check out the story at the beginning of Habit. Read up on Jim Collins "Big Hairy Audacious Goals" and Dave Ramsey's Debt Snowball.

Agile Worldview Quotes - Scattering Seeds

I just read in Mike Beedle and Ken Schwaber's Agile Software Development with Scrum that "Scrum represents a competing worldview when compared to the many other styles of software development or business organization." I've never heard the term "worldview" associated with anything in software development, but I fully agree.

Agile isn't just about how a team of developers builds something, it's reaches into the business - how the team works with the other departments, how the business must have a single voice and must prioritize requests.

Something I've found useful is to include in all of my email random quotes I've saved which reflect this worldview. The program I use is Qliner Quotes, and its free.

Here is a sample of some of the quotes:

I'm going to make mistakes, but I've got to be able to look myself in the mirror and say to myself that I believed in that decision and mistakes are okay. And once I make those mistakes I can adapt and change. - Frank Addante interview on Venture Voice

Companies with the most values based critiques of their industries often turn out to be the savviest and most aggressive competitors. - Taylor and LaBarre, Mavericks at Work

Saying smart things and giving smart answers are important. Learning to listen to others and to ask smart questions is more important.  - Bob Sutton, Professor of Management Science at Stanford University

Core values are not something people "buy in" to. Executives often ask me, "How do we get people to share our core values?" You don't. Instead, the task is to find people who are already predisposed to sharing your core values. You must attract and then retain these people and let those who aren't predisposed to sharing your core values go elsewhere. - Jim Collins, Good to Great

Courage in Scrum isn't a visible, tangible thing. It is not some kind or romantic heroism. Instead, it is having the guts, the determination, to do the best you can. It's the stubbornness not to give up, but to figure out how to meet commitments. This type of courage is gritty, not glorious. - Mike Beedle, Agile Software Development with Scrum

Harmony itself is good, I suppose, if it comes as a result of working through issues constantly and cycling through conflict. But if it comes only as a result of people holding back their opinions and honest concerns, then it's a bad thing.  - Patrick Lencioni, Five Dysfunctions of a Team

When I'm building a team, I look for people who love to win. If I can't find those, I look for people who hate to lose. I want people around me who have passion. - Mark Beeson

A good plan violently executed now is better than a perfect plan executed next week. - General George S. Patton

Excellent firms don't believe in excellence, only in constant improvement and constant change. - Tom Peters

A manager must be able to do four activities extremely well: select a person, set expectations, motivate the person, develop the person. The manager role is the catalyst role. - Marcus Buckingham and Curt W. Coffman, First Break All the Rules

In the world according to great managers, the employee is the star.  The manager is the agent.  And, as in the world of performing arts, the agent expects a great deal from his stars. - Marcus Buckingham and Curt W. Coffman, First Break All the Rules

Are you going to take the risk to be different? Because no one is drawn to ordinary or average. And if you're willing to be different, be warned. Leaders are always controversial. Followers fit in. - T.D. Jakes

To succeed, a project relies on information from very different people: on one side are customers; on the other side is the technical team. If either side dominates these communications, the project loses. - Mike Cohn

A key role servant leaders often play is facilitating necessary changes. As a result, it's imperative that these leaders recognize there are four levels of change that vary in degrees of difficulty and time: knowledge, attitudes, behaviors and organizational change. The last one is the most difficult, because now you're attempting to influence the knowledge, attitudes and behaviors of multiple people. - Ken Blanchard

"The record for successful software projects is dismal indeed, but there's a new kid on the block: agile programming. Agile principles include flexibility, teamwork, trust, and reflection. But sadly, these environments are few and far between." - CIO.com

Do We Need to Manage People?

Going through Good to Great again, and was struck by Jim Collin's statement that the best companies hire self-disciplined people who don't need to be managed, and the leadership manages the system, not the people.

One of Scrum's principles is that the teams are self-managing. But I can see now that that principle depends on having the right people on the team – disciplined people. Just because I'm running scrum doesn't mean that someone on the team who wasn't previously self-managing or disciplined suddenly becomes disciplined. The opportunity is there for them, and hopefully peers around them to model after, but the brutal facts might be that there are team members who will never become self-managing, self-disciplined. Perhaps the team manages these people off their team, but if the team and process doesn't gel immediately (average of several sprints before typically gelled and consistent), then it is likely the ScrumMaster may be the first to deal with whether a person is right for the team.

The Architecture and Technology Council

Upon review, I found a fair number of our software projects over the last year came in late, over budget or failed for reasons that attention to architecture could have prevented. We have been unable until recently to get approval for Architects as a position. Even now, we only have one and he is on the smallest development team and so has limited sphere of influence.

So, how to address this gap? Build an Architecture and Technology Council. This council will have one representative from each of our development teams. I can see several benefits to having this council.

Culture: the existence alone of a council brings attention, discussion and, likely, validation that architecture and technology is of significant importance to the success of our projects. More dialogs will open up between technical, project and business teams. The business will see a significant expression of concern for IT's goal for effectiveness and adding value. Project stakeholders and key players might pause to consider if they are taking into consideration concerns published by this council whose focus is project success.

People: the mere existence of a council raises the bar. Council members are acting on the belief that they can make a difference, that we can be change agents. Other IT workers see an example of leadership that is difficult to write off as positional, political or purely based on length of service because these members are selected by their peers. The council is encouraging because shows an avenue of personal and career growth where the technical worker doesn't have to give up their technical role for a management role.

Process: we begin finding a way to address the issues we all agree are issues. The existence of the council gives a moment to confront our classic mistakes, examine our processes and review opportunities for best practices.

The road ahead is not that clear to me at this moment. I think the Council should regularly go through a lessons-learned dissection of a failed or flawed project from the past. I think we should come up with a suggestion for a technology and architecture road map for our organization that addresses their strategy (platform, tools, languages, architecture). From a process view, we should determine where and how checks are executed to prevent IT from doing something to repeat a mistake when we have learned the lesson. These process checks should also keep us from diverging from the road map.