What I Learned This Year

I have many people to thank for what I've learned this year. What I learned on my own pales compared to what I learned from others. I decided to list those learnings out, as they come to me, in chronological order.

I learned how much there is to learn from others. Through conversations and working together, through friendship and mentorship, I gained valuable knowledge and insight from Lyssa Adkins, Tobias Mayer, Giora Morein, Lee Devin and Amy Feinberg, Mike Cottmeyer, and Jesse Fewell. 

I have learned how great a group of like-minded people can be, effective and humble, knowledgable and open-minded, being fortunate to work at Rally. I learned from the first coaches I observed: Ann Konkler and Aaron Sanders. I learned from those I trained with: Alan Atlas and Ronica Roth. From those who've coached me: Rachel Weston and Jean Tabaka. And from the incredible peers on topics from what it means to be a coach, the agile enterprise, lean start-ups, agile games, retrospectives, kanban, and on. I have been continually surprised at how much they know and the quality of who they are as individuals - Ben Carey, Isaac Montgomery, Steve Adolph, Bob Gower, Mark Kilby, Ken Cline, Rick Simmons, John Martin, Karl Scotland, Julie Chickering, and Dale Schumacher.

I have learned how much there is to learn from peers, sharing what we're doing, helping each other, challenging each other in a peer coaching circle with Dan Diep, Travis Morgan, Sarina Huber, and Tyrone Salters.

I learned about skill and craft and different viewpoints and passions from working with David Lokietz, Jonathon Golden and Kiran Thakkar.

I have learned personal insights, and about change, friendship and community from mentoring and the small group at my church - Jim Fredericks, Brad Nichols, John DePaola and Don Saladin. 

I have learned that there's always more possible, both in myself and in others.

I have learned that being pleasantly surprised is a mindset.

I have learned that what's possible (or impossible) is really a decision of how hard you're willing to try.

I have learned that making a difference is about people and conversations, over working up an elaborate plan or breakthrough idea.

I learned the gift of giving to others without expecting (or even ability) to return the favor.

I have also learned, albeit with more difficulty, of receiving without the ability to return the favor.

I have learned that great change often takes a lot of work. Especially in me. 

I have learned that giving honest feedback takes courage and trust. It is much easier said than done, but does get a little easier with practice. And, it is a gift -  it's not about me and how I feel when giving the the feedback, but about them and wanting their best for them.

I've learned that growth is an investment, and I'm responsible for it. There is no "ideal time" when it comes (or starts) easily.

I have learned that real change can come about when I seek out other like-minded people and share a vision that benefits them. 

I've learned, again, that there is no antidote for the weariness of life like a shot of support and encouragement from a friend. 

Amidst all the work, and travel, and companies, and conferences, I have learned that my wife and daughters are my most precious items in life. Working on learning in that area is my top goal for 2011. :-)

The Already and The Not Yet

In 1944, the US Coast Guard Cutter Eastwind, an icebreaker ship patrolling Greenland, discovered the German naval transport ship Externsteine trapped in ice. The German ship, transporting a crew and supplies for a weather station, surrendered without a fight. The German ship was rechristened the USS Eastbreeze and set sail to take this prize to Boston.

Now, the ship was under American control, flying an American flag and under the command of an American captain and some of the crew from Eastwind, but the German crew was still there, as well, a crew that for years had been under the authority and training of the German regime. Although the previous crew formally acknowledged the new authority of the Americans, it took time for individuals and groups to accept it. Perhaps there were excuses for why certain duties took so long, or to delay the trip or not keep things in good running order. It's easy to imagine how it would take even longer for the crew to act according to the rules of the captain, even when the captain would never know. Even longer to know the captain personally, such as why he did things differently and to even come to value those same things that made the captain who he was and why he ran the ship the way he did. 

The ship did eventually make it to Boston. Though it took longer than it would have with a solely American crew on a ship they already knew well, what arrived in Boston was not only the ship full of cargo, but a ship potentially full of people who understood, could believe in and perhaps even supporting the Allied cause.

Agile is full of promise and possibility. Agile is fraught with challenges and open space. There is so much to be gained at all levels of the organization when adopting agile, but there is no way to predict what specific challenges each person, or team or department will encounter. There's common problems, of course, but I've found many more uncommon problems. And there is no simpleton set of rules or turnkey solution for success that comprehensively predicted those issues. In the same way we explain why predicting a detailed plan for creating products does not work well, so to with expecting a detailed plan for going agile, a plan that takes away all fear, uncertainty, and risk. Your approach to adopting agile should also be iterative - team by team, evaluating results and planning next steps.

You have everything you need to succeed, you don't have what you need for your next step forward. Whatever information and resources that are necessary for you, your team and your organization to have a successful agile adoption are out there. What you need to do to bring the next right thing to bear for you, your team and your organization will always be the next thing to. The "already and not yet" of agile. 

With the new captain on board, the ship was now American, but at the same time, it was also not yet American. In deciding to adopt agile, your company is agile, but also not yet agile. The mission for each of us, within our role and authority (and perhaps more importantly, our sphere of influence) is to bring those aspects of what is true about agile into our projects and teams and organizations. 

Begin with you. Make sure that you are bringing agile into yourself. Do you value others? Do you value interactions, moving towards face-to-face meetings and away from email?  Be the change you want to see. If you want those around you to be willing to learn about agile, go learn about agile at your local user group, the next conference (or one of the other 31 things you can do today to be more agile). If you want them to be learning from each other, share what you're learning with others - start a weekly brown-bag book club, and quotes to your email, go have lunch with the other ScrumMasters or agilists in your company.

Know that it will take time. In the U.S. culture, we often want instant gratification, can be impatient, and easily forget previous progress. One of the most successful large agile adoptions I've recently heard of has been 22 months in the making. Another large company has several full time agile coaches helping  their adoption for over a year. Accept that it will take time, and help educate and set the expectations for others. That way, when issues arise (and they surely will) you've prepared decision makers to respond according to truth and reality rather than react emotionally.

It's all about the people. In the end, much of agile adoption is about culture change. Change is hard, and culture can be deeply rooted. Given that the agile manifesto points to valuing individuals and interactions over processes and tools, we should always be aware that the focus of our time and energy, as well as key to addressing problems and issues, will be people over modifying the agile process or details of a roll-out plan. The most successful adoptions and problem solving have come when I've made a point to spend one-on-one time with the right people. The "right" people might be the most influential, or most vocal, or most frustrated. 

Be willing to invest in a journey that, although not the most shortest, will bring about the most change - genuine, enduring change.

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.

Vision is Spelled "R-I-S-K"

I remember the first time I heard the Product Owner in Scrum referred to as "the single throat to choke." I was watching a video about the roles in agile. It was on YouTube and done by someone with a nice, therapeutic voice named Lyssa Adkins (who turns out to be a nice, therapeutic person who knows a ton about agile and gifted in helping others achieve and be more than they thought they could). At the time, I thought that phrase used in the video was a bit strong, yet I agreed and respected it. I use it today. And it is not just true for Product Owners, it's true for anyone in a position of leadership.

Product Owners, ScrumMasters, architects, leads, managers and those above them are just some of the roles and titles that are in some aspect about leadership, and vision is a significant attribute of leadership. Ken Blanchard wrote that after "studying leadership and organizations for more than thirty-five years and have come to a conclusion: All the world-class organizations we know are driven by three critical factors," the first of which is "clear vision and direction championed by top management", adding "Vision and direction are essential for greatness."

Vision is seeing something ahead, in the future, that is some positive, fulfilling goal or desire of what you or your team or company (or country, or family) could be. When sharpened, it stirs you, motivates you, bugs you, pulls you into action. And when sown into those around you, it will often do the same for them. Ken Blanchard described vision as "being so clear about purpose, so committed to it, and so sure about your ability to accomplish it, that you move ahead decisively despite any obstacles." Vision, like faith, is being "sure of what we hope for and certain of what we do not see." And borrowing from what a pastor once said, Vision, like faith, is spelled "R-I-S-K."

In order to have a truly compelling vision for our product or service, for our team, for our company or ourselves, we at some point have to step out into some unknown. Jim Collins' vision framework includes BHAGs - "big, hairy audacious goals." If we limit ourselves to only a safe next step, "like X but better", we miss the power of challenge, good anxiety, and focus that are part of the traits of good Scrum teams. Those traits draw teams together and yield the multiplier effect.

Helpful links on items mentioned:
Jim Collins' 14 page Vision Framework guide
That Vision Thing, article by Ken Blanchard

People Help Agile Adoptions

A common problem I hear from those trying to help agile take hold or grow in their company is that outside individuals or groups that support is need from do not try or even want to help. "How do I convince them? Force them? Go around them?"

My experience with change is that well-paced, lasting change comes through people who want some part of the hoped-for outcome. They may not want the change itself at all. Heck, change is hard.

So why do some of us simply expect people to do the "right thing?" As trite as it sounds, "What's in it for me?" is a fair question, if not just plain reality. How is adopting agile going to help them, their department? How is it the best solution to for current or future problems? How will it bring at least some success with little risk? How will it help their careers in 1 or 2 years? How will their boss view their decisions, and help their boss with the same questions above? Based on personality, how does going agile help them with personal decisions, teamwork, consistency or processes?

Sometimes when we believe in something strongly, we can forget that others _can't_ see what we see. We forget the process we went through before we became convinced, didn't read the "A-ha!" moment article or hear the great speaker at the conference. Others don't have the same experiences we had of painful projects, missed expectations, resource problems, or failures we felt responsible for. Often, these other groups haven't been responsible for anything except providing resources from their department in a predictable manner to many demanding and impatient internal customers.

Meet these people where they are in their workaday, pressure-filled world. Hear them out. Ask them what their problems are. If it seems the right time, share with them how agile will help those problems while not exposing more risk, unknowns and change than would make it worth it. You may have to wait a week between asking them and sharing your thoughts. If they have questions, do the homework necessary to provide answers succinctly and in a what that can be easily shared with those they work with. Ask them what success would look like to them if they were to try agile. Work with them to plan the next few steps.

Patience and consistency go a long way, and if they believe you are looking out for their good, they'll begin to trust you at a level that helps everyone move forward.

Getting Executive Buy-in for Agile

I was recently sent a question that I've heard before. It's important, and I think my view (as someone with strengths Relator and Strategy) is not one I've seen much in the workplace. So, I thought I'd share the question and response with you. I hope it is of some value.

Question: Given a development team that is fully convinced of adopting the Agile methodology, what is the best way to get buy-in of upper management that is used to having hard deadlines and deliverables similar to what (allegedly) was delivered by waterfall methodologies?

My Response:
Good question, and I have a couple thoughts.

First, it would be nice if you could dig up even a few facts about what's happen in previous projects. Often I go through email from key people at milestones or deadlines and build a simple journal of events. It helps keep the facts simple and clear in my mind for when there's a key decision-making meeting later (I tend to lose my train of thought or important facts in those pivotal moment).

That ties into my bigger view, which is that my experience in winning others over starts with a focus on a short study of those people, and only after that, what their objections or concerns are. Often times "the issue isn't the issue." All problems are people problems, so focus on the person. It's likely the decision for this person is not about facts, but about their fear, uncertainly and doubt.

So, if they have their neck on the line, you present agile as a great risk-mitigation method (and let me know if you need the info on why that is so). Or if they need some wins with key management/peers in the company, present it as the best way to get game-changing features out, and out sooner. If getting stung by poor quality is the issue, take the approach of quality built in upfront.

Practically speaking, they are usually only concerned (or focused) on one or two aspects. Keep it simple and address those. If you're not sure what those are, we can talk about fairly simple ways to get at that information.

Also, I keep in mind a couple of personal aspects. First, natural law. You have to make this agile adoption a win for them *personally*. They have to believe at some level that you're looking out for them *personally*. This builds trust and that trust gives you political capital to get things going and get things done.

Second, they have a personality and strengths that incline them to look and interact with the world a certain way. The simplest paradigm is from Management By Strengths. If they are "me" centered, it helps to present information/options/decision in a succinct way that allows *them* to make the decision (rather than be told something like "This is obviously the right thing and we need to do it," no matter how earnestly you deliver it). If they are "we" types, present it as a something the whole team (whatever he sees as team - project, department, etc) will benefit and be a part of/involved in. If they are "pace" types, you have to deliver the information and decision points clearly, gradually over time. Those types can't be hurried to make a decision to get out of a burning house. Be willing to invest in being patient, consistent and clear in your message. If they are a "process" type, present more as a clean system and process approach, not some foggy, no-documentation devs-gone-wild weirdness that they might have heard. Give them the white papers and research from Microsoft, IBM and other respected companies.

There are certainly other personality/problem aspects, but I hope this is enough to get you started. A good patterns approach to bringing change to an organization is Fearless Change. You can flip through and find ideas to apply immediately.

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

Starting Strengths-Based Teams

My most common approach to starting teams on a strengths-based approach is relatively straightforward, but powerful and a big return for a small effort and investment of time.

I order the StrengthsFinder 2.0 books, one per team member, on Amazon. Once the books arrive, I hand them out in the next team meeting (perhaps after the Daily Stand-up). I explain that the book is not so much to read, but for reference and that really it's for the code in the back of the book that lets them each take a strengths profile exam. The book has all the instructions on how to create an account and take the test. I ask that they take the exam within a week and to send me the results of their test.

I then schedule a 1 to 1.5 hour meeting to occur several days after their week deadline. In this meeting I give some background of the test, Gallup and why this is valuable to them. You can find this information on my blog or on the web. The main part of the meeting, though, is that I whiteboard a large grid. One by one, we go around the room with each person saying what their strengths are. I write them up and talk about each each, one by one. It's informative, fun and bonding.

After the meeting, I scribe the results grid and put it somewhere public (SharePoint team site, wiki, email it out, or posted in the war room). Depending on the team, I'll ask them to post their list on the cube wall.

All of this takes maybe 2 hours of effort, planning and meeting time, plus 45 minutes of their time at most to take the test. The logistics of doing this is very easy but has a huge return. But there's much more that can be done to leverage the value here, as well as grow it. I'll cover more of that in a subsequent post.

Technorati Tags: strengths, teams, agile, management, teambuilding

Introduction to Strengths-Based Teams

Over the last several years, when I work with agile teams, new or old, I have them take the StrengthsFinder assessment. I have found people in the Agile, Scrum, lean and XP camps who feel strongly about different aspects of how the work in our area is done. I feel very strongly about strengths, and would never work with a team without requesting they participate in the assessment and the training and guidance I wrap around that.

I have spoken on this topic from various angles for over three years, have used it with over a dozen teams, overseen over 100 assessments, read three books and parts of three others on the topic. I know it fairly well, believe in it, and want others to hear it.

I'll be sharing more on this topic this month, but for now let me share some introductory links of several videos from different perspectives, reference material and my own previous reference material.

Great video from Marcus Buckingham on strengths, how few of us play to our strengths, and myths that lead us away from our natural strengths.
http://www.youtube.com/watch?v=hWZTdso2Njs

Overviews and handouts from talks I've given or submitted, and other posts on strengths-based teams and management.
http://scottdunn.blogspot.com/search/label/strengths

Great interview discussing the business reasons and they share about their own strengths with good practical examples from Tech Ranch in Austin. They provide training for entrepreneurs, and has every person they work with take the profile.
http://www.youtube.com/watch?v=3wWIUu5fSlA

There are also now formal strengths-based programs at Baylor University and Azusa Pacific University's Noel Strengths Academy for Strengths-Based Leadership and Education. There's also a good overview video here - http://www.youtube.com/watch?v=UqKCUmsZKQA


agile, strengths, management,Scrum

My Work Manifesto

I've found that people can play in the same field, doing the same activities, even using the same words, but have vastly different motivations underneath. What motivates us isn't always openly discussed, but it's clearly evident when when I'm in a discussion with a new friend, some colleague my area of work, and I feel a connection on a deeper level. This becomes more of an issue when a business sector is having success and some come into that area simply for that reason. That is, most people I've met in art or landscaping do so because they are passionate about it, not because it will pay for a home in Newport Beach and a new Lexus (while they might appreciate and get those material things, that is not their primary motivation).

Admittedly, I've struggled with how I feel about this with each new agile company I see or coach I meet. I ask myself, "Were they passionate about agile before this recent boom?", but I've also had to ask myself if that matters. Would it be okay, with me, if they weren't passionate about agile and were only in it for the money? What if they were good at coaching, training or in other ways helping companies and people? What if they become passionate about it? Those questions, and more, are ones I can't answer and, I've found, that I cannot decide the worthiness of others being in this field. I can only look at myself in the mirror and refine what's there.

To this end, I put together a list to help me determine my guiding values and, as the Agile Manifesto does, did so in a comparative manner. May it be of some help to you.

Purpose-Motivated over Money-Driven
Extending the Vision over Keeping to the Familiar
Stretching Myself over Staying Comfortable
Helping the Whole over Benefiting a Few
Abundance Mentality over Scarcity Mindset
Others' Needs over Self-Interest
Giving Back over Accumulating
Making a Difference over Busyness
Significance over Success

That is, while it may be fine for others to value the items on the right, I value the items on the left more.

Goals for Agile Teams

When working with companies who are trying to adopt, or correct, an agile approach to their projects or product development, usually using Scrum, the situation, needs and specific problems vary. But the core needs, and root cause of problems, doesn't typically vary that much.

With that in mind, I have a few goals that help me stay focused on the "main and the plain" of agile, and begin with the end in mind (to borrow from Steven Covey).

My Goals for New Agile Teams :

1. That they know, understand and practice the Scrum framework
2. That they are aware of where they aren't, the possible consequences, and the limitations (domain) of Scrum
3. That they know, understand, and are living the agile principles, Scrum values and self-organization
4. That they are aware of other agile methods and the pros and cons
5. That they are connected to community and learning sources
6. That they gel and are moving forward as a team
7. To understand why management wants Scrum/agile here
8. To know their definition of success
9. To understand what they see as their opportunities and challenges

And my personal goals when coaching agile teams:

1. That I set and meet expectations each week
2. That goals are stated and progress visible
3. That goals clearly align with my customer's goals
4. That I understand what it means to meet and exceed expectations
5. That I understand what will help them move forward, and have contributed to that

Technorati Tags: agile, scrum, project-management, coaching, eds-pick, business

Kanban Book Review

I just finished reading Kanban and Scrum - making the most of both, by Henrik Kniberg and Mattias Skarin. You can download it for free. I was very impressed by this self-published book, enough so to place an order today on Lulu for a paperback version.

Despite my readings of blogs and listening to podcasts on Kanban, it still wasn't clear to me. Knibert and Skarin broke it down so clearly for me that I finally got it. They took a simple approach, used lots of drawings, as well as comparisons to Scrum that helped related it to something I did know.

Here are some of my favorite quotes from the book:

As teams evolved from individuals to self organizing units, the managers realized they were facing a new set of leadership challenges. They needed to deal more with people issues – handling complaints, defining shared goals, resolving conflicts, and negotiating agreements.
...
The WIP limits are there to stop problems from getting out of hand, so if things are flowing smoothly the WIP limits aren’t really used.
...
The only thing that Kanban prescribes is that the work flow should be visual, and that WIP should be limited.
...
What should the Kanban limits be?
When the Kanban limit for “your” column has been reached and you don’t have anything to do, start looking for a bottleneck downstream (i.e. items piling up to the right on the board) and help fix the bottleneck. If there is no bottleneck that is an indication that the Kanban limit might be too low, since the reason for having the limit was to reduce the risk of feeding bottlenecks downstream.
...
If you notice that many items sit still for a long time without being worked on, that is an indication that the Kanban limit might be too high.
•    Too low kanban limit => idle people => bad productivity
•    Too high kanban limit => idle tasks => bad lead time

...value stream map. It’s basically a visualization of the value chain and provides insight into work states, flow and time through the system (cycle time).

Over time, managers learned that if they kept number of concurrent projects low, they didn’t keep stakeholders waiting.
The need to project delivery date was no longer a big issue. These lead managers to stop asking for up front estimates. They only did if they feared they would keep people waiting.

And I particularly loved this approach with management, and of course their results overall:

But keeping traction on complex, infrastructure type issues was a harder ordeal. To deal with that we introduced the ability for teams to assign up to 2 “team impediments” to their managers.
The rules where:
1. Manager can work on two slots at any single point of time.
2.    If both are full, you can add a new one as long as you remove the less important one.
3. Team decides when issue is solved.

Three months after introducing Kanban, the system administration team was awarded “best performing team” in the IT department by the management. At the same time, the system administration team was also voted as one of top three “positive experiences” in the company retrospective. The company retrospective is a company-wide event that happens every 6 weeks, and this was the first time that a team turned up on the top 3 list! And just 3 months earlier these teams had been bottlenecks that most people were complaining about.

For those trying to learn about Kanban, or those responsible for leading, coaching and/or training Scrum in your company or for clients, I highly recommended this book.

Technorati Tags: agile, kanban, lean, scrum

Agile Adoption

Several good posts related to agile adoption -

First, from the Orange County APLN meeting in February:
"One recommendation was to use coaches and train all team members, as noted in a post on Yahoo's Scrum adoption. See Lessons from Yahoo Scrum Adoption for more.

Also, some talked about on large, complex projects, that getting good, thin slices of end-to-end feature/functionality is crtical, and difficult. See Elephant Carpaccio and Walking Skeleton.
...
Others also described, and warned those looking to adopt Scrum, of the problems with ScrumBut.

Also, for environments of continuous changes, such as product support or operations, Kanban might be a good approach.

A question, and spirited debate, occurred around what is pair programming, what is the value and how do you sell it to management?

We also discussed the improvement (60–90% drop in defect density for some teams) from using Test Driven Development (TDD) documented in a Microsoft paper."

The discussion at the APLN meeting got me thinking, along the lines of XP dev practices such as TDD and pair programming, oftwo articles I keep telling others to read are the Decline and Fall of Agile and another on Flaccid Scrum.

For at-a-glance view, check out two versions of why agile adoptions fail, with 12 Agile Adoption Failure Modes and 11 Ways Agile Adoptions Fail.

Other articles or posts you would recommend?

Technorati Tags: agile, scrum, project management, scrummaster, project manager

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