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?

3 Things To Do Today To Add Agile to Your Project

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.

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).

Agile Presentation - Dear 31 Year Old Me

My session was "Dear 31 Year Old Me - 10 Things I Wish I Had Known Before I Dove Into Agile"

What agile practices were most important? What tools were most helpful? What books? How did you succeed? Where did you fail? What helped your career the most? If I could go back 10 years, there's a lot of things I wish that I could tell the 31-year-old me. Some lessons go counter to conventional wisdom, some are just not highlighted much. This session will cover what distilled, core lessons have helped me and teams that I've coached the most as we moved into agile.

Deck available here - 

http://www.slideshare.net/sdunnrocket9/dear-31-year-old-me-what-i-wish-i-knew

There were some great questions during the Q & A session at the end of the day, including "If process doesn't save us, what does?" and "What's the best way to start up new teams in an agile adoption?"

Overcommitment, Difficult People and the Defeated Mindset

In August I left the Agile 2011 conference two days early to attend The Leadership Summit. Although I heard there were some great sessions on Thursday and Friday at the agile conference (including oft-noted Linda Rising's closing session on The Agile Mindset), I have no regrets. 

As I posted previously about my prediction, and as came to pass, the Leadership Summit renewed and reinvigorated me. I needed this more than more information. It educated me as well, but most importantly, it inspired me. I find that agile coaching in the large enterprise is less about educating people and teams, and more about helping people grow, finding their strengths and helping them to see and apply them, challenging them, confronting fixed mindsets and old ideas, and having grace for people being human. All of which can drain you. And on top of that, I believe that we need to be leaders, and leadership is hard. So, with that in mind, let me share with you what I gained from The Leadership Summit this year.

Over the course of two days (mine at a simulcast site, one of hundreds across the world), there were eight sessions. The speakers were Bill Hybels, Len Schlesinger, Cory Booker, Brenda McNeil, Seth Godin, Steven Furtick, Mama Maggie Gobran, Michelle Rhee, Henry Cloud, John Dickson, Pat Lencioni and Erwin McManus. 

Bill Hybels on Overcommitment, Difficult People, and the Defeated Mindset

Bill Hybels, pastor of Willow Creek Church in Chicago and the founder of The Leadership Summit, began by saying, "I believe we can change the world, but we have to let go of the safe, the predictable and the comfortable." I was struck by this because of The Scrum Alliance's slogan of "changing the world of work." I love the vision and the challenge of what we have to let go of in order to get there. Hybels went on to add some great leadership axioms, such as:

• Everyone wins when a leader gets better. 
• Every leader can get better.
• Where do you show that you're investing in getting better?
• Swing hard or surrender your bat.

Overcommitment

The main thrust of the talk was on leaders watching their commitment or challenge level. He drew something like a thermometer, marking three levels of answers to the question of "What is your current challenge level at work?"

1. Under challenged (crossword, visit, watch the clock, don't feel fulfilled)
2. Appropriately
3. Dangerously over challenged (Look at to-do list and, OMG. Work late, not present

The ideal level was just barely into the Dangerously Over-challenged level. We learn and perform the best with just a bit of pressure and anxiety. I have seen this to be true on Scrum teams, and it's detailed as the best way our brains learn in Pragmatic Learning and Thinking.

But, he cautioned, if you go and stay above that level, you'll break down. At this level, we can't sustain the responsibility we've put on our plate. 

Do we, as leaders, set a bad example? The truth is, he said, is that we need a "discipline of replenishment". And we, as leaders, have to take responsibility for that. Leadership bucket. If you stay DOC, you can't have your bucket stay full no matter how many 3 day weekends, luxury vacations, hobbies, retreats, etc. you have.

Our performance over time, can go way up, but then it crashes. It's possible to overweb an organization. Also, we need to watch for being under-challenged, where there's nothing new, nothing that keeps us, our team or our organization on the edge.

Dealing with Challenging People

Hybels also asked, "What is your plan for dealing with challenging people in your organization?

Twice a year, he does personal evaluations, something he calls "The Line Exercise." He puts everyone on his team, that reports to him, or leads people, in order of keepers or indispensability. At the "not crucial" end, what you have is not bad people, just at the end of the line. This makes you ask some interesting questions. "Are these people carrying their weight? On the right issues? On mission? No longer a good fit? Are there known issues, but you're not looking at them? Are you avoiding tough conversations?" I've seen this a number of times in the places I've worked. The key to the future is unquestionably tied to ability to attract and retrain fantastic people, and also dealing with people no longer fantastic. He gave the example of "Bad Attitude Fred" - How are you going to deal with him? More importantly, how long will you let him spread his negative radio-active fallout?

Bill broke down an approach in the following way:

• If the problem is just a bad attitude, give him 30 days to turn it around and if he doesn't, let him go. The truth is, these people will often truly be happier somewhere else, but they're just scared to leave or change jobs. 
• If the problem is underperformance, given them 3 months to turn it around. 
• If it is that the role has grown beyond their capacity, and they are missing the elasticity needed to adjust to that role change, give them 6 - 12 months and try to re-deploy them, break your back to honor them, and break piggy banks for their severance if you can't make something else work for them within the organization and you have to end up letting them go.

As an important side note, Hybels said that your stock as a leader goes up when you fire for clear values violations. If you don't, you drag down everyone. Fantastic people want to work with other fantastic people. These problem people are not really happy people. 90% they find something else and come back thankful.

So, are you naming, facing and resolving the problems that exist in your organization?

The Idea Lifecycle Diagram and a Defeated Mindset

Hybels said that every idea has a lifecycle. The lifecycle has four phases - Booming, Accelerating, Decelerating and Tanking -  "Nothing rocks forever." Pick some core areas, efforts or values and decide "We won't allow it to tank." Use re-invention, staff-lead efforts, and tackle cross-department problems in order to save these few and feed them back into Booming. Part of your job as a leader is to look problems straight in the eye, and ask if you're going to let it fail or arrest those tired ideas. Create a systematic way to address problems. This injects energy and self-esteem into your team, saying that we are not victims and can solve problems.

When is the last time you re-examined the core of what your organization is all about? Ask yourself "What business are we in? What's our main thing? Could we put it on a shirt? What's our core?" One company sold cars, but came to realize that they were actually selling transportation solutions. They're new slogan was "Bring your transportation challenges to us."

So, he asked, have you had your leadership bell rung recently? Leaders rarely learn anything new without having their world rocked. 

Cast a bold vision. You want your people to either say "Count me in," or think you're crazy. As leaders, we need our boldness back. We've lost a little faith. How hard are you willing to swing?

As a process, he wrote that we often go through something like:

1. "If we could just do or be "X", we could rock."
2. "But we can't... "
3. So we stay stuck. 
4. "But we're sick of being stuck!"
5. But we're not sick enough.

I've seen this a lot, especially in large organizations. Hybels called this a defeated mindset, and said we're making excuses for being stuck instead of doing the hard work of finding solutions. Create an environment where people can be lead to bold solutions for stubborn problems. Don't just just preside over things, or preserve it from demise, but to move it from here to there, from Tanking to Booming. In agile words, "Move it from problem-saturated, political, fear-ridden, hierarchical bureaucracy to solution-orientated, growth mindset, empower, self-organizing, innovative teams." And Hybels added, "You have to believe God is willing to help you do it. If you don't, step aside. Make room for someone who does."

Hybels left everyone with a challenge, 

Maybe your next year could be your best. You could learn more, challenge each other more. Tell me why your next five years can't be your best? Your team deserves your best five. It comes down to whether you want to do it. Why go out with a whimper? How you finish is how you will be remembered. For those starting out, make your first year awesome, not average. Do you want that? Leaders call people to decisions. 

Also, check out this great summary of Hybels talk. 

Meeting with Executives Key to Growing Agile Success

I just returned from perhaps the most successful short engagement that I have had. It's a story that you, whether you are on the agile teams delivering or a manager, director, or executive management, would want to see lived out in your company.

It mirrors Rally's Flow-Pull-Innovate agile adoption model, but there was a catalyst that distilled what surely would have taken months of meetings and decision making down into just several hours. 

If you have some teams with some success under their belts, consider asking to schedule a meeting with management (as high up as you can) for a meeting where you will share the agile success metrics (of your team and others in the industry) plus a short overview of agile (what problems it solves, how it works, and culture changes/failure modes). Make sure to have the ScrumMasters and Product Owners on those one or two successful teams present to answer real life questions of what went well, not so well, and lessons learned along the way. 

In my case, our meeting ended with all of management: convinced agile works, understanding the road is long and hard, deciding on next logical steps (which projects, what training, etc.).

But lead with the success you and others have had. Executives need to know why they should care and what's in it for them, then tell them more.  

The Principle of the Agile Path

After hearing Andy Stanley speak on The Principle of the Path, I realized that it addressed a number of issues that I commonly see with teams or organizations trying to start or grow their adoption of agile practices. I recently shared about the Principle of the Agile Path at the Agile Comes to You event in Orange County.

Years ago, I agreed to join my friend Joe on a hike up San Gorgonio, the highest peak in Southern California. I purchased a map of the trails and got my equipment ready to go. Days before the hike, he decided to try a closer peak, Mount Baldy, but make up for the lower challenge in elevation by adding miles to the length of the hike. I wasn't find maps for the entire hike, only the beginning, and that proved a significant point later on. The hike itself started fine, at the trail head at 6 A.M., with a plan to be at the summit just after lunch and down by late afternoon. That left some time to get to the local diner at have a hearty, celebratory meal. We did indeed make the summit on time. Joe was full of excitement and wanted to tack on one additional challenge - go back down via a different route. It was an unmarked, gravelly bowl on the side of the mountain. All we had to do was head down and the trail would become apparent soon enough. The first hour or two was fun and easy, but we didn't come across the trail yet and we were out of food. We decided to change our angle somewhat, but an hour later were still without a trail, and now without water. By now we should have been back at the trail head, so we went towards what we thought was a trail we saw. We went up and down large slopes and through waist-high brush. Still nothing, only hungry and thirsty now, and the sun was starting to go down. Out of options and getting desperate, we decided to go aggressively straight across the mountain, up and over one side of the mountain, then two, and then we ran into a small, impassable, 100 foot gorge. The only way around was to go back up the mountain and drop into the riverbed below. By that time, it was dark. Having hiked 12 miles over 13 hours, We were exhausted, scraped up, out of food, water and energy. With no overnight supplies, we contemplated what it would be like to sleep on the rocky bed with no protection.

That was not the destination I had planned on when we left that morning. My intention was that at 7 P.M., I would be relaxing at a greasy spoon restaurant with a hamburger the size of a dinner plate in front of me, celebrating with Joe about our successful hike. But my intentions didn't matter when we started down from the summit. What mattered was our direction. That's the Principle of the Path.

Your Destination is Determined By Your Direction, Not Your Intention
You may want to repeat that once or twice. Try replacing some of the words with your company or team's verbiage, i.e. - "Our Goal is Determined By Our Decisions and Actions, Not By Our Mission Statement", or "Our Final Stage is Determined By Our Activity, Not By Our Over-arching Strategy." However you need to adjust it to hit home, the point is that where you will end up is not about what you want to happen, but about what is happening. Let's look at the four aspects of the Principle of the Agile Path.

1. You are on a path
For those wondering when you might start your journey into agile, you are already on an agile path. You are moving, things are already in motion. The question is where is, more accurately, what direction are you headed? Since my adventurous hike, I have since purchased a wonderful hand-held tool that let me know what direction I'm headed.

2. You often don't know that you are off course
I recently heard an agile coach comment that when he hears, "We can't do that here," he responds, replace that statement (at best inaccurate) with the truth "You can do it here, it's just a matter of how hard will it be and are you willing to do whatever it takes?" So, are you off course or on course? Unfortunately, we often don't know when we're off course or lost. When I was hiking, there was no dotted line along the ground that indicated we were off course, and how especially true this is when you are trailblazing. When going down the road, you may see many signs, but you won't see the sign that says, "You, in the blue sedan! Turn around - you're going the wrong way!"

I was on a trip recently, and have become much better at finding my way. I had the directions to my hotel in Mountain View ready in advance. I followed the signs perfectly and found the hotel without missing a turn. When I went to check in, the friendly clerk told me that I did not have reservations. Without trying to appear too smug for being in the right, I showed him my printed reservation information. "Sir," he replied, "that reservation is for our location in Cupertino." Think critically about your destination, because you could be on the wrong path while following all the right signs to a wrong destination.

3. You need objective feedback
This is also important because you can feel good about the situation and still be going in the wrong direction. I felt great about my hike hours into going the wrong way. I felt great about the hotel trip all the way up to the check-in counter. And don't set the bar so high for who you ask to listen to you and give feedback.

Given that so many challenges are rooted in people (and the culture that comes out of a group of people), you could get this feedback from friends, peers or colleagues over lunch, email or regular collaboration such as coaching circles (weekly conference call for like-minded professionals).

4. Judgement = Time and Experience
The core of value in objective feedback is that it is based on good judgment. Good judgement comes from time and experience. Even though the average professional football player has more experience than many in agile, you will still find someone on the sidelines guiding their progress. Their coach is someone with more time and experience around the game, and who is somewhat physically removed from their effort and activity.

Take a moment right now and consider where you, your team and your organization are heading on your path of agile adoption. Write down what you feel good about, what concerns you and write down the name of a person that you will contact today - take the bold step of reaching out and begin getting some objective feedback. They may just be the person to tell you to take a different way down the mountain.

You can watch some of Andy Stanley's talk here.

Strengths of a ScrumMaster

In previous posts, I listed some introductory material on strengths and how to start the process of beginning to build a strengths-based agile team. The next deeper and more powerful step in the process is working with team members one-on-one through the lens of their specific strengths.

When speaking at events, or after facilitating taking the profile test and walking through the results, I am often asked "What strengths do good ScrumMasters have?" I think there could be a good number of different strengths, depending on how the individual leverages them, the make-up of the team and projects needs and the surrounding organization. I'll list several that I think are good or that I've seen leveraged well. I've also listed strengths that "pair well", balance and support, that strength. These could be other strengths that individual has, or strengths that other team members have. In the latter case, those team members need to be interacting and working closely enough together that those strengths come to play directly and collaboratively with the ScrumMaster. I think that a strength not being leveraged specifically when it's needed is like the superhero not responding to the call.

Some Strengths of a Good ScrumMaster
Belief
Belief is good for several reasons. One, I think believing in something, truly believing in it, is infectious. It spreads. Other people can't help but catch it, find out about it, get interested in it when they're around people who are staunch believers in it. Also Belief is great for ScrumMasters because people will surely have good questions, raise tough issues and even come against you. Your rock solid Belief will handle these, and often people need to see there is something real beneath what they see as the latest business fad or self-serving or just not well though through (which in all fairness does happen in our workplaces ). And sometimes it's only your belief in something that carries you through the hard times. And we all know that doing Scrum, and adopting agile in the bigger picture, can be quite difficult.

Pairs nicely with Woo so that you're winning people over to what you believe, and also pairs well with Leaner and/or Input so that you are always taking in information that fills out and supports your belief. That way you can engage in informative dialog rather than "because I/they/boss/Santa Claus said so, that's why" belligerent debates. Also, Learner/Input will broaden what you believer in, so that you become just as much a true believer in, say, test-driven development or continuous integration, as having retrospectives.

Futuristic
Another strength that can pull you through the difficult times and challenges is Futuristic - the ability to really see what could be. That vision should, of course, be shaped and defined by Scrum and agile, and related areas, so it also pairs well with Learner and/or Input. But where Belief is contagious because it provides a solid rock, Futuristic is contagious because it pulls people forward, positively, toward the vision. This is effective in good times and bad, because you can always move forward, ahead. To say Futuristic is important for leadership is an understatement because people, and especially teams, want to get behind, support and follow a vision. Paint that picture you see (cast the vision) repeatedly because vision does leak - life gets in the way and distracts people.

Input
Input is great simply because there is so much to learn, and to quote S.H.R., "it's great to learn, 'cause knowledge is power." As the ScrumMaster understands what's happening at a detail level in his team (with the QA tests, with the designers dealing with the outside vendor) or his company (with management decision making process, and new market they are consider) or with agile (the best books, good blogs), all those bits of information are fuel for good decisions at some later, who-knows-what time. Some people are good at listening and collecting information, but only when they know (or think) it's important information or an important time. As humans though, we make mistakes in judgement (such as what we deem 'important') and timing, much less simply missing information. On top of all of this, frequently it is the most specific details that have the truest value - such as the difference between getting an error versus no response on the call, or there's a new open source CI tool, or which server the problem was on, or that the newest version of the Spring framework coming out in five days can consume XHTML natively (I made that up). But the wonderful thing about Input folks is that they can't turn off the collecting machine. And as a ScrumMaster, this strength can be grown to take in all these great details all the time, every day from every team member and then, like a pollinator, carry it around to other teams, stakeholders, and resources to help them: make better decisions, solve problems, collaborate, raise the bar, help YOUR team.

Input pairs well with strengths that give it guidance and/or limits. Otherwise, the Input can be on the web gathering information for hours. And hours. And hours (trust me, I know this…). So, good with Deliberative, Maximizer, Activator, Achiever.
When paired with Relator, it might yield someone who likes to learn about others, which makes everyone on the team feel loved. Not a bad thing. Input also feeds Belief and Futuristic.

Maximizer
Going from good to great, that's the Maximizer. If you don't think you're group is even at "good", then consider that the fact you are there and know what you know means they are already better than they were before. That's good. Striving for excellence will propel you and the team forward through whatever means you have, whether forming allies, relationship, or using the other strengths you have. Watch that you don't get discouraged because the goal is so far away or hard to reach. Don't become frustrated with others who don't "get it" that we should do X, Y and Z (obviously!). Break down your goal into smaller, attainable pieces. Limit your work in progress to perhaps only focus on a couple items, areas or people. Learn to look for, and celebrate each step towards those.

Pairs well with some form of getting information in order to know what "best" is. That could be Input, Learner, Relator, Harmony, Empathy, Connectedness.

Relator
In the end, it's all about people, and here's where the Relator is powerful and effective. It the personal relationships that the Relator will form that will influence others to come to the meetings on time, try the new method of writing tests, be willing to hear out the person they're frustrated with, get management to agree to pay for the celebration meals, get the Product Owner to show up at the daily stand-up. More than that, though, the Relator is able to see what's in people that is causing them to either impede the agile adoption, or even just personally holding themselves back on the team. When we're running around dealing with people problems (and it's said that all problems in software are people problems), often the "issue" isn't the issue. For example, the problem isn't that testers don't have enough time, it's that the QA Manager hasn't been walked through the new approach slowly enough that he fully understands it and knows that the change isn't really a risk and that nothing bad will happen to his people (making him a bad manager, right?) or upset them with the changes so much that they are all freaking out and giving him more of a headache than it's worth (i.e., it would be easier to stonewall you with "problems" and "risk" and "process"). But imagine the change when he knows you genuinely care about him, how he does, and you understand that he has a team to look after, and that you want him to do a good job at that, and you have his best interests at heart, and will be there if there's any problems, questions or just to help. Wow. He can step forward now, even without all the answers. Even knowing there will surely be some issues.

In every problem and discussion that adopting Scrum brings about, or each new project, or even each new sprint, Relator comes to bear. Being present. Listening. Caring. Connecting. Which is to say, investing in others. And all those investments are money the Relator can borrow when he needs help, an extra effort, grace, trust, the benefit of the doubt, willingness.

Relator pairs well with those strengths that would shape and direct it. Otherwise, it can just sit there being "present" with anybody and everybody, not helping anything move forward. Maximizer, Strategic, Input, Learner, Deliberative, Futuristic, Restorative and perhaps the other feeling strengths Empathy and Harmony.


There are some other strengths that I will add later and update this same post.
Technorati Tags: agile, scrum

Agile Leadership and Management Presentations

From my two Code Camp presentations on agile, leadership, management and strengths, I've linked the handouts and made a list of the books referenced. Great conversation and shared learning with everyone. Several additional resources that I mentioned are Pragmatic Learning and Thinking, Mavericks at Work and What Got You Here Won't Get You There. I added those books to a list of leadership and management books on Amazon to make it easier to track.

Here are the links to my presentations on Leading a Team and Developing Team Members - management and leadership and Scrum and Agile - People and Problems: Teambuilding with Agile and Strengths.

Technorati Tags: agile, scrum, management, teams, projects

Salesforce.com's Success with Agile

Perhaps the best slideshow I have seen on agile implementation\agile adoption in the enterprise.

• How do you roll-out Scrum?
• How do teams learn Scrum?
• Are there metrics or proof that agile works?
• How do you get executives to buy-in?
• What about the problems with Scrum or some saying that Scrum is failing?
• What is the role of agile coaches?
• How many product managers should go to product owner training?
• What does successful agile adoption look like?

From the Scrum Gathering conference of 2008 in Chicago, presented by Salesforce.com, titled "A Year of Living Dangerously".

The Year of Living Dangerously: Extraordinary Results for an Enterprise Agile Revolution

View more presentations from Steve Greene.

Technorati Tags: agile, scrum, management, saas, web2.0

Offshore Agile Teams

Good webcast on offshore development teams using agile (perhaps Scrum). The image below shows the medicine that must be taken - colocated teams. Although it sounds like a tough sell, companies that have done this report not only good results but positive experiences from team members.

The notes in red are mine, pointing out the fact that most offshore teams that I have worked with or know people involved with are operating in a dysfunctional structure.

Technorati Tags: agile, offshore, Scrum, software development

Example of Team Agreements List

Team agreements recently came up at a conference. I picked them up from another coach as a means to help set-up a baseline of expectations that the team can have of each other. They don't take much time to set-up (almost fun) but pay dividends back to the team throughout the project. We start each Scrum Master certification training with a working agreement of what makes a great class.

[2/27/17] I updated the list with some new items that pertain more to technical practices (per XP, DevOps and covered in the Certified Scrum Developer workshop).

Here's an example of a Team Agreements list:

1.    Tell the truth and be transparent
2.    Treat all team members with respect and value other team member’s time.
3.    Value team members’ thoughts
4.    When in the team room, cell phones on low tone and take calls outside of the room. During meetings, cell phones set to silent.
5.    Formal meetings have an agenda, have focused participation and begin/end on time (unless all agree to change it).
6.    Have one conversation at a time including during phone conferences.
7.    ScrumMaster will maintain a calendar in an Excel spreadsheet that will include planned leave and holidays. This will be reviewed and confirmed at start of sprint planning.
8.    Be present during specified co-location days from Monday through Friday, 1:30 pm to 10:30 pm, except for travel. Remote team members can work 9:30 AM – 5:30 PM on Fridays.
9.    Be available by cell phone when needed.
10.    Daily stand-up meeting 2:15 - 2:30 PM
11.    Daily Scrum of Scrums call with US from 9:45 – 10:00 PM (9:15 PST)
12.    Task estimated hours to completion to be updated in Rally/VersionOne/JIRA/TFS daily by 6 PM
13.    Dinner hour is free time
14.    All new code (or code touched) must have unit tests.
15.    At least one story per sprint must have the acceptance tests automated.
16.    One team member must learn something new (take a story they don't know) per sprint.
17.    Limit the number of stories in progress to the number of team members (keeps QA from getting overloaded). Often referred to as a WIP limit.
18.    We must have a team name. And the team name changes if management changes the team.
19.    Developers must check-in their code [every 2 hours, or 4 hours, or daily].
20.    If a developer broke the build, they must undue their change if they can't fix it within 10 minutes.
21.    We must pair on at least one story per sprint. A similar agreement is "We must have at least one mob programming session per sprint."
22.   Leave the code cleaner than you found it (relentless refactoring).
23.   At least [x] items from the retrospective must be worked on the next sprint (typically between 1 - 3).
24.   At Daily Scrum, only the person with the talking stick/ball/rat can talk.
25.   If anyone is late to the Daily Scrum they: put a dollar in the beer/cake/donuts jars, or have to sing and be recorded and uploaded to YouTube (true), tell a joke. Or, one team reversed it - if everyone was on time, the team got cake/pizza/new car. :-)
26.    HAVE LOTS AND LOTS OF FUN!
Technorati Tags: agile, scrum, communication, management, teams, projects

Agile and New Ideas for the Enterprise

In a previous post, I commented on what to do after successful implementation of agile to an IT team. What I found from others was that the next step is to move towards the agile enterprise, and I pointed to looking at the P & L and what drives ROI. A complement to this "what" is "how", and a great book on how to introduce this agile growth, and other new ideas, is Fearless Change by Mary Lynn Manns and Linda Rising. It is a book of very practical and comprehensive patterns to use to get support and buy-in, and it is the sum of collected experiences from many professionals.

Despite my best efforts, I often see problems and opportunities through my lens and not through the lens of those I work with. The book references work by E.M. Rogers which breaks down people into groups of Innovators, Early Adopters, Early Majority, Late Majority and Laggards. While I and others in IT, web 2.0, or project management might be Innovators or Early Adopters, two thirds of the world around us are Early Majority or Late Majority. These groups need to see others successful with an idea first, or are naturally cautious or skeptical (they could have the theme Deliberative). Moving a new idea such as Agile Enterprise, with all the visibility and accountability, is a paradigm shift, foreign and likely scary for some of the very people that will not only benefit most from it, but also whom you vitally need their support. From my initial reading of Fearless Change, I believe this book will be a significant help in getting you there. Also, understanding the strengths of these stakeholders will help you speak their language and motivate them.

After Scrum, the Agile Enterprise

The other day, Joseph Little (blog here) posted to the Scrum Development board on Yahoo! asking for input on what to include in an advanced course that he and Jeff Sutherland were leading (Agile 201). One item I raised was "What do you do when your agile project efforts are going well? What's the next step to capitalize on successful to move agile into the enterprise?"

Well, I came across a great post on exactly that - Agile Leaders - The Next Hurdle from Steve Garnett. Simply put, the next step is Lean Thinking & Financial Understanding

"It's alright being bloody great at Agile, and knowing how to deliver software and create self-organizing teams, but always remember that the engine for change, the real way to effect change, is control of the P&L."

Summary of Marcus Buckingham's Strengths Movement and its Value to Business

A few months back, I wrote a summary of the strengths movement – personal strengths, or employee strengths if you're a manager, according to the work done by Gallup and Marcus Buckingham (previously misspelled Markus Buckingham on my blog).

I've since found myself forwarding this email numerous times to others to give them a quick overview or primer with a focus on the value to the company. This post is the same content and formatting for easier reference.

Overview- Why and How

"Our people are our greatest asset." Correction - your people's talents are your greatest asset, or more precisely "Aligning our people's talents to their tasks so that they play to their strengths the majority of each day is our greatest asset."

The premise of strengths-based teams is that the most effective method for motivating people is to build on their strengths rather than correcting their weaknesses. People don't change that much, and the effort to remediate their weaknesses is much effort for minimal return. Researchers at the Gallup Organization have analyzed results of interviews of over 1.7 million employees from 101 companies and representing 63 countries. Less than 20 percent of employees stated that they were using their strengths every day. And there is no relation to type of work, skilled or unskilled, industry or even within company. In fact, more disparity existed within companies than outside, showing that there is no such thing as "great companies," only great teams within those companies.

One must purchase a book (noted later in this post) in order to get access to the test which reveals their strengths. Once they learn their profile, a manager can begin a process of how to capitalize upon each person's unique traits, aligning them with the goals of their team and the company, resulting in better performance and employee satisfaction.

Summary of Strengths Books by Buckingham and Gallup

For background, here's a summary of the related books. In "First, Break All the Rules," strengths are mentioned as one of the levers that great managers can use to get the most out of their employees. In fact, it trumps all the other tools a manager can use. Then, in "Now, Discover Your Strengths," aimed at management and business, the authors focused on solely on strengths (because it is the greatest single lever to increase team performance), listed all 34 strength types, and gave cases studies and examples. The book includes a code to take the strengths profile test. The new "StrengthFinder 2.0" book is geared more for the individual, and contains a slightly newer version of the test with a bit more guidance on the next steps of how to apply your strengths. Finally, in the new "Go Put Your Strengths to Work," Buckingham explains (and gives great, practical tools) on how to take personal responsibility in turning knowledge into action, because just knowing your strengths alone doesn't change a person into someone who leverages their strengths the majority of the day.

Supporting Facts

Here's an edited down snippet from a Gallup white paper on the results of their strengths study:

Definitions of performance vary, but typically include indices such as productivity (revenue in business), profitability, employee retention, customer loyalty, and safety. Substantial predictive validities have been established between structured interview measures of manager "talents" and future manager performance (Schmidt & Rader, 1999). In a recent study of more than 2,000 managers in the Gallup database, Gallup researchers studied the responses of managers to open- ended questions related to management of individual talents versus weaknesses. In comparison to poor-performing managers, top-performing managers (based on composite performance) were more likely to indicate that they spend time with high producers, match talents to tasks, and emphasize individual strengths versus seniority in making personnel decisions. Success was 86 percent greater for managers with a "strengths versus non- strengths " approach (Gallup Organization, 2002). Managers with a strengths-based approach nearly double their likelihood of success.

The ROI of Employee Engagement

The employees who say they "have the opportunity to do what they do best every day" have substantially higher performance. In a study of 308,798 employees in 51 companies, teams scoring above the median on this statement have 44 percent higher probability of success on customer loyalty and employee retention, and 38 percent higher probability of success on productivity measures (Harter & Schmidt, 2002). "Success" is defined as exceeding the median performance within one's own company, across work units. Managers who create environments in which employees have a chance to use their talents have more productive work units with less employee turnover.

The ROI of Strengths Development

Gallup researchers has performed studies of talent identification, feedback, and strengths development activities with a "study group" and a "control group" who were administered the "StrengthsFinder" assessment and given feedback, both individually and in group sessions, with follow-up. Post-intervention measurements of employee engagement in productivity were conducted six months later. Results indicated that the study group productivity grew by 50 percent more than the control group did.

Taken from http://media.gallup.com/DOCUMENTS/whitePaper--InvestingInStrengths.pdf

Other links:

Gallup's StrengthFinder Center: http://gmj.gallup.com/book_center/strengthsfinder/default.aspx

Marcus Buckingham's site: http://www.marcusbuckingham.com/

Do We Need to Manage People?

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

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

David Maister on Passion, People and Principles

David Maister is so straight on with his post on Passion, People and Principles (posted here).

Over and again on projects and teams and in companies, I see these truths and consequences lived out. Throw in embracing a paradigm of servant leadership and an understanding of strengths, management and leadership, and I believe every person who wants to be successful, can be. But from what I've seen, many people aren't willing to give up what they want, even for better long term, or if it hurts the company, themselves or others. Like the monkey who can't get his hand out of the jar because he won't let go of the banana inside, these people get what they want but trap themselves in the end.

IT Manager's Survey

I've been conducting an IT Manager's survey. I'll be using the results of as part of an effort to understand how personality and natural talent can be leveraged to improve one's career. The responses will be aggregated with the answers from other managers, and I'll post the final results here sometime in the futre.

I was previously a supervisor of a development team, and have my opinions on how developers can improve themselves and their career, but I want make sure I accurately represent the breadth of IT managers. The responses from other managers will help ensure this. Below is the survey.

Manager's Survey


1. What vehicle do you prefer for candidate leads?
A. referrals
B. job posting and interviews
C. recruiters and interviews
D. Other:

2. On the range of 1 to 5, with 0 being no experience with a technology and 5 being significant production-level experience, what significance would you give a interviewee if they had used the technology you're looking for a prototype at work, working demo or test application at home?
A. 5 - Equally significant. Understanding the technology can is the same whether done as part of a complex production or a working demo on a dev machine.
B. 4 - Significant. Of considerable value.
C. 3 - Minimally significant. Of little value.
D. 2 - Somewhat insignificant. Of almost no value.
C. 1 - Insignificant. Making a demo or test application is of no value in getting experience of applicable worth.

3. If a candidate had a blog, would you read it? Would a blog factor into requesting an interview or your evaluation of candidate ability and match for the position?
A. 5 - Very significant factor. I would take time to read the blog and give them equal weight with the resume.
B. 4 - Significant factor. Glad the candidate is sharing their knowledge and views. I would likely review some or most of the blog.
C. 3 - Not really a factor. Good for them that they're blogging, but I most likely would not even go to the blog.
D. 2 - Somewhat insignificant factor. Of almost no value. I would not go to the blog.
C. 1 - Insignificant. I couldn't care less that the candidate has a blog.

4. Besides technical skills and previous positions, what traits do you look for in a job candidate?
Please mark no more than 4.
self-starter works well independently team player
good communicator problem solver innovative
dependable calm leader
energetic organized creative
follows directions works well without structure Other:

5. Describe the attitude of your best employee. What does he/she do?


6. If you could have your typical developer change or grow in some way, what would it be?


7. What's your most common complaint, problem with a developer?


8. What do you look for when you have an opportunity to promote someone?


9. Describe one of the best workers you've recently (or still) have.


10. Describe one of the worst workers you've recently (or still) have.


11. What would you recommended to a programmer (or other IT worker) looking to advance in his career?


12. Could you list three to five basic traits, skills, or talents (such as strategic, responsible, decisive, persuasive, high achiever, adaptable, disciplined, quick learner, positive, or any others you choose) that define or describe the following roles:
- Senior:
- Architect:
- Lead:
- Supervisor/Manager:



13. Have you read about or been involved in training regarding personality styles, temperaments, traits, or strengths, and if so, what was the material or organization?


14. How did you get into your current position?
A. Hired into the position from another company where I was a manager/supervisor
B. Hired into the position from another company where I had a leadership role
C. Hired into the position from another company where I did not have a management or leadership role
D. Transferred within the same company into the position from another group where I was a manager/supervisor
E. Transferred within the same company into the position from another group where I had a leadership role
F. Transferred within the same company into the position from another group where I did not have a management or leadership role
G. Promoted within the same team
H. Other:

Stay Lean

From Nuts! Southwest Airlines Crazy Recipe for Business and Personal Success regarding staying lean:

Bureaucracy creates a mindset of dependency, which makes people do what they are told but no more. Rather than encouraging employees to assume ownership and responsibility, bureaucracy teaches them to transfer responsibility. Leanness, on the other hand, gives control, ownership, and responsibility to those who are closest to the action. Southwest allows its people a lot of decision-making power and authority. With no more than four layers of management between a front-line supervisor and Herb Kelleher [CEO], the leader's span of control is very broad at Southwest.

Kelleher believes that excessive bureaucracy results from the egos of empire builders who try, through title and position, to emphasize their own importance.

In a bureaucracy it's easy for an employee to say "that's not my job." This undermines productivity and prevents the company from being as nimble and moving as quickly as it might. Leanness helps identify nonperformers because,in a lean organization, marginal performance is difficult to hide.