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.

Career Kaizen #5 - 5 Days of Leadership

Monday - Level 5 Leadership

Leaders help team members
solve their own problems.

Most agree leadership is important, but there are many definitions out there. Are you a leader? Do you have leadership in you? The ScrumMaster role is often described as a servant leader, so it's worth some focused time on it.

One of the classic business books is Good to Great. In the book, Jim Collins talks about Level 5 Leadership, the highest of all and a level few CEO's attain. There are good metaphors that describe that type of leader.

First, these leaders look out the window to assign credit, and look in the mirror to assign blame. Always try to deflect to the team when someone looks at the results and says "You've done a great job leading the team," especially if it's in a public situation, like a meeting. There are many ways to do this, for example, "It's not me. It's the team. Anyone could have done it if they had a team like this," or "Thank you, but really, the team is the one responsible. They have really put in a lot of time, effort and heart into this, " or even just point to some specific positive aspect of the team (perhaps from one of their retros), "The team really feels that _______ has been the key ingredient to the success we've had."

Second, these leaders want to make clock-builders, not be time-tellers. Rather than always have the answer, or be quick to solve someone's problem, Level 5 Leaders help team members solve their own problems or find their own answers. This builds their own abilities, ownership of the solution, empowers self-organization and makes teams faster. Many times making a clock-builder can be started by responding to a question with "What do you think?" I've been surprised how many times they already have an idea, they're just looking for feedback, support, or political covering. You can answer with, "Well, try that out and let me know how it goes," and watch as the team begins to solve more and more of their own problems.

Homework: Ask yourself: Does it feel good to solve people's problems? To be needed? Or to be able to help? Is your value based in part on how critical you are for things to get done? Are you okay with them figuring out everything by themselves?

Tuesday, Common Team Needs

Marcus Buckingham said that the difference between management and leadership is that management looks at what is unique among people, and capitalizes on it, while leadership looks at what is common among people and capitalizes on that.

Knowing what the common concerns are, or addressing a common need, is important. Vision, a key leadership trait, is pointing to a common goal or destination that enables a group to rally around and towards that - a common goal or challenge as they struggle, fail, win and journey together.

Homework: Look at the common felt needs of employees compared to what management thinks they need. What do you think the top three for your team members are? List them in the next retro and have the team dot vote them.

Wednesday - Positional or Influential Leadership

The challenge, and the blessing, of leadership in the ScrumMaster role is that you do not have authority over the team. You can't tell them or force them to do anything. Yet, traditional, authoritative leadership is actually the lowest form of leadership. People aren't as likely to truly be following you as a positional leader (for example, a manager). They are doing what you say, whether they like it or not, because they have to. In those situations, they're not giving the positional leader their best, but only the minimum required. Just enough to not get in trouble or fired or noticed.

Having people listen to you, follow you, as a servant leader means you must learn and grow in the powerful area of influential leadership. Forming relationships, understanding their needs and concerns, fighting on their behalf, protecting them, taking hits for them.

Homework: Looking back over history, who do you admire? Any heroes or people that you respect the work they did, the impact they had, or the challenges that they overcame? If so, in what ways can you apply lessons from them for your life and work now? What would they tell you?

Thursday - People Development Wins Championships

You must develop team members to win championships

John Maxwell wrote a very popular book on leadership. A few quotes from him:
"You can't lead people without liking them."
"At one level, you focus on becoming a change agent - focusing on productivity."
"Productivity wins games. People development wins championships."
"Besides the obvious competence, effort and skill, leadership also depends on intentionality."
"To succeed as a leader, you must help others move forward."

Homework: Pick one of the quotes you like (or another quote from the web page), print it out large to post on your wall at work, and small to put on your bathroom mirror or car dashboard. Keep it in front of you for a week. Don't start your computer or end your day without looking at it (even better to say it to yourself) or start your car or brush your teeth without the same.

Video Fridays

Stanton Complex - face the brutal facts, but don't let go of hope. In 1965, Captain Stanton was shot down and in a POW camp in Vietnam. While others kept believing any day that they'd be released, the reality was they weren't. These people ended up giving up, or worse. Stanton was hopeful, but not unrealistically so, and faced the reality that, also, they may never be released.

On your team, in your company, it may look grim. It doesn't help to believe things will magically change based on nothing other than your wishful thinking. And yet, we have to hope and believe that there is a chance, a chance worth fighting for, that they someday could.

Always respond positively. Don't join others in their complaining. Focus on solutions - what can you change, what experiment, what can you ask for, that might help. If you're not sure, ask yourself, "Is this noble or excellent?"

Homework: Watch the video of Jim Collins (or listen to his audio clips), or Patrick Lencioni.

Weekend Warrior: Review all of Jim Collins Hedgehog Concept items. List out the five levels of leadership.

Would you like to receive Career Kaizen in your inbox?

Career Kaizen #4 - 5 Ways to Make Real Change Happen

Monday, It wasn't easy - I had to change a LOT

The challenges you face are what make you better

Difficult days are rewarding. The challenges you face are what make you better, more than what you were last week or last year.

Imagine that you are observing some amazing team, better than any you've ever been around. You ask the ScrumMaster, "Wow - how did you help them get to this place?". He replies, "Nothing, they were like this when I showed up." What kind of inspiration is that?

Yet, when you feel challenged, maybe even too much at times, these are exactly the points that push you into responding in new ways, trying things you haven't before, becoming someone, perhaps, that you weren't before. So when someone asks, "Wow - how did you help them get to this place?" you smile, laugh and say, "It wasn't easy - I had to change a LOT. This is where it started…" and they will be all ears.

Homework: Do your own speedboat exercise. Draw a boat on a sheet of paper (yes, really - drawing connects with a different part of your brain). Now, draw three or so anchors off the boat that are slowing you down. For each anchor, write three actions that might help with each area. Now, choose three, and either add them to your personal kanban board, or calendar them.

Tuesday, If Nothing Changes, Nothing Changes

Yes, you really can change. I've wanted to learn to play guitar for years. In fact, I have one. I've had it for 16 years. Up until several weeks ago, I hadn't played more than a song within any given season for at least 8 years. Maybe picked it up once in a month or two.

But now I've played it every day for weeks. I've caught up to where I was a decade ago and passed it. I've learned new songs and notes. I have callouses on my fingertips again. Not only am I playing, but my family is often joining in singing as they walk in and out of the room. Wonderful repercussions.

Why the change? It's something that I really wanted for a long time, so not a lack of desire. Well, it's habit. I added it to one of several daily check-off items on an app I use. Just wanting to flip it to green - done - has made me stop and do it. And now that I've gotten used to just finding a moment to do so, I'm finding more moments and connecting that decision with the reward of the feeling while I'm playing.

It may or may not work for you. It actually took me a couple of weeks, and some tweaking (I had to set a goal of having at least one day where I did ALL items on the check list). But, do something, and inspect and adapt. Because, if nothing changes, nothing changes.

Homework: If you have a smart phone, check out some of the habit-building apps. Start with one positive habit you'd like to build. If you don't have a smart phone, try an online version, or try adding it to your calendar or daily to-do's via Outlook or even good old paper.

Wednesday, Help the Elephant

What specifically needs to happen to turn the elephant?
What is an intermediate achievable turn for the elephant?

The elephant and the rider. You may already be familiar with the story. Elephants can be guided by a rider down a path, but if the elephant really wants to go somewhere, it's going to go there. Same with us and our desires and goals. We may want to go somewhere, but we're often taken somewhere else by the elephant - our emotions. I may want to lose weight, but on a stressful day, I'm much more likely to eat chocolate (true). Or I can want to go running in the morning, and so set the alarm, but once it goes off at 5:30 AM, I don't feel like getting up very much. It could be the same for wanting to speak, get into training, go back to school or a certification program.

Help turn one of your goals into a reality by helping the rider. Look for bright spots - times or situations that things did go well, or you did have some progress. What was happening in that? Script the critical moves - don't inundate yourself with too many choices. What, specifically, needs to happen? Point to the destination - is there an end goal that the habit lines up with or supports?

And help the elephant, too. Shrink the change by lowering the bar so that you can get some success. One habit I had was popping my knuckles. Rather than trying to go all day, my first goal was just not to do it before 10 AM. Then it was 1 PM. Now it is all day. Studies were done that showed that people were 40% more likely to return to a car wash if they were given a 10 punch card with two punches already done, versus an 8 punch card with none.

Homework: How can you help the rider? What are the critical moves to successfully achieve the task? How can you help the elephant? What is a small starter goal to incrementally move toward success?
Share your ideas in the comments below...

Thursday, The Growth Mindset, or the Fixed Mindset

People generally fall into one of those two categories. The fixed mindset believes that we have a certain amount of abilities and that if we do or don't do well at things - subjects, jobs, life, it's because we don't have what others have. If we did, we'd do well, naturally. The growth mindset believes that we can learn, grow and change in these.

Homework: Answer the questions:
1. People are born with a certain intelligence that stays fixed throughout life. True or False?
2. Choose one: Do you demonstrate your ability or increase your ability?
3. When you fail, what does it tell you?

Video Friday:

Watch the TEDx video The Power of Belief


Weekend Warrior:
Check out Linda Risings YouTube videos on the Agile Mindset


Watch Carol Dweck's Mindset video or check out the book or audio book.

Career Kaizen #3 - Your Culture

Monday - Your Cultural Context

Culture eats strategy for breakfast.
What is your company culture?

This week we'll be looking at your cultural context. A mentor once told me "People trump process, but politics trumps people", and for the business, "culture eats strategy for breakfast." So, what is your company culture? And what does that mean to you?

The technology innovation adoption curve is a model adapted by Geoffrey Moore that plots the relative number of people who fall across a continuum of their response to new technology. There are innovators, early adopters, early and late majority, and laggards.

This matters for you because agile is, in the same way, new. IT changes how many people in the organization work, aspects of their roles, what's expected of them, and even deeper and more importantly, it changes what's expected of people's mindsets and what the values are.

An agile survey showed that the number one reported problem with agile adoptions was management resistance.

Homework: Read up on the curve, plot where you are, where your team is and where you think your company is.

Tuesday - Lead with Vulnerability and Transparency

You are part of a team. Even more so with agile, we can't find our success outside of that. Like a relay race, you may claim a fast time for your segment, but if the baton is dropped, you still lose the race.

Patrick Lencioni wrote about what makes teams healthy, and what holds them back. The common problems are absence of trust, fear of conflict, lack of commitment, avoidance of accountability, and inattention to results. Many teams asking for help are stuck at the first two levels, so let's focus on how you can help with those.

To help with the absence of trust, first, lead with vulnerability and transparency. Tell them how you blew it (they usually already know anyways), when you were stressed or worried. Affirm them for what they do that you can't do so well. Be the first one to share, ask the difficult question or talk about the elephant in the room. Model transparency. Affirm them when they do it.

Second, look for conflict, don't avoid it. We should cultivate environments where it's okay to disagree, and passion is okay. No personal attacks, of course, but freedom to speak your mind and have opinions.

Homework: Look at the documents on Five Dysfunctions of a Team.

Wednesday - Get your Team's Perspective

What does the team think? Schedule a meeting, or include it in the next retrospective, to have them say what they think they have, both on the curve, and with dysfunctions.

Homework: Schedule the meeting (unless it will be part of the next retro) and review the documents with the team.

Thursday - The Change Agent

Healthy things grow. Growing things change.
Lead by embracing change.

How and why do people change? What motivates them? What motivates you?

There's a saying - healthy things grow, and growing things change. But we can't make people change. Just look at corrective institutions, rehabilitation centers or many marriages.

But we can lead by embracing, and living out, change. Although I may teach and coach about change, I'm surprised how often I'm actually resisting it. For each of us, this is true for many reasons, but the point is to be mindful that we all struggle with it, not just others. Is there a habit you haven't broken, a goal you haven't attained?

Two reasons that change is hard are emotion and habit.

Homework: Look at the summaries for Switch and Habit. Note three points or items that stuck out to you.

Friday - You, Your Team, and Your Response to Change

By now I hope you have some feel for both the culture around you, your team and your own response to change.

Homework: Watch these Switch and Habit videos on YouTube. 

Weekend Warrior: Do a force field analysis of what changes are supposedly wanted by the company and what is hindering them.

Learn from Project (and Life) Mistakes Using the 5 Whys

You don't have to be using Scrum to have regular lessons-learned sessions on your project. I think these meetings, called Retrospectives in Scrum, are more helpful when you've gone through the entire  Define-Build-Test-Acceptance cycle, but they were all too infrequent when at the end of my traditional projects.

When journaling this morning, I found myself doing the 5 Whys for root cause analysis on something that happened yesterday, and I thought it might make a good (although somewhat painful and embarrassing) example.

Problem: I went the wrong way on Interstate 10 yesterday and it changed my 1.5 hr drive (left early) to 3.5 hours. Why?

1. I didn't put the map directions on my phone to navigation mode. Why?
     A. I didn’t because the battery was too low. Why?
          1) It was low because I didn’t charge it at the client. Why?
               a. I didn’t charge it at the client because I didn’t have a charger in my backpack. Why?
                    I. I didn’t have one in my backpack because we don’t have a spare at home.

Solution: Buy one and keep it in the backpack for client use only.

How would this look on your project? Here's another real example.

Problem: Requirements keep changing (sorry if none of you can relate...). Why?

1. The team makes assumptions that are later found to be wrong. Why?

     A. The Product Owner doesn't put in enough detail. Why?

        1) He doesn't have much time since he's on the road visiting clients. 

Solution: Long term - Find another Product Owner who can dedicate more time. Short term - have a Business Analyst flag and clarify the product backlog item requirements that are thin. 

Although great for projects, these are also great for life (and when's the last time you took time out to work on your life?) Here's some for you to try:

1. I, or significant others, feel like my work-life balance is way out of balance.
2. I'm not motivated, much less inspired, with my current job and workplace.
3. My job/this project is too chaotic.
4. I don't feel like my team is close or acts like a real team (unity, group decisions, comfortable with each other, clear purpose). 
5. I/we keep repeating the same mistakes.
6. I don't feel that I'm growing in my career and/or personally.
7. I don't feel I've done anything significant (worth mentioning in my Christmas letter) this last year, and next year looks like it will be no different.

If some of those resonate with you, try the 5 Whys on them, and look at resources such as the Storyline conference, The War of Art, Drive, The Leadership Summit, Love Does, or your personality and strengths with Myers-Briggs (free), StrengthsFinder or Action & Influence. 

If you're a ScrumMaster and wanting to grow, I'll be having a something out soon that provides small, actionable steps, day by day. Reach out to me and stay posted. 

The Unanswered Offshore Question, Pt 2

So, how do you know if your offshore team is as productive on onshore, and therefore saving money (as is typically the primary reason for offshoring)?

Work from one backlog (combine backlogs if working from more than one). Without specifying which team would do which story, have both onshore and offshore teams participate in sizing, or estimating, from one larger pool of user stories. You may do it together, or start by doing a few together and the rest separately. In the end, sample enough of the stories that both teams agree on how many story points various stories are.

At or before the planning meeting(s), randomize the stories or alternate each team getting whatever story is the next one pulled. At the end of the planning meeting, you'll have an estimated amount of work for each team, which gives you an idea. At the end of the sprint, you'll know for sure. Even with various issues (no product owner, newer/smaller/etc team), you'll have a number.

If you can't have both teams estimate and pull work without upfront planning or designating due to resource, knowledge, or other silos or barriers, I think you have other problems that Scrum will fix (if you want it and let it).

Thanks for all the great feedback from the first offshore post (and all the spam comments for offshoring ;-)

The Unanswered Offshore Question

Student: "But how does agile work with offshore team members?"

Me: "Well, let's start by asking another question - 'Why are you offshoring?'"

Student: "It was a management initiative."

Me: "Why?"

Student: "To save money. The hourly rate is lower."

Me: "But agile depends on high team interaction and collaboration. This change in how work is done might have changed the economics of the decision. How do you measure how productive those offshore teams are? That is, how do you confirm that you are indeed saving money?"

Student: "Ummmm…I don't know."

I've asked this question dozens of times. Always the same answer.

When I am coaching clients, and ask management about this, and most of the replies are essentially "It was the VP's decision, and it's not to be questioned or challenged." Considering that the VP lobbied for it as a good decision, it may not be something most would like to look into and find that they were actually wrong about that $6,000,000 decision (multi-year deal given the resources I've seen). 

The only hard numbers we traditionally had to make a ROI decision on offshoring was the hourly rate, typically somewhere from $40 - $60 for developers, and I've seen as low as $20 for testers. Seems like we're saving money, given the typical $100 - $120 rates I've seen for US developers. But what if those developers don't get as much done due to the fact they can't talk to the subject matter experts and other team members in the U.S. (at least not much of the time, and not without delays, and rarely face to face)? If agile depends on that kind of collaboration, aren't we setting the offshore team member up for frustration and failure? 

Add to this the aging of the decision data. A senior manager in India recently told me, "Those CEO's in the U.S. made the decision to offshore based on very old data." Ten years ago, he told me, you could get a ridiculously brilliant 5 Star engineer in India for 1/10 the cost of the same in the U.S. Many companies rushed into India to take advantage of this - taking all the 5 Star/One Tenth engineers (Such a deal!!), then moving quickly to the 4 Star/Three Tenths engineers (Pretty good business decision). Then large outsourcing shops and system integrators rose up to take advantage of the great staffing and consulting business opportunity. By bundling long term, large team deals, they smoothed out the bumps that they were starting to run into with 3 Star engineers and a moderately lower rate. Now, my friend said, it is very hard to find good to great engineers, so the U.S. is being offered 2 Star (and sometimes even 1 Star!) engineers for a rate that might look like a deal on paper, but these engineers are often not as good as most U.S. company's own developers, AND we using agile. 

A year or two ago, I was coaching a team that was waiting to start their project after they go the resources from the offshore partner. But there weren't any. We waited several weeks before they got one potential to be interviewed. The interviewee didn't pass the technical interview. Not even close. Nor the second, third or fourth. Finally, nearly three months into the original project schedule, the team compromised for fear of either having the reschedule or cancel the project.

If don't get the benefit from the cost/benefit analysis, is this truly best for the company? If we extend the team to realize the value for a project, because it takes 50% - 100% longer due to communication exchanges, the value itself is diminished. And the hidden cost of the quality of resources is certainly higher than the information and stories based on 5 - 10 year old projects. 

And if a company is saying that going agile is a strategic decision, we have to look at the offshoring decision to see if that is best for the teams and therefore the success of agile.

My next post will be on how to objectively, quantitatively and qualitatively evaluate the productivity and cost effectiveness of the offshore teams.

Why a ScrumMaster Might Lie

One question I ask in working with new groups or retrospectives is how far away is everyone now from where they were born. If we're talking about self-organization, I can ask the team to line up in that order, and watch the interactions go.

It's surprising to me how little we know about the teams we work with. That knowledge we gain, with sometimes only minutes of talking, pays dividends in a more trusting, productive working relationship and environment. 

I worked with one Project Manager turned ScrumMaster, and he was struggling with a decision the team wanted to make that he didn't agree with. He even went so far as to tell the team that their Director wanted it the ScrumMaster's way, which turned out to be not true. Not very good servant leadership. Management wondered if we needed to pull this guy out of the ScrumMaster role, for he had been an effective project manager, from what I understood. 

Then one night I ran into the ScrumMaster at Chili's and we shared a meal. In the course of that hour, I learned how he had come from a powerful Middle Eastern family. He was the eldest son and had high expecations put on him, a burden that he seemed trying to meet, thousands of miles away from his family, through work performance. All these details helped me see a fuller picture of this man who had been raised to make things happen and carry the full burden of responsibility himself. 

In this case, the struggle wasn't about Scrum, it was about a new personal definition of success and learning to trust. I would never have changed my coaching approach had I not stumbled across this new perspective of my teammate. 

Listening to Your Team

Sometimes for a retrospective, I'll have a team play the ball point game. I do this because it let's be see the team dynamics as a whole in only 20 minutes. Is someone dominating the rest of the team? Is this a team afraid to take risks? Is this a team that innovates? Is this a team that has trust, is close and works well together, or are they a group of individuals who begin to blame and finger-point when the pressure is on?

Recently I had a picture of a team that was unique to me, but perhaps common to others. It was a team that I would give an A+ to for effort and energy. They were trying as hard as the possibly could, and that was part of the problem. They were so intense, so focussed, trying so hard that they weren't listening and giving weight to everybody's ideas. Instead, in the craziness and loud voices, it seemed they found themselves guided (or more appropriately, driven) by the energy and passion of a few.

After several iterations, and even my sharing with them the performance I've seen from the vast majority of other teams, they were beginning their next iteration with exactly the same approach as before, yet committing to significantly more work. "What changes have you made since last sprint?" I asked. "We are going to be more focussed!" they said emphatically. I wish you could have seen the situation - these guys had been giving more effort and energy than a playoff team, yet were saying the missing key to success was focus? Essentially, they were saying they were going to try harder, but make no other changed and more than double their productivity.

In the quiet moment while I had their attention, I asked if anyone on the team had any ideas that hadn't been tried yet. Immediately, one then two then three people shared great ideas that would enable the team to hit their goal. Now, these people sharing their ideas were not the loud, gregarious, driving leaders. They were more likely introverts. Just like the ones that statistically make up the majority of your technical team.

Often, I'll lead retrospectives by having everyone write down their thoughts one what's going well, not-so-well, and any ideas. This ensures that I hear the voice of even the quietest (or newest or youngest) team member. Our agile teams do not succeed based on the old, traditional approach of a project manager in charge who, often, is expected to make all decision (and therefore often the only person trying to solve all problems). Agile teams rely on collective intelligence. The same way that Google has come up with great products such as AdWords and Maps, or the way that Barrick Mining found fresh approaches to find where to mine based on contest submissions from around the world (as described in Mavericks at Work). 

No one of us is as smart as all of us, so make sure that you're creating space to hear all voices and great insights of your team.

My Brother-in-Law Says Scrum Doesn't Work

The question inevitably comes up at my internal, or more often, at my public Scrum classes. "Does this really work? My brother-in-law worked over that Barf-o Software, and it was all messed up over there."

Deciding whether Scrum, or any other agile methodology, really works based solely or your or someone else's personal experience is anecdotal. It's the person who doesn't want kids because his brother's kids are out-of-control mini monsters, or doesn't like wiener dogs because one bit him when he was seven. For me, it was football. I didn't play because my brother said the coaches were mean to him when he was in 7th grade. I finally tried out my senior year and loved it. And the coaches weren't mean to me. Well, not very. I did have to run extra laps for talking to David Stewart when coach was talking to us.

Scrum works (better in some in contexts than others), but when it's going poorly, it's often because of 1) people doing Scrum wrong, 2) bad company culture, or 3) difficult team and project structure.

I've seen ScrumMasters (the role that should know Scrum the best, and therefore educating others) let the daily 15 minute Scrum go over 45 minutes, do planning poker estimating for each person's task for every story in the sprint, post a formula that showed the ratio of story points to developer and QA (it was 1 and .5, just so we all finally have the answer to that secret recipe), tell the team what their tasks would be, make every decision, lie to the team (FYI - that's bad), and more. Of course, this has an impact on the team. They don't do as well as the could, maybe even poorly. But that doesn't mean Scrum doesn't work. It means the ScrumMaster isn't doing it right. And worse, the team isn't owning the principle of continuous improve to work through these, and other, issues and get past them.

Secondly, bad company culture will make Scrum, and any other process, go poorly. Management that sets unrealistic deadlines on a project with fixed scope without asking the team for estimates will be bad for the team whether they do Scrum or traditional waterfall (although it won't be as bad with Scrum because at least you can tell management within two weeks that it looks like it's not all going to get done when they asked for it). Project managers who let every new change or request pass right through to the team without asking good questions or request priority or feature trade-offs when new, valid  needs are discovered will cause problems on any type of project. Some company cultures simply don't value the project teams, but hold to Theory X and see them solely as resources who need the whip cracked in order to get results. These executives will try Scrum because they hear it will get more results faster. But when they find out that these improvements (and others) come in part through self-organized and self-managing teams (who expect to be supported and empowered), senior management won't let go and trust, but instead tries to implement the Scrum practices without the Scrum and agile values. The results are predictably bad (and the teams upset, too boot).

Last, Scrum works best with cross-functional teams of people sitting together, and preferably kept together long term and fed different project. Once, a ScrumMaster was saying he felt his team wasn't gelling and collaborating well together. It turned out that every one of his team members lived in a different country. In Scrum, we work better and more efficiently in part because we move away from our functional team silos and heavier-than-needed process and towards individuals and interactions (just simply talking to each other more in order to solve problems and get stuff done). If you don't have that, it won't work as well. And that's not Scrum, that's your organizational structure. I've seem team members on a team matrixed on 17 different projects. How effective can you be, really, with 10% of your time on a given project? On paper, with some resourcing tool splitting everyone's time up, the math deceptively looks good. But in reality, ramping up and down daily on different projects and activities thrashes productivity. That's not a Scrum problem, that's someone somewhere not wanting to prioritize and say, "Really, these three initiatives are the most important. The other 14 will have to wait."

These, and other, challenges are some of the problems covered in the Certified ScrumMaster class. Scrum doesn't solve these people or culture problems for you. It simply makes the problems you have clear, and gives you great tools to show, if you change, how good things can be right away.

Who Should Be the ScrumMaster?

Who should be or become the ScrumMaster for your new team? That is, which role: project manager, lead developer, functional manager, or anyone but one of these roles?

Although, understandably, most management wants a standard answer for who they should select to be the ScrumMaster in this new work paradigm, there is not a one-size-fits-all answer. And the reason is because it depends on the person, the team and the environment.

Before I walk through some of the roles, I think it's a good question to ask "Who is deciding who becomes ScrumMaster?" I see management decide often times, but they make the decision without knowing what Scrum is and, more importantly, how it works. The decision on who the ScrumMaster will be does not need to be made months, or even weeks, in advance. I've seen teams decide hours before their sprint begins. If at all possible, take this important decision to the team to see what they think. There needs to be prudence in this, certainly, but I'd rather lean towards making this statement of empowerment and trust of the team from the very start of adopting Scrum.

I commonly see Project Managers given the role of ScrumMaster, but there's a trade-off. What makes a great project manager may not make a great ScrumMaster. In fact, it might be counter. Often, management wants project managers who "get things done." That is, they drive performance. They push the team. They may even micro-manage for results and visibility by tracking every task, status, risk, change and deviation from the plan. And management might love this (or, more truthfully perhaps, love the results). On the other hand, I've also seen Project Managers who provide management what they want (helping get more productivity and more visibility to progress, issues and options) by serving, empowering and trusting the team. If you are currently a Project Manager, which type are you? My experience has been about 50% of project managers are on each side, with very few changing. For some, their "driver" approach impacted the team so badly that management was considering removing the person from the team.

I've seen managers also take on the ScrumMaster role. This, more often then project managers, has negative consequences, only the consequences are not so obvious, but these can be corrected more often and more easily than I've seen with project managers. Some managers, due to their company's culture and expectations, carry the responsibility of getting results from their people (for the projects their people are on). Along with this, many more are expected to make sure their direct reports are busy (that management is getting their money's worth from the employees). For these managers, even if they wanted to embrace the transformative qualities of the ScrumMaster, the company culture will push back, and most often win. For managers in these tough positions, I'd rather see them find someone else to be the ScrumMaster, and then the manager can focus more time and energy towards the bigger need of being a heat shield, organizational impediment remover and management mindset and company cultural change agent. Truthfully, that is the great need and value immediately and long term. For those managers not in culture or carrying those "busyness" mandates, and who have the right attitude towards their role and their team, I have seen great things happen. For these managers, this new role in the business and IT world of ScrumMaster opens new pathways to work with their team, provides new tools to let their people learn and grow, and fosters collaboration between their people. In many ways, this is what these managers were looking for in terms of moving away from needing to make sure things got done (which now the team commits to and owns getting things done), and wanting to focus on growing their people. For those managers wanting some book recommendations specifically for this new "Agile Manager" aspect of their work, take a look at my Agile Management and Leadership book list on Amazon.

My preferred option for whom should be the ScrumMaster is to look to those who are individual contributors (developer, lead developer, business analyst, QA). Ideally, the ScrumMaster is a fulltime role, which has the downside of giving up a fulltime employee. Again, this is contextual. The ScrumMaster will certainly need to be fulltime if the team (and/or company) is starting with agile, or if the project or product that the team is working on is fraught with challenges outside the scope of the basic context taught in my Certified ScrumMaster classes of a "single, co-located, cross-functional team." That is, if there are challenges of having multiple Scrum teams, or using offshore or remote team members, or a larger team, than the need of a ScrumMaster's time and help will be greater. On the other side of the scale, in a simple context, supportive environment, and/or experience ScrumMaster, I've seen the ScrumMaster still do 50% of his or her time doing development (or other tasks) as a player and coach. The biggest trade-off there is that the ScrumMaster needs to know their personal limits on commitment to tasks and stories they take on, as well as balancing personal and team focus. Not easy. 

I'll end with my favorite stories that illustrates what I'm really after when thinking of who should be the ScrumMaster on team. First, I was at a company that was deciding how much to grow their agile adoption. They had one team doing Scrum for six months with great results and a second team had just finished their fourth two-week iteration and was also doing well. The conversation among the executives came to a seemingly trivial point of who the ScrumMaster happened to be on the six month team. When a manager informed the executives that the ScrumMaster also happend to be the most junior developer on the team, there was unanimous appreciation and excitement about how this was exactly what the company wanted for it's culture - that anyone could make very significant contributions! 

My second story is from when I was working with a team that had a working agreement that included rotating the ScrumMaster every two months or so. After finishing their second rotation, at the meeting to decide whom would be next, the team unanimously, and quite noisily, voted to keep their current ScrumMaster. Forever. They loved her and how she helped them. She had grown to love the role and the team as well. And this was a person who was had a fair bit of self-doubt about even trying out the ScrumMaster role the first time, only agreeing to do it because of the guarantee of the ending (surely in failure, she assumed). 

It's stories like these that show how Scrum can help individuals, teams and companies thrive.

Scott recently posted an updated version of this post on the Rocket Nine Solutions blog: http://rocketninesolutions.com/implementing-the-scrummaster/

He also posted a companion piece: Who Should Be the Product Owner, http://rocketninesolutions.com/who-should-be-the-product-owner/

And you can find a video about it on http://rocketninesolutions.com/ as well.
http://youtu.be/4hqywLT0mWM

Looking Back at 2011

I had one of those great, intellectually charged conversations the other day with a colleague and friend, one of those discussions that leaves your mind abuzz. One nugget that came out of it was what books I had read this last year that have had the biggest impact on me as an agile coach and trainer. Here's the list I shared with him:

Must Read

Switch - How to Change When Change is Hard - A great read with lots of science and stories behind how and why people and groups change. Provides a structure to follow in leading change. A must-read for coaches and those leading change efforts.

The Lean Start-up - Eric's book provides the framework, reasoning and experience on how to swiftly determine the product to build. More than that, Eric provides pragmatic understanding of why traditional businesses and management behave the way they do, and how to deliver measurable, actionable way to change that. A must-read for anyone in IT, product development, management or executive leadership (so, everyone). 

Getting Naked - Shedding the Three Fears that Sabotage Client Loyalty - Patrick Lencioni shares what makes real consultants (and consulting) awesome, versus those traditional consulting companies that we all love to hate. A must-read for anyone in consulting or in other ways provides professional services.

I would add The Goal by Goldratt because I loved the use of a fictional story to learn about lean and the theory of constraints, but it hasn't had the practical impact that the other books above did.

Insightful

Mindset - The New Psychology of Success

Interesting 

The Black Swan - The Impact of the Highly Improbable

I'll add to this list several of "Must Watch" videos:

Joe Justice at TEDx - Agile used to create a 100 mpg road-ready car in 3 months. More lessons for all businesses in this 10 minute video than any other I know of.

Simon Sinek - Leaders, Start with "Why" - One of the Top 20 most watched TED videos. All companies know What they do, some know How they do it, very few know Why. Great for product managers, management and leadership.

Animated Daniel Pink Talk on What Motivates Workers - A very engaging video, using graphical notetaking, that I show in many of my classes that shares the three things that motivates workers (and none are money). Based on Pink's best-selling book Drive. 

Marcus Buckingham on Learning Your Strengths - A well-polished 10 minute introduction to strengths. It is part of one of several DVD's that I play for teams as part of team-building or learning self-organization in agile. 

And ONE "Must Attend" conference:

The Leadership Summit

"But, wait," you're surely saying, "didn't you attend four other agile conferences (and two one-day events) in 2011?" Yes. 

And I have referenced, quoted, shared, lended more by the speakers from The Leadership Summit (Lencioni, Godin, Booker, Schlesinger, Hybels, Furtick) than all the other conferences combined and doubled. And it was only two days. And 1/10th the price. And available (almost) everywhere in the world via simulcast. 

"But, wait - again," you might be saying, "isn't that a Christian event?" Hosted by a church - yes. Goal to make attendees Christians? Definitely not. Goal to change the world? Yes. I think it's good to be around a bunch of people who really want to, and honestly believe they can, change the world. Even if that means stepping out of your comfort zone. It may just radically change your Why (just as we hope to do in the companies we serve).

Three Simple Tools for New Teams

When I am delivering Certified ScrumMaster classes or starting up new agile teams, I share three simple tools that really help collaboration: creating a working agreement (also called team agreement), the art of the possible, and the fist of five. Based on feedback, these three items are often some of the important tools that team members take back and use immediately. Below is a simple way to introduce these by facilitating creating working agreements with your team.

Photo by Greencolander via Flickr.

Before you kick off your new team, get the team together and let them know the goal is to come up with some team agreements so that we all agree on how we’re going to work together. You might have some ideas, but first go around and hear others first. If you’re in a large group, pair up, otherwise each person can individually write down one statement about how their time together should be – everything from working hours to working conditions. Now collect these and put them on the wall, under the title “Working Agreements.” For general work, I often hear: take personal calls out of the working area, headphones on for music, keep your chat program on, put a flag or sign up if you don’t want to be interrupted (for less than an hour), shower regularly (seriously), no eating fish at your desk (yep, that too). Some common ones for meetings that I’d recommend are: one conversation at a time, start and end on time, electronics by exception (that is, no cell phones or computers unless it’s an emergency and everyone understands that), and have an attitude of the art of the possible.

The art of the possible means keeping an open mind that something covered here could work ormight be true, even if you disagree, instead of an attitude of “that could never work here” (even if that is your experience). There’s always a first time, and the difference of our attitude, effort and approach differ vastly when something “just might be” possible, rather than impossible. MacGyver believed in the art of the possible.

Now that we have everyone’s recommendations, decide on what the final working agreement list will be. My preferred way of collaborating on quick yes/no group decisions is with the technique called the “Fist of Five.” When you’re in a group deciding on something (such as where to go to lunch that day), you can simply say the recommendation and then have everyone hold up one to five fingers. The number of fingers represent where they stand: 5 means they love the idea, 4 means they like the idea, 3 means they’re not that happy but they won’t get in the way, 2 means they have some questions or concerns that if answered they’ll get on-board, and 1 means “No way, ever, never!” (and make sure the one finger is the index finger…) Fist of five is a great way to hear everyone’s voice and quickly see who’s not in agreement and why (and then work to get them in agreement).

I hope these tools help your team get off to a great start.

(This post also published on the BigVisible company blog at http://www.bigvisible.com/2011/11/three-simple-tools-for-new-teams/)

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.

Agile, Operations and Strategy

From a management point of view, you want to know that you are getting the top return on investment for all of your IT efforts. Scrum makes this clear, visible and in the control of the product owner, who is often funding the effort.

But what about all of the other time and effort by IT personnel whom are not on agile projects, those who are most often "putting out fires" or working on short-notice market-driven system changes? Without a lightweight method to track these efforts, funding could be misspent and neither CIO's nor CEO's would know. Worse than money wasted on effort not making a difference, it is money that could have been spent on something that would have improved the company and\or IT.

This IT request tracking should give visibility to requests, timeframes, the requestor, estimated effort and status. It should be visible to all IT and company management and proactively alert key stakeholders, and also provide summary reports of effort so that management can regularly easily see a high-level view of all effort and knows how money is being spent.

Project Areas and Team Member Proximity

I’ve seen significant increase in information sharing on project teams due simply to having daily scrums (agile status meetings). I’ve wondered how much more would communication (and therefore team performance) improve if I had the team members moved to cubes in the same area. The evidence from Tom Peters, below, is significant. Note how close teammates need to sit for optimal interaction.

“…if you and I are separated by 5 yards or less, the odds of us communicating at least once a week are nearly 100%. At 10 yards of separation, the odds plummet to about 9%; and said odds are almost constant at 3% if we're 30 to 100 yards apart.”

Quote referenced from Tom Peters’ weblog here.

Insights from Southwest

Southwest Airlines is an exceptional company. They are the only U.S. airline to have made money every year since 1973 (since 1978, 120 other airlines have gone bankrupt). Southwest has consistent market share of at least 60% in almost every nonstop city-pair market it serves. Southwest has the best customer service record in the airline industry and is the only carrier in the U.S. to win the industry's "Triple Crown" - baggage handling, on-time performance and customer complaints. Southwest has a turnover ratio of 6.4 percent, one of the lowest in the industry, and was listed in the top 10 best companies to work for in America.

Several interesting quotes from Nuts! Southwest Airlines Crazy Recipe for Business and Personal Success:

• When people work really hard for something they believe in, a special bond inevitably develops between them.
• "Most companies fail in their growth because they don't have a vision." Howard Putnam, former Southest CEO.
• "Market share has nothing to do with profitability. Market share says we just want to be big; we don't care if we make money doing it. In order to get an additional 5 percent of the market, some companies increased their costs by 25 percent. That's really incongruous if profitability is your purpose." Herb Kelleher, former Southwest CEO
• "We'll train you on whatever it is you have to do, but the one thing Southwest cannot change in people is inherent attitudes." Kelleher
• Southwest was, in the words of Gary Barron, chief operations officer, "nimble, quick, and opportunistic." How did Southwest get that way? Whenever possible, Southwest flies in the face of bureaucracy: it stays lean, thinks small, keeps it simple."

11 Commandments and 10 Reasons

Two good lists:

11 Commandments for an Enthusiastic Team

1. Help each other be right....not wrong.
2. Look for reasons to make new ideas work - not for reasons they won't.
3. If in doubt, check it out. Don't make negative assumptions about each other.
4. Help each other win and take pride in each others victories.
5. Speak positively about each other and your organization at every opportunity.
6. Maintain a positive mental attitude - no matter what the circumstances.
7. Act with initiative and courage as if it all depends on you.
8. Do everything with ENTHUSIASM...it's contagious.
9. Whatever you want ... give it away.
10. Don't lose faith and never give up.
11. HAVE FUN!!

and

The Top 10 Reasons Projects Fail

1. Inadequately trained and/or inexperienced project managers
2. Failure to set and manage expectations
3. Poor leadership at any and all levels
4. Failure to adequately identify, document and track requirements
5. Poor plans and planning processes
6. Poor effort estimation
7. Cultural and ethical misalignment
8. Misalignment between the project team and the business or other organization it serves
9. Inadequate or misused methods
10. Inadequate communication, including progress tracking and reporting

For more information, check out Ian Percy's site (11 Commandments) and Frank Winter's series (login required) on GanntHead.com.