Software Development and Human Capital

Upcoming Agile & Scrum Conferences

2013-05-15T08:12:00.000-07:00

Including coaching, testing, small and intimate, and large and comprehensive. I included this list in a follow-up email after my Certified Scrum Master and Product Owner classes, but I thought others might appreciate the list.

June 2-7 Agile Development Conference West (includes opportunity for QA Certification class) @ Las Vegas
June 3-5 RallyON @ Boulder, CO - Awesome small conference with focus on agility in business and very high coach-to-attendee ratio). Don't have to be a Rally customer. Great for business, execs, agile leaders
August 5 - 9 Agile 2013 @ Nashville, TN - The granddaddy of them all. My session is on the Agile Leader Storyline.
August 8-9 The Leadership Summit - Where I first heard Markus Buckingham & Jim Collins. This year Patrick Lencioni (5 Dysfunctions of a Team) and Colin Powell, and more. Simulcast around the world. Find a site near you.
September 11-13 Agile Open SoCal @ University of California, Irvine - Put this on your calendar now! Small, intimate Open Space unconference with a high percentage of coaches for small sessions and hallway conversations. The only SoCal agile conference. Meet people form area companies who are doing agile.
December 6 - 8 Scrum Coaching Retreat @ The San Marcos Resort in Chandler, AZ. Heard great things about the previous coaching retreat. Don't have to be a CSC or titled "Agile Coach."

The 3 Steps of a Change Agent

2013-05-01T08:30:00.000-07:00

From July 2005 -

------------
Welcoming Reality - The Furious Indifference to Our Cause

For all my talk, I weekly come back to the question "So how do we put this into effect here where I work?" It is not uncommon for those in IT to rarely see the ideal solution, method or process actually put into practice.

Recently I've seen the confluence of, at first glance, unrelated items. When seen holistically, though, these items point to what I feel is at the heart of leading change in the workplace.

You Need to Fight, but Fight Right

"A soldier surrounded by enemies, if he is to cut his way out, needs to combine a strong desire for living with a strange carelessness about dying. He must not merely cling to life, for then he will be a coward, and will not escape. He must not merely wait for death, for then he will be a suicide, and will not escape. He must seek his life in a spirit of furious indifference to it; he must desire life like water and yet drink death like wine." - G.K. Chesterton

In business terms, a leader is surrounded by all the reasons things don't change in their workplace. If he is to succeed in making a difference, he needs to combine a strong desire to keep his job and favor with his boss and colleagues with a strange carelessness about being fired. He must not merely worry about keeping his job and what those in influential positions think of him, for then he will be a coward, fearful, and he will not make a difference. He must not merely wait to be fired - saying things and taking actions that communicate not caring about being fired or about what his boss or those in influential positions think of him, for then he will be fired and he will not make a difference. He must seek to make a difference in a spirit of furious indifference to whether he actually succeeds in creating change.

First, we must decide that we're going to fight to make a difference. This is the "strong desire for living." Making a difference takes effort, commitment, determination, and often much more physically and emotionally exhausting than just accepting a substandard environment.

Second, we realize and accept that making a difference is a desire, not a goal. Desires are what we strive for, goals are what we can actually achieve. Often, people and circumstances get in the way of what we hope to achieve. If they get in the way of goals, we can become frustrated, angry, resentful. With desires, it is easier to accept failing to attain the end result in its entirety - not getting closure. This helps one to keep from reacting. Instead, they respond. The focus is on the action(s) or logical argument(s) in question positions being discussed, not the people themselves having the dialog.

Third, we find a way to put ourselves second to the cause and the possible consequences of advocating the cause. This is the "strange carelessness about dying." We stop looking out for "#1" - ourselves, as paramount. I haven't found a way to be effective in making a difference when I am thinking of myself first because I keep getting in the way. That is, while trying to convince someone of my point, fear and doubt keep me thinking in the back of my mind, "What if they think this is a truly bad idea? If they did, would they communicate that to my boss? What then would he think of me?" At times, I become competitive. I approach discussions where a decision outcome will occur as a zero-sum game where if I don't win, I'll lose. In these cases, I must win because if I don't, I'll appear weak, foolish, less-than, that my ideas aren't sound. This emotional reaction can be especially strong in a public forum, such as meeting or an email thread with many recipients.

These three points are simple, but not easy. Making a change to the way things are done involves other people. We are interdependent in all but the smallest IT organizations. And it is our interactions and relationships with these people (and their attitudes, beliefs, understanding, motives, agendas) that are principally the challenge.

If You Want a Queen, You Have to Be a King

There's a saying in courtship that if you want a Queen, you have to be a King. This means that if we want a certain reality, we have to be the type of person deserving of that reality. We have to be a person of character if we are to expect a working environment where there is good, healthy interdependence and commonality.

Creating the unity necessary to run an effective business... Requires great personal strength and courage. No amount of technical administrative skill in laboring for the masses can make up for the lack of nobility or personal character in developing relationships.
In addition, we can see on an even deeper level that effective interdependence can only be achieved by truly independent people. It is impossible to achieve Public Victory with popular "Win/Win negotiation" techniques or "reflective listening" techniques or "creative problem-solving" techniques that focus on personality and truncate the vital character base. - pp 202, 203; The 7 Habits of Highly Effective People, Steven Covey

The combination of these two quotes from recent reading and my concerns on how to truly create change in our IT department occurred as I reviewed a document this week. It was a going-away present for a coworker. This coworker is widely viewed as an exceptional and very well respected senior level developer in our organization. The gift was a list comprised of individual submissions from his colleagues of the positive traits they saw in him. For all his wealth of technical and intellectual talent, by far the most common items in the list were "patience", "persistence", "friendly", "helpful", "giving." After working alongside him for a year, I had been mistaking the dominant reason he was so effective. It was because of his character, who he is. He was a great worker because he was a great person.

To be change agents, we need to commit to the cause, let ourselves be second, hold on to what we want with open hands, and have the kind of character which nourishes good relationships (and effectiveness) with our coworkers.

What Happened When I Spoke Out

2013-04-29T08:00:00.000-07:00

My recent post about being a change agent reminded me of one of my personal favorite posts I wrote back in July 2005 titled "Welcoming Reality - The Furious Indifference to Our Cause."

I was writing about a time when I was in the midst of a bad work situation, but at the same time was inspired by a great worker and some great change agents (several of whom didn't last). Specifically, I was wrestling with "Do I save my skin and compromise my values, or do I step out and speak my mind, and whatever happens happens." The risk was real. Over the previous year and a half, I had kept a tally of 17 people in our group who had been let go for various or mysterious reasons. As a manager, I tracked this and other turnover in our department. We were something like 300% over the average of the rest of the IT world.

Well, I chose to speak out.

And I was let go as part of a second round of layoffs couple months later. Terrible? Yes, and no. I'm writing this now to let you know:

I lived, and
I'm better off

When I talk about courage in my ScrumMaster classes, I look at students in my class and I think of this valley in my life. I know that these situations can be scary for many of them.

But these tests and trials develop something inside us that you can't buy or get from a book. It's only from experience. And your people will respect you for your courage and selflessness (can't buy that, either). These tests develop perseverance, and that gives you genuine character, which leads to hope. Hope is a core leadership trait per Jim Collins and Gallup (see The Stockdale Paradox and What Followers Want from Leaders). Personally, since that time I've gone on to speak my mind more often (and learned to position, influence and build support much better - great skills for a change agent) and live a life where I don't dread coming in to work, no matter what the situation.

I'll re-post it soon, so keep an eye out, and I sincerely hope you enjoy it -

ScrumMasters, I Hope You're Being Criticized!

2013-04-24T08:00:00.000-07:00

This recent post, The Catch 22 of Criticism, was great. Here's why it matters to you.

ScrumMasters, one of the most powerful aspects of your role is that of Organizational Change Agent.

Whomever started your large company, he or she surely didn't say to themselves at the beginning, "You know, I'd really love to create a large, slow bureaucracy. That'd be awesome!"

Yet, the company grows. And adds dev, QA, and business analyst silos. And grows. And adds management layers. And grows. And adds project management layers. And grows. And suddenly management is wondering why it takes so long to get anything done.

As the change agent, you're giving constant, prompt feedback to what is keeping your product-focussed team from being super productive. And I've seen again and again pushback from those in the middle who are fearful, or resistant to change, or have other motives, or have something to "lose." But...

Don’t let it change what you’re doing entirely or who you are. You must understand the type of criticism, the story line, and the intentions. Don’t be reactive, simply sit back, enjoy the show.
The catch 22 is that if you’re being successful at pushing boundaries, you’ll get criticism. If you aren’t getting criticism, you’re not pushing hard enough or actually making change. So look at criticism as a gift, or a sign that you’re doing something right.

By the way, I love the storyline mention. That's the topic of a session I proposed (and was accepted) at Agile 2013. More on that to come...

3 Things To Do Today To Add Agile to Your Project

2013-04-22T07:14:00.003-07:00

One morning at a client site, I came across a small group of people standing up around a table in a conference room.

"So you guys are using Scrum, too?" I asked."

"No, we're not using Scrum at all. Our project has a deadline coming up to deliver, and we thought it would help if the team just met each morning for a few minutes to talk about what got done yesterday, what's on tap for today and if anyone was having any problems."

Whether using Scrum or not, you can apply these action items below to add some agility to your project. Keep in mind that when I say agility or being agile, I mean activities and attitudes that reflect the values listed on the Agile Manifesto.

1. Meet with your project team (those doing the work) each morning for 15 minutes. Ask someone on the team to facilitate each person answering these three questions:

What did I accomplish yesterday?
What do I plan to accomplish today?
Is anything blocking me from getting my work done?

Interactive displays and interesting conversations at EWEA 2013 by European Wind Energy Association

Attribution-NonCommercial-NoDerivs License

If any problem solving or discussions beyond these three questions come up, the facilitator should ask that they be held until after the meeting when others who are interested can stay and continue the conversation. This is called a daily scrum or daily stand-up meeting. It's not a status meeting, but a collaboration touchpoint for folks doing the work.

See the thorough article It's Not Just Standing Up for a deep dive.

2. Use simple collaborative tools. Especially given that most individual contributors in IT are introverts, tools such as fist-to-five (or fist of five), dot-voting, using stickies to brainstorm or provide feedback provide an amazingly different amount and type of feedback. Anytime I just ask for ideas, or what people think, I'll get a third of what I would if I asked the group to write down their ideas, or give me a fist-to-five.

The Fist-to-Five: When you're in a group deciding on something, such as where to go to lunch, you can simply have everyone hold up fingers representing 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 can get onboard, and 1 means no way ever never. Fist of five is a great way to hear everyones voice and quickly see who's not in agreement and why (and then work to get them in agreement).

3. Estimate together. Estimate without bias.

I used to go to each of my team members individually and ask them to estimate the effort for their or their people's tasks. What works much better is to bring all the team members together and have them do a blind vote on what they think the estimate is. I commonly hear of only the leads or architects being asked for estimates, but whenever I ask the team if they would like for someone else to estimate their work, they say know. I think it disenfranchises them, eliminates real commitment, and therefore hurts motivation and productivity.

In the big picture, it's best if the work to be done is defined in terms of small units of working software (user stories) and using relative estimation (points) to derive when the work will be done. But that's a big shift, and if your team or company isn't going to okay using Scrum or other agile approach anytime soon, you can still use some helpful aspects of this approach.

Describe the work to be done. Ask if there are any questions. After there are no more questions, have people write down the amount of effort they think it will entail. Pick the persons with the lowest and highest numbers and ask them to explain why they thought so.
Vote again.

Although I hope they'll agree on the same number, they probably will only get closer. It's best to let the team decide the final number. Regardless, I've found that the conversation and team member engagement was so much greater in regards to the requirements and the estimates than I ever had before, and this thoughtful, focused exercise will yield much better understanding and therefore estimates.

These are just some things you can do today to improve your project with collaborative practices that shift focus towards agile values such as individuals and interactions over processes and tools.

3 Reasons to Give Story Points to Defects

2013-04-04T08:00:00.000-07:00

An agile manager recently asked if the teams in his department should size bugs, the same as they estimate user stories with story points.

My response was that I prefer to story point escaped bugs. Escaped defects are those not found within the sprint (because sprints should be zero-defects).

Sizing defects helps:

development teams get credit for the work that they do, which often can often include fixing bugs.
the Product Owner determine priority (maybe he doesn't really want to fix a defect for IE 5.5 users in Estonia if it means 40 points of work.
track another view of defect trends for your product (not just defect count but also total effort/complexity/doubt, priority when combined with feature requests, real progress trend, etc).

5 Things To Do on Your 1st Day as ScrumMaster

2013-04-01T08:39:00.003-07:00

As I work with students in my Certified ScrumMaster classes, coming from all roles (developer, lead engineer, project manager, quality assurance, and on), I find there is perhaps a gap in clear next steps guidance.

Scrum helps teams to focus, but perhaps it's a bit overwhelming at first. Here's somethings you might consider on Day 1.

In Scrum, the first day or step in the process is a sprint planning meeting, but let's assume that you're not there yet, but simply have been told your you're now a ScrumMaster.

Are all your meetings (daily stand-up, planning, sprint review and retrospective) scheduled? What about grooming meetings? Check my blog post for ideas on a "day in the life of Scrum" calendar. Just having the dates for the meetings will help you and your team to focus. Will you have stories ready to demo at the sprint review? Maybe, maybe not, but it's better do something and then inspect then results, rather than wait until you or others feel ready.
Do we have a prioritized backlog of product backlog items (typically user stories, and the top ones with acceptance criteria)? If not, schedule a story brainstorming meeting with the Product Owner and team. To start, you only need enough work backlog to fill the first sprint, plus another one to two more. That gets you going.
Do we have a Product Owner? Does that person understand what expected of them in this new role? Here are two videos - a short animated video on the Product Owner role, and an hour conference session on the Essential Product Owner that might help.
Do we have a team? Ideally five to nine members, dedicated (not shared on other projects), cross-functional (not a dev Scrum team, and a QA scrum team), and co-located (all in the same location and within talking distance). Any variations to this, and the challenges and likely weakened results should be communicated to the stakeholders and sponsors of the agile effort.
Has your team had agile training or experience? If not, I encourage you to set up an Introduction to Agile or Agile 101 type session. You may not feel qualified, but even walking through Mike Cohn's PowerPoint presentation Introduction to Scrum (and you can find lots of SlideShare and PDF's on this) will stir and help conversation, shared understanding and agreement. It might lower your anxiety and the expectations you put on yourself if you consider yourself less an instructor and more of a facilitator. I would expect at least one to two hours, but formal training is typically a day on this.

I also wrote a document for next steps after the ScrumMaster training. It is broad and beyond Day 1, but it might help.

Good luck, and enjoy the journey!

You Already Chose Failure (or Success)

2013-02-06T07:24:00.000-08:00

Ever wonder if it's going to work? Is this role right for you? Can you successfully lead this team? Will the project be a success?

Although we may have the skills and experience to be successful, much more is determined by the intangibles - passion and drive, collaboration skills and empathy, work ethic, vision and values.

We all have roles, and those roles are our decision filters on how we behave, and therefore our success. We are acting out of those roles whether we realize it our not, and often it's not the roles we want to be in, but default or roles not appropriate for the situation.

I might know a lot about parenting, but if my primary role when I come home is (still) business, then my actions are based on that, and I fail. I'll be trying to get one more email done. I'll be thinking about upcoming meetings and not listening to my family. I won't be present emotionally, even if there physically. And I certainly won't be leading my family to a vision of what we can be, something they get excited about and get behind.

The roles of the ScrumMaster include Servant Leader, Impediment Remover, Coach, Educator and Evangelist, Organizational Change Agent, Chief Mechanic and Shepherd an Guardian of the Process.
Our roles act as a decision filter. When you're at work, try consciously wearing one of these hats. That way, we take initiative in stopping our default responses or reactions and start acting from who we want to be.

For example, if I'm late to work, my default role of employee or reports-to-someone pulls me towards trying to sneak in unnoticed. Now, my teammates or those I lead will notice this. I've not only missed a coaching or learning opportunity with them, but I've actually modeled just the behavior that I don't want them to have.

Instead, if I am late to work, but I'm wearing the role of servant leader, I'm thinking of my team first. I transparently check in with them, letting them know that since I was late, I might have missed something they needed (or worse, the daily stand-up). I might model vulnerability about how I'm wrestling with my own inspect-and-adapt cycle on how to solve this on-time problem.

Repost - Buckingham on Management, Leadership & Employee Engagement

2013-01-31T07:30:00.000-08:00

Marcus Buckingham has been one of the biggest influences on how I work with people. His books First Break All the Rules and Now Discover Your Strengths (published 1999 and 2001) are still in Amazon's Top 100 Business and Management.

I've stitched together three posts I wrote a while back that summarize Buckingham's book "The One Thing You Need to Know...About Great Managing, Great Leading, and Sustained Individual Success"

Part 1 - http://scottdunn.blogspot.in/2004/08/markus-buckingham-one-thing-you-need.html

Part 2 - http://scottdunn.blogspot.in/2004/08/you-need-to-know-pt-2-management.html

Part 3 - http://scottdunn.blogspot.in/2004/08/you-need-to-know-pt-3-leadership.html

And two other summaries:

A nice, but low res, video with some key points - http://www.youtube.com/watch?v=RYbzV8SDkdY

And a good, concise summary of the book (and my take-aways as well):

Managing: "Discover what is unique about each person and capitalize on it."
Leading: "Discover what is universal and capitalize on it."
Sustained individual success: "Discover what you don't like doing and stop doing it."

Along the way, Buckingham provides some excellent points of focus, including a very important differentiation between managing and leading that too many of his contemporaries have overlooked: "When you want to manage, begin with the person. When you want to lead, begin with the picture of where you are headed."

We're Distributed - Can Scrum Work for Us?

2013-01-28T07:30:00.000-08:00

Another common question at my classes - "Our teams are distributed and remote. Can Scrum work for us?"

Before I answer that specific question, let me quote something recently that struck me -

When we're trying to make distributed work as well as co-located teams, why aren't the teams co-located? Is it to save money?

Henry Ford said that if he listened to what customers said they wanted, he would have given them faster horses. That's partly because customers will ask for what they think will solve their problem, but our job is to try to solve the problem. And if it's a complex problem, then our job is to plan on making multiple passes at a solution, evaluating the results each step of the way.

So, most of the time teams are distributed because they are outsourcing because management saw it as a strategic way to save money. Traditional management doesn't understand agile, how it works and how good it can be. It's often seen as a cost-cutting approach, as well. And you can imagine the frustration, and confusion, when management expects to add another layer of cost savings (agile) on top of outsourcing, when in actuality they are mostly in conflict. Perhaps a first step is to run an experiment with a team or teams fully co-located and measure their productivity.

Sadly, every time I've asked either how the company is measuring the cost savings, or how they even measure productivity of the teams, there's no answer. This might be a good opportunity to start.

As far as making your distributed team work. Did you ever have a long distance relationship? How well did that long-distance relationship work? For those whom it did work out for, what did they do? Most often they said, "This isn't working. We either move to the same city or call it quits." Okay, but in lieu of that, how much were you on the phone? How much did you visit each other?

Keep in mind, a lot of the following involve changing behavior, culture, how we work, opinions and raising the bar. Having said that small bit...

Best practices from a number of agile leaders from companies include:

Most importantly, you must travel, at least yearly. Preferably quarterly. Both ways. One company measure the productivity increase at 50% after a 3 week visit by just a few people from the offshore team.
Video chat. Given all the options and low cost, this should be a given. Have a webcam in all the meetings, and each team member should have one and ability for others to know when they're available. And get a good, hi def camera.
Screen sharing. Expect developers to pull up the code with remote team members when discussing questions and issues. There are even people who pair program remotely most of the day.
Collaborative design tools like Cacoo, and estimate together using planningpoker.com or everyone hitting the number key for their vote at the same time when conferencing.
Dedicated desk or person place. Some teams keep a computer and webcam running for the remote person. If you need to talk, just walk over to them as if they were there.
Rolling video cart with multi-account video chat and large flat screen to have others join your team's meeting where ever it is. Cheaper than you think to build one yourself, and there are sites out there that provide the specs and how-to.
You must have the all the meetings together, as much as possible. To show respect for the other team members, alternate who (onshore or offshore) has to be joining at odd hours.

ScrumMasters, Be Different from the Inside Out

2013-01-22T07:30:00.000-08:00

Reading up on Design Thinking, I came across this part of the process and was dumbfounded.

"Set aside emotion and ownership of ideas."

Oh, really? Is it that simple?

Personally, I've practiced self-awareness, servant leadership, and been coaching teams and individuals for years, and I struggle with setting aside emotion and ownership of ideas. What about people who don't even understand others, much less themselves?

And here's where I think Scrum and Agile struggle. We can teach the framework and values, but it doesn't equip us for

the people issues,
the resistance to change,
the turf wars and politics,
and the fear, uncertainty and doubt that these newly minted ScrumMasters will face back at their organizations.

Besides the classic resources I would recommend, I can honestly say that I think the ScrumMaster or agile servant leader needs to be a different person from most of the people in the workplace, different inside than 95% of the people around them.

They need to be hopeful and believe they will prevail, regardless of the circumstances. And when bad things happen, they need to believe that good will come out of it.
They need to be patient, continuing to work and work towards the goals. Not patient in terms of days or weeks of not seeing results, but sometimes months or years.
They need to look for the good in people, while having firm and respectful boundaries that cordon off the bad.
They need to know the worst of humanity that impacts our efforts in the workplace - ego, selfishness, inability to admit mistakes or lack of knowledge, revenge, fear, control, but not react to these when they come out.

Not should they not be naive about these negative aspects of the workplace we navigate. In fact, they will have even greater impact if they have been the victim of some of these abuses and not only come through it, but have no resentments. They dealt with the emotional baggage, have forgiven the person or people, and let it go. These are people that no how the game is played, don't get angry about that reality, and are still effective in getting immediate results with that environment, while slowly helping to change it and make it less dysfunctional. When South Africa began to deal with all the residue from apartheid, Desmond Tutu actually asked for just these sort of people to lead the cultural change.

Finally, they need to have a source of fulfillment that doesn't depend on their results - personally or with their projects, because these results may or may not come, not fully in this person's control. Yet they should still be a leader in that they always have something to give others, and they can if their personal tanks are full. This could come from their own personal growth, or how they've helped others grow.

We want these leaders in our workplace, but they are rare gems indeed. Be the change you want to see. Don't try to act like someone amazing, that will run out. But start becoming someone amazing, and then the actions just become natural.

Find a guide to help you grow:

The Road Less Travelled - A classic text on personal growth
Storyline - a new workbook to trackback the events in your life and how they are telling a story of your purpose here
How People Grow - Thorough book by well known psychologist
The Search for Significance - Another workbook that is a guide for finding significance over success

and be inspired - find some heros:

Love Does: Discover a Secretly Incredible Life in an Ordinary World - A fun read by a surprisingly unconventional, almost wacky attorney who founded Restore International, a nonprofit human rights organization operating in Uganda and India.
The Hiding Place - The riveting story of how a middle-aged Dutch watchmaker became a heroine of the Resistance and a survivor of Hitler's death camps.
Kisses from Katie: A Story of Relentless Love and Redemption - An 18 year old leaves everything in American to start an orphanage in Uganda.
Pranitha Timothy - Has lead dozens of rescue missions to free slaves.
Freedom Writers - A movie about the teacher in the inner city who changed lives.
Amazing Grace - The movie of William Wilberforce who began the movement to end slavery in Britain.

Great Forrester Comment - "PMO's are Becoming Incredibly..."

2013-01-09T07:30:00.000-08:00

One of my favorite quotes on the PMO comes from this frank and humorous comment from Dave West, VP Research Director at Forrester Research. You can hear him and the other panelists on Agile Portfolio Management Q & A Panel at the link below. Dave's comment starts at 1:30.

"It's interesting, what we at Forrester have observed across the industry this particular kind of maniacal kind of addition to the program management kind of practice. PMO's have grown in size and stature in organizations and become incredibly…big, in terms of their execution. One thing that it illustrates is that complexity does not solve complexity. As organizations wrestle with increasingly diverse portfolio, time-to-market pressures, one thing that they want to do is add more complexity. "When in doubt, add more governance!","When in doubt, add more people to manage the people that are managing the people!" "When in doubt, get more Gannt charts!" And I think that we've found that that does not work. I think it's clear that breakthrough companies or companies that are definitely driving the industry around change and innovation are not solving those problems with complexity."

http://www.youtube.com/watch?v=kN99R6Plw3E

10 Most Used Resources in My Certified ScrumMaster Class

2013-01-03T14:00:00.003-08:00

This is what I reference most often, or show during the lunch breaks in class. Enjoy!

Material Used in Class

1. New Scrum Primer 2.0, from four Scrum Trainers - http://assets.scrumfoundation.com/downloads/1/scrumprimer20.pdf

2. Agile Manifesto and 12 Principles - http://agilemanifesto.org/

3. Do Better Scrum - http://www.scrumsense.com/resources/do-better-scrum

4. Scrum Handbook – http://jeffsutherland.com/scrumhandbook.pdf

5. (CSPO) User Story Primer - http://trailridgeconsulting.com/files/user-story-primer.pdf

Videos Often Shown in Class

1. Marcus Buckingham, Strengths. We watched one of two videos:

a. Trombone Player Wanted http://www.tmbc.com/assets/sc/go/tpw-player.html

b. The Business Case for Strengths http://www.youtube.com/watch?v=1KeNfhw7bK0

2. Daniel Pink on Motivation – The longer TED talk, and the RSA animated version on YouTube

3. Simon Sinek, Start with Why – “Very, very few people or organizations know why they do what they do. And by "why" I don't mean, "to make a profit." That's a result. By "why," I mean: What's your purpose? What's your cause? What's your belief? Why does your organization exist? Why do you get out of bed in the morning? And why should anyone care?” http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html

4. Agile Product Ownership in a Nutshell - http://blog.crisp.se/2012/10/25/henrikkniberg/agile-product-ownership-in-a-nutshell

Videos Related to Material Often Mentioned in Class

1. Switch, How to Change When Change Is Hard - Heath

a. Want Your Organization to Change? - http://www.youtube.com/watch?v=JhBzxy7CneM

b. Why Change is So Hard - http://www.youtube.com/watch?v=RpiDWeRN4UA

c. How to Find the Bright Spots - http://www.youtube.com/watch?v=zbLNOS7MxFc

d. Shrink the Change - http://www.youtube.com/watch?v=j-iXOvkyAOk

e. It's the Situation, Not the Person - http://www.youtube.com/watch?v=Qp1_6hufkoU

Are You Fighting Others or Creating New Options?

2012-11-26T07:18:00.000-08:00

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

2012-11-20T07:06:00.003-08:00

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

2012-11-02T06:37:00.003-07:00

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

Getting Better Before You Get Bigger

2012-10-31T05:30:00.000-07:00

At most of my Scrum training classes, people ask about how to scale agile at their company. When coaching at a company, what we are doing is typically the #1 need for scaling - getting better.

As Woody Zuill said so well at the Agile Open SoCal conference last month, "People ask how to do it right in the large, when they're not even doing it right in the small."

Yes, there are methods, tools and techniques for doing agile with 10+ teams, or multi-team projects, or distributed team members. But those practices won't solve the most common problem - lack of organizational alignment, buy-in and support (and from top to bottom). Most of the issues I find are with mid-management handling the change that come with introducing agile. But this is the same challenge that happens with introducing any change. The book Leading Change reinforces this point with 10 years of stories around introducing change at difference organizations.

My experience has been that you'll be much better off getting one or two teams excellent. And by that, I mean success that everyone can see, and that is obvious. Nothing wins arguements and gets support like success, and this helps mid-management's willingness to go out on a limb with this new thing that will surely: raise more questions, change they way they do their job, move them out of their comfort zone, upset some of their reports, make mistakes. Help make that gamble for them as easy as possible.

And keep in mind that we're in the Late Majority with agile adoptions. These are companies, customers, and managers who generally do not like change, resist change, and have been at the same company (and maybe job) doing things mainly the same way for 10, 20 or 30 years.

Listening to Your Team

2012-10-16T07:00:00.000-07:00

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.

The Best Team Building Exercise

2012-08-30T07:04:00.000-07:00

Diana Wei from the Orange County PMI recent asked for recommendations for team building ideas. Some recommended a happy hour, or sailing, and I suggested doing a Five Dysfunctions of a Team offsite.

I had completely forgotten what I share every Scrum class - have the team discover their personal strengths! Over the past eight years, every department I managed, every new team I introduced Scrum to, we would do a strengths-based personality assessment. I was at a company in the Bay Area this week that had a new, heralded CEO, and I saw that they were already helping the change efforts by rolling out a personality assessment to employees. My impression is that, while many overlook these psychometric tests, great managers and leaders instinctively know the value of these tools.

There are several choices in this area that I have used and would recommend.

StrengthsFinder - Close to 10 years old, and still a perennial best seller, the StrengthsFinder assessment from Gallup will give you a list of your Top 5 Strengths Themes out of 34 possible, along with an action guide. Buy the book, and you get a key to take an online test that emails the reports.

StandOut - Last year, this book and new assessment came out from Marcus Buckingham, formerly with Gallup, was one of the first to write about strengths in the management best-sellers First, Break All the Rules and then Now, Discover Your Strengths. He's since written more books and created create videos on introducing strengths or how to truly cultivate them. You can purchase the test online, or buy the book and get a key to take the test online. It also includes an 18 page action-plan result.

Action & Influence - Brand new assessment from an agile training and coaching company that I think highly of, this assessment not only gives you your strengths, but it also maps that onto a grid of your teammates. Now managers can see in a nice chart where all the team members fit, and are able to quickly identify any gaps in the team, or opportunities to move people into roles that play to their strengths. The test is based on over a decade of research and work in psychology and organizational development.

Teams, Being Smart Isn't Enough! You Have to Be Healthy

2012-08-21T07:23:00.002-07:00

Some notes from hearing Patrick Lencioni at The Leadership Summit in August...

Lencioni started by saying that much of what he was going to share were things we all already know, and quoted Samuel Johnson, saying "People need to be reminded more than they need to be instructed."

For the second time during the conference, I heard someone talk about Southwest Airlines (the first time was by Jim Collins). Lencioni started his talk, as he starts his new book The Advantage, by sharing a story from Southwest Airlines. For those who don't know, Southwest is the most successful airline, in a very competitive field, when looking at financial consistency (143 consecutive profitable quarters, including the only major airline to do so following 9/11), and customer satisfaction (consistently at the top for lowest customer complaints, most on-time flights and fewest baggage problems).

Lencioni was at a leadership event at Southwest listening to presentations detailing Southwest’s values (the ‘Southwest Way’ - a Warrior Spirit, a Servant’s Heart, and a FunLUVing), their unorthodox approach and the things they do to make their customers happy. He was sitting next Southwest CEO Gary Kelly. Lencioni leaned over and asked, "Gary, why don't your competitors do any of this." It was a rhetorical question, but he said, "Honestly, I think they think it's beneath them."

Building a Heathly Organization

Organizational health is the single greatest competitive advantage in business. It is virtually free and accessible to any leader who wants it, and yet it remains ignored by most leaders and virtually untapped in many organizations. Too many leaders think it's beneath them. It's not measurable enough. Not immediate enough, not push-button results.

To better understand why this is, Lencioni used contrast. In order to maximize success and to be the best, there are two requirements for success. You have to do things well in these two categories:

Be Smart	Be Healthy
Finances	Minimal Politics
Strategy	Minimal Confusion
Marketing	High Morale and Productivity
Technology	Low Turnover

Being Smart is all good stuff. You should be solid in the areas of strategy, marketing, finance, and technology. It's only half of what a company needs to be successful, but gets about 98% of leaders attention. We are more comfortable with those things that are easier to measure and less emotional. But to change organizations you have to make them healthier!

Southwest is fabulous, not because they are smarter than their competitors, but because Southwest is so healthy as an organization. They get so much more out of their number of employees than their competitors do.

CEO's want to improve their companies, but it's like a classic scene from I Love Lucy. In the scena, Lucy is on her hands and knees looking at the carpet in the living room. Ricky comes in and asks what she's doing.

"Looking for my earrings," she replies.

"Did you lose them here in the living room?"

"No, I lost my earrings in bedroom, but the light out here is so much better."

CEO's know they are missing some things on the human, touchy-feely right side, but they are out of their comfort zone in dealing with them, so...they gravitate back to the left side. They focus even more on strategy and technology, etc. But the truth is, if we want to change the organization, we have to make it healthier.

Thirty years ago, the Smart side was new. There were lots of gains to be made by focussing on that side. But now, you can't distinguish your company by focussing only on the Smart side. You can have lots of great people working at your company, and they can all have the domain expertise to be awesome. But you won't be able to tap into it. You won't bring out their potential. Southwest's people aren't smarter than their competitors. But they use every bit of knowledge they have.

Organizational health is the multiplier.

The next post will be on "How do we do it?"

A Slice of Humble Pie

2012-08-16T07:49:00.000-07:00

Yesterday, as I climbed up my back steps, I had a realization that made me swallow real hard - like a something difficult to get down. It was, as we knew growing up in Texas, a slice of "humble pie."

Photo by Joselito Tagarao via Flickr using a CC-BY license.

Eating a slice of humble pie means that you rightfully were humbled. It could be the team asked if they could rotate the ScrumMaster and you're the ScrumMaster. It could be your team building idea completely flopped. Maybe a friend told you that you were the wrong in some gripe you've been carrying around for weeks. Your stock picks have brought what saving you had to almost nothing. In some ways, it's acknowledging failure. Although you might have failed, you are not a failure. And as John Wooden said, You aren't a failure until you start to blame. Failure is good medicine for us, but we often don't want to take it. We avoid owning failure - it hurts - and turn to blame someone or something else. Humility allows us to cut out the cancer from the body of experience, separating the good from the bad. Keeping the good things we need to learn from what happened, while cutting out the stinkin' thinking. Sometimes we need to realize that we're not great at everything, a shadow attitude that makes it more difficult to really listen and value other people's opinions. Humility isn't thinking yourself nothing, it's not thinking more of yourself than you ought.

For me, it was realizing that some was better than me at what I do. Even though I had been doing it longer, and I had even helped them, they were now far past me. Rather than push the surgical knife away by saying that they were doing better because of luck and circumstances (more on that from Jim Collin's later), I had to acknowledge that this person was simply more driven and hard working than I was. And that was hard for me to accept. But owning this allowed me to pause and ask myself, "Why are not so passionate so as to be that driven and hard working? What is not clear about your vision and goals that it's not that motivational for you?" That was the golden take away from this experience - my personal mission statement wasn't clear enough, and certainly didn't have a clear strategy, to empower me.

Jim Collins wrote in Good to Great that Level 5 Leaders look in the mirror to assign blame. This core leadership character trait and value doesn't come easily and needs to be developed. We don't get promoted into some leadership platform and then begin working on getting these leadership traits. Unless we already have them, the sudden, new power (however small) will quickly begin to corrupt and blind us. Instead, we develop these traits which will then qualify us for, and pull us up and forward into, leadership opportunities.

Resources
Patrick Lencioni's Fart Story (yes, really)
Humilitas by John Dickson: How the Virtue of Humility Can Turn Your Strengths into True Greatness in all Areas of Life
Great Video Clip on humility from John Dickson and Patrick Lencioni from The Leadership Summit
Jim Collin's Good to Great Diagnositic Tool

A Sample iCal Calendar for Meetings in Scrum

2012-08-13T10:00:00.000-07:00

In my Scrum training classes, one of the most common requests is that I draw up what a schedule might look like for all the meetings we've been talking about (Sprint Planning, Daily Scrum/Daily Stand-up, Sprint Review and Sprint Retrospective) in a two week sprint. I've created that sample here. Below, there are links to an iCal format for import into Microsoft Outlook and also a PDF version. On the iCal file, each meeting has a link to a description of the meeting, for additional reference.

Sample Sprint Calendar

The reason that I have sprints beginning and ending on Wednesday is mainly to avoid Monday and Friday due to common impact of people taking vacations, planning to be sick :-) or holidays. You could certainly use Tuesday or Thursday without much difference. Also, I have Sprint Planning and Sprint Review and Retrospectives happening on the same day. Although it makes for a very full day, that's what I commonly did as ScrumMaster with my teams. You could spread that over two days, but I choose to keep continuity over tiring people out (and in consideration of this, I did try to bring caffeine and sugar to the afternoon planning meetings).

Also, I wrote up a sample agenda for the Sprint Planning meeting. I plan to do the agendas for Sprint Review and Retrospectives as well.

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

2012-07-18T08:00:00.000-07:00

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.

Should the ScrumMaster be Telling the Team How to Do our Work?

2012-07-16T08:00:00.000-07:00

In a word, no. The Scrum Master is a servant to the team, not managing the team or their tasks. The Scrum Master should facilitate the team meetings, not tell people what to do. The Scrum Master should encourage and empower the team to solve their problems themselves, not inflicting their help by solving all real and perceived problems. The Scrum Master is the shepherd and guardian of the process - more of an evangelist and trustee than the Scrum Police or Scrum Boss.

The more the Scrum Master can back away from making sure work gets done, control things so that there are no problems or failures, or coordinate all the orchestration details of how things get done, the more the team can step in, step up and own the execution and delivery. One linchpin seems to be allowing the team to fail - giving them the freedom in a safe-to-fail environment (culturally and the framework of short sprints of small, shared stories), and trusting them to learn from it and get better.

In the end, no matter how smart and hard working one person is, nothing beats the power and smarts of a committed team working together and focused on a clear, shared goal.

Who Should Be the ScrumMaster?

2012-07-10T11:07:00.003-07:00

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.