Software Development and Human Capital

Looking Back at 2011

2011-12-30T15:17:00.000-08:00

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

2011-12-11T22:33:00.001-08:00

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?"

Three Simple Tools for New Teams

2011-12-01T07:00:00.000-08:00

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

Photo by Greencolander via Flickr.

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

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

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

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

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

10 Links for Changing the World (and World of Work)

2011-10-24T22:26:00.000-07:00

Great links I've collected over the last few weeks, of things I've read and people I've met.

Changing the World of Work

How Willow Creek Is Leading the Church by Learning From the Business World | Fast Company - http://www.fastcompany.com/magazine/151/what-would-jack-do.html A great, thorough article from Fast Company about the Leadership Summit, that blends faith and business speakers and topics. I attended the Leadership Summit this year and am posting summaries on my blog. Click the Leadership Summit tag to read those.
Circles and Soup Tool for Team Collaboration - http://www.futureworksconsulting.com/blog/2010/07/26/circles-and-soup/ Circles and Soup tool/metaphor is a nice graphic way to capture issues in retrospectives into categories that give clarity around ownership and action: what the team controls and can take direct action on, what the team can influence and should have persuasive or recommending action, and finally what is just the organizational environment that they will have response actions for.
People Don’t Shop for Organizational Change - http://agilesoftwarequalities.blogspot.com/2011/09/people-dont-shop-for-organizational.html Great post by @softqual that points out that what business come to agile for is often not what the actually need. Though we may go on about changing organizations to be agile, that's not what they're signing up for at first.
Fixed Mindset vs Growth Mindset | The Mindset Maven - http://themindsetmaven.com/fix-growth-mindset/ The topic of the Agile 2011 closing talk by Linda Rising was about Mindset. Here is a good personal story and short summary of the book's most pertinent points.
Getting to “Done” - http://www.agilejournal.com/articles/columns/column-articles/6420-getting-to-done Is the boundary of "done, done" within the team (and their capability) or the end of the value stream? And Lean Startup would say it's not "done, done" until the learning loop is completed…

Changing the World

Welcome Home Ministries, Africa - http://www.welcomehomeafrica.com/ This is the orphanage my family visited last year. We decided to adopt at the end of the trip, and now we are back here for several weeks completing our adoption.
Hackers For Charity - http://www.hackersforcharity.org/ I met Johnny Long at his restaurant, The Keep in Jinja, Uganda. Applying his technical skills and professional network to helping nonprofits and training locals in computer skills is great. His restaurant is our favorite here as well.
Kirabo - http://www.kirabofoundation.org/wordpress/ We met the founder here in Jinja, and were so taken by the videos (linked on Vimeo from the site above). Kirabo Foundation has been providing scholarships and support to orphaned and disadvantaged children of Uganda. My wife and I were really impressed with the person running Kirabo, her heart, humility and the effort she and others are putting in to this effort to make education a reality for those who otherwise would never have a chance.
Kiva - http://www.kiva.org/ Kiva is a microfinance site that lets you search for needs around the world and lend money for specific people. You get to see a picture of the person and see their description of the request. Leveraging the internet and a worldwide network of microfinance institutions, Kiva lets individuals lend as little as $25 to help create opportunity around the world.Watch a great profile video from PBS.
the Journey - Kisses from Katie - http://kissesfromkatie.blogspot.com/ After graduation from high school, Katie returned to Uganda, leaving behind family, college, friends, her boyfriend, and the American dream, to teach Kindergarten at an orphanage. She has stayed and adopted 13 girls, as well as started a nonprofit for community outreach, medical care/training, vocational training, spiritual discipleship, a preschool, and several other initiatives. There's a nice short video about her work and a reference to the book that chronicles it - http://www.youtube.com/watch?v=zfXgCx3f_1c

Overcommitment, Difficult People and the Defeated Mindset

2011-10-11T04:46:00.001-07:00

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?"

Under challenged (crossword, visit, watch the clock, don't feel fulfilled)
Appropriately
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:

"If we could just do or be "X", we could rock."
"But we can't... "
So we stay stuck.
"But we're sick of being stuck!"
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.

Summary of Agile 2011 Conference

2011-09-24T00:16:00.000-07:00

Too much good stuff. With 14 sessions to choose from for each time slot, and many more hallway conversations, I walked away with a head full of knowledge of new things to try, new areas to dig into, and new people to collaborate with.

The first problem, though, was realizing that I had to choose between 14 talks. That's correct - 14. Although one is able to see this reality on the website (and they did a great job with Sched), it just doesn't hit you until you're picking that first talk from the handout. A great lesson for me in the value of coordinating in advance with others from my team in order to cover all the sessions we're interested in. I heard several people mention how hard it was to choose, and being a little late in deciding can sometimes mean missing a seat in the room.

My first session was Pollyanna Pixton's Collaborating with Non-Collaborators. What a great way to start off the conference. A knowledgable and experienced agilist and comfortable speaker. And she started off with a graceful approach of trying to understand why someone might be a non-collaborator. My biggest take away was a grid she showed us (which is available from the links to her site). For one type of non-collaborator, "Passive Aggressive," she said "They are characterized by over competitiveness, lack of respect, self-preservation and personal agenda." I think I've seen that person more than once. How do you handle them? Her list was:

Don’t engage in a power struggle
Wrap them up in process
Don’t let them dodge accountability
Make them step into their responsibility and make it the only possible step
Make them commit in public
Take the fun out of being dysfunctional
Ask how they want to solve it
Don't let them be a manager

Her handouts also included a lot of self-evaluation, which I realized that I don't do enough of. I'm too busy taking inventory of client's issues to stop and notice mine. She said "You cannot fix people, you can only fix process." Check out her book Stand Back and Deliver: Accelerating Business Agility to dig in more. You can also watch a video of Pollyanna speaking elsewhere - the keynote at Agile Development Practices on Collaborative Leadership.

My next session was Michael Spayd on Transformation Path to Enterprise Agility. I got excited when it looked like they were going to do some live coaching, but I was waylaid at the break and never made it back to see if they did. It sounds like there was group work that was rewarding. For more in this area, check out Spayd's and Lyssa Adkins' training The Coaching Stance.

I finished my first day with a lively and fun group at Karl Scotland's Red Bead Experiment. Karl played the manager well, and the lessons of how management typically behaves, and what actually works, were clear. You can watch a version of someone else facilitating the red bead experiment on YouTube - http://www.youtube.com/playlist?list=PL8E522DD542C4CA69. You can watch Karl speak about kanban, or find out more about him on his blog.

Tuesday started out with a bang as I was blown away and greatly impressed with Jez Humble and his session on Applying the Lean Startup Model to the Enterprise. Jez understands the process, issues and value up and down the layers from dev to executive, and his insights bumped up his book Continuous Delivery on my wishlist. You can download the presentation. Biggest takeaways from his sessions:

Going agile must include DevOps. Building everything swift and smoothly, yet not being ready to have it go live swift and smoothly (much less keeping it running) is not success.
Amazon has a saying of "You build it, you run it." Treat services being built as products and align full dev+ops teams to align, stick to and support those services.
The Lean Startup mentality that "the feature isn't done until the learning loop is completed." You can get a good overview of Lean Startup by opening two tabs to listen to Steve Blank talk at SXSW while clicking through the same presentation.

The next session was my lightening talk on strengths (lesson learned - don't cram 1 hour of information into 8 minutes). For more (and better) information on strengths, visit the strengths tag on my blog.

After that, I went to my old colleague Aaron Sanders' session at Ten Tales of Positive Change. It's great to hear success stories at different levels, in different context. It's a very transferrable form of experience, strength and hope for all of us in the trenches about ushering in change with teams and organizations.

I then facilitated my other session, Narrative Coaching, with great help from colleague Skip Angel. I continue to come back to the value narrative brings on a non-prescriptive approach, finding and strengthening areas of success, and curious listening. I gave away a shirt with the classic Narrative saying, "The person isn't the problem. The problem is the problem."

Wednesday began with great insights and references to help with people and change. BigVisible coach Skip Angel discussed What are we supposed to do with these managers NOW?. Here's the summary I pulled from it:

Option 1: They need time to process change

Everybody processes change differently
Ask:

What's in it for me?
Am I gaining more than losing?
Will I be supported by the change?

Option 2: Change Roles
Option 3: Not Everyone Fits
Option 4: Willing to re-invent yourself?

More people go down this road.
We want managers to move from "Directing" to "Catalyzing Leadership" (from Bill Joiner's book Leadership Agility, which I heard referenced several times at the conference)
Be a sparkplug

Directive Catalyst
Analytical Thinking Systemic
Move from "Either/Or" to "Both/And" thinking
Unilateral Control Mutuality and Collaboration
Deterministic Chaordic. (Scary)

9 out of 10 times, your ideas aren't as good as a team decision
Be flexible, adaptive
Be Possibility-oriented
Be Self-reflective - Thing learned the most - somewhere along the way, you have to learn that you don't know everything. That you can learn and grow. But there are expectations that you have to know everything (this was powerful for me)
Move to Helping Teams instead of directing or managing teams.
Teach and supporting to say "No."
Protect the stakeholder
Make team feel safe
Build capabilities
Partner with the ScrumMaster

Where can managers support teams?

Minimize Waste - Partial work, finding info, delays, over produce, extra steps, defects, handoffs
Create collaborative environments
Invest in Learning - provide Formal Training, give Research Time, set up a Community of Practice, Set-Based Design
Change the Organization

Evangelize, educate, show proof
Recognition and rewards

Everyone needs to understand the strategy (don't make it need-to-know). Get everyone involved, and in particular, what is THEIR PART!
Culture of Learning - The Fifth Discipline (another book I heard mentioned more than once), not a culture of fear. Mistakes are OK and encouraged. We learn from them.
Optimize the whole, not the parts.
Reduce delays in the process (and this could mean starting from budgetting and allocation).
Everybody needs to solve the problems (systems thinking) that impact effectiveness.
Agile will help, but cannot address all challenges. That's why we need people in these management roles. Rather than a coach solve all problems, managers do.
Agile is not a "dev" thing, but a significant organizational change.
Agile is not a destination, but a journey.
Agile needs strong leaders within the organization to make a difference.

That ended my sessions at Agile 2011 because I left early to return home and attend The Leadership Summit (you can find my summaries of those sessions on my blog, too). In between sessions, my time was spent in great conversations with Mark Kilby, Mike Cottmeyer, Gerry Kirk, a very fortunate and mind-filling "DevOps 101" hallway talk with Patrick Dubois (his site has lots of video presentations), a Senior Vice-President from a large investment company going agile, as well as Sean Buck, a presenter and head of the agile transformation at Capital Group. And there was a breakfast for CSC's and CST's where I got to meet trainers and coaches from around the world.

Sessions that I heard great things about or wish I could have attended but couldn't (either because the room was full or I was double-booked) included:

Putting the Fun Back In Your Retrospectives: Ken Clyne, Eric Willeke,
Tell Me Why - 'The Golden Circle' of Agile Transformation: Jean Tabaka,
Coaching Success: Getting People to Take Responsibility & Demonstrate Ownership: Christopher Avery, Ashley Johnson,
Zero to Agile in 3 to 5 years - It's a Marathon, not a Sprint: George Schlitz, Sean Buck, and
I heard wonderful things about Linda Rising's inspiration closing session The Power of an Agile Mindset.

Some good reviews of the conference:

Thorough day by day reviews, with pictures, by presenter Craig Smith
Another set of nice day-by-day reviews by Cedric Pontet of Luxemburg
Reviews of Christopher Avery's session and the session building a children's book.
Agile2011 Impressions by APLN Board Member Robbie MacIver

More Information or More Change?

2011-07-31T22:24:00.000-07:00

I have choose where to spend my time in August. The biggest conference in agile is coming up, as well as the most impacting leadership conference. Was I going to spend time learning more about agile, or was I going to spend time at the conference that had changed my life more than any other? The latter is The Leadership Summit - where I first heard Marcus Buckingham, who's work on strengths was the catalyst for change in what I was doing as a manager. It was where I heard Ken Blanchard, and then hunted up a copy of The One Minute Manager. I heard Colin Powell, Colleen Barrett (previous President of Southwest Airlines), USC President Steven Sample, as well spiritual leaders Erwin McManus and Bill Hybels.

While there's a lot that I've learned about agile principles and practices at conferences, more importantly I've been changed by The Leadership Summit. A parallel is that much of my coaching comes from a mix of business and faith-based (not agile) books I've read. As Seth Godin (speaking this year at The Leadership Summit) recently wrote, there is no such thing as business ethics, only personal ethics. I find myself at a loss when talking about Scrum values such as Courage, Openness, Respect, Commitment when there is no agile book or talk that I know of that coaches people on how to grow in these areas. Even getting agreement on what it means to coach at all is subjective.

I feel a responsibility to let others know that each of us needs to know where our roots are in these areas, and with conviction and confidence that goes beyond opinions and trends but can stand up to the challenges we have and will encounter when trying to introduce change in the jungle of the business world. In the end, I decided that I needed to fill up the personal leadership tank, and decided to leave the Agile 2011 conference early so as to not miss any of The Leadership Summit.

How to Select an Agile Consultant

2011-07-26T08:20:00.000-07:00

How to pick an agile consultant to help your company? I've learned a bit after helping a number a dozen or so companies and working alongside another couple dozen agile coaches. I started this post to describe the types of people I see out there, but what seems more helpful would be to provide guidance for those looking at bringing someone in to help them. Here's a cheat sheet of questions.

Have they been a ScrumMaster on a team?
Have they been the ScrumMaster on a project in Scrum from inception to completion?
Have they worked in 1, 2 and 4 week iterations?
Have they been the ScrumMaster on a project with distributed team members or with a vendor?
Have they introduced Scrum or agile to an organization where it was new? Specifically:
Did they train team members on Scrum?
Were the teams fully-dedicated, cross-functional teams?
Did they work with department managers on team composition, managing team members and other changes?
Was there a PMO in the organization? Did they work with them on the agile roll-out?
Did they initiate and facilitate release planning?
Have they lead a multi-team roll-out?
Have they coached other ScrumMasters?
Have they facilitated multi-team release planning?
Have they collaborated with company leadership on crafting an agile adoption plan?
Have they worked on an implementation of a new product?

Transitioning a small company (< 50) to agile is generally much easier than large companies. I've found more people who are there for career security and corporate ladder climbing in large companies than small. And these people see the fear, uncertainty and doubt in agile more than the gain (for the company, but more importantly, themselves). I've also fond more people in large companies who can get away with lower performance, and the visibility of agile can be scary. The approach, therefore, for large companies needs to be much more than the principles and techniques of agile. It needs to be strategic in determining who is influential, understanding how they feel and what are wins for them personally, as well as doing your best to make sure there are clear, early wins for agile in the company so that everyone can relax a little and get behind this thing. In some ways, this is no different from any change to an organization, and it's a bit like sales.

If you work at a large company, you'll need help. Going to the Certified ScrumMaster class is only the beginning, not the end, of finding out the how and why. There are now a lot of people out there who will sell you something that looks like help. In order of visibility...

Agile Networkers. Connected with a lot of agile coaches, trainers, thought leaders and businesses. As far as what you need, they may not be, but they might know people who are. Networkers may not have the agile experience to vet their connections on a professional level, or the depth and length of a personal relationship to vet the character, so the people that they recommend to you should still be evaluated independently. Keep in mind that often the main goal of the agile networker is looking to get connected with people and activities (training classes, conferences) that can help themselves, and hopefully help others.
Agile Consulting Companies. They might have polished materials and perhaps a list of training classes, webinars or speaking events, but look at the questions above to evaluate the substance behind the materials.
Agile Trainers. Due to the popularity of Scrum, there are a lot of Certified ScrumMaster classes, but only a few who can do the training. Besides the CSM, there are a lot of other trainings out there, most of which I think are valuable. You might love the class, but someone being a great trainer and great coach involve very different skills and abilities, and I don't know that all the people can (or even want to) be both.
Agile Coaches. There are several different kinds of coaches, and you likely need some aspect of all. Most coaches can get a team going with agile and work through the people and team issues that arise. There are times when the business needs a level, though, that works with getting the executive team on board, working through strategic planning and political issues. This is much more about listening, building rapport and trust, patience, staying persistent and positive and selling by influence. Another key aspect of coaching is technical or software craftsmanship - being able to guide programmers and other team members, with hands on the keyboard, into the new world of test-driven development, continuous integration, pair programming and other agile practices (and hopefully you know how critical these areas are to the success).

In the end, nothing beats experience, and preferably a team of experienced people.

Metamorphosis - Manager to Agile Steward

2011-06-30T23:59:00.000-07:00

I was listening to someone recently talking about the role of steward in previous centuries. The steward managed the estate for his lord and tried to get the most return for his lord while also keeping the people of the land content.

I thought of how this is a better metaphor for those in management, and perhaps more appropriate goals than I've experienced. My experience is that most managers are simply trying their best to keep everyone happy - mainly those requesting resources (people under the manager). They are also often simply trying to make sure everyone defensibly busy.

It's in the best interest of the manager's boss, though, that resources are used for the most return. This might take some educating or a little pushing. Think in terms of how a financial advisor is both making sure your funds are being put to use, but also often educating you along the way about why he thinks you should move some of your money here or there. This would obviously help get clarity around value - the value of different initiatives, the individual strengths of the people and how to best leverage those, and helping to see that value realized as soon as practical.

Without a clear path to value back to the manager's boss, managers can be left to simply growing their department as a means of validating their value (and therefore security) in the company. But imagine this happening with your financial advisor - "I can't tell you how your funds are doing because I really have no idea, but I have some reports that show how many people report to me."

Introducing Scrum at Your Organization

2011-06-10T08:58:00.000-07:00

A Bad Prescription

I am often asked for advice on how to either introduce Scrum and agile at an organization, or how to roll-out from a given implementation of a team or teams to a broader level, such as program or division level. While there is much to be said on this topic, it is best to start off with the imperative that there is no prescriptive approach that will work for everyone. There are many approaches, some successful despite being counter to standard recommendations. There are important contextual variations, such as company culture, personalities, recent experiences and history, project storyline and product market space that may all play an important part in how to roll out agile in your organization. This section will review some of those aspects, tools you can use, and then get to general recommendations.

Simply, here are the most important points that I have seen be effective:

1. Ask why management wants to go agile. What is the win for them? Define success together. Rally co-creates Agile Success Plans at the beginning of customer engagements.

a. Look at Geoffrey Moore’s adoption curve and mark where you think the company sits. Based on that, what is that group’s standard view of risk?

2. Looking for the natural law win for those involved. Whether backers, decision makers or influential, be sure that you’re aware of or find out what would make this transition a win for each person. Along the way, you should find out, or uncover, what their concerns are (fear, uncertainty and doubt).

a. Take a look at George Schlitz’s presentation on Mapping the Agile Battlefield for a deeper look at this area.

b. The book What Got You Here Won’t Get You There is a coaching-view towards helping managers succeed in change situations like these.

3. Remember that your agile roll-out plan and effort in itself should be agile. Plan it, and then routinely assess what’s working and not working in it, and adjust.

a. Organization change is not complicated, it’s complex. Look at the Cynefin model and remember to gather data, especially people and process narratives and then determine what to do next.

If your company isn’t agile yet, but you want management to consider adopting agile, consider selling it based on the success of other well known companies. That might lighten their risk.

Narrative Coaching Resources from Scrum Gathering Talk

2011-05-15T23:32:00.000-07:00

Below are the books referenced in my talk on Narrative Coaching at the 2011 Scrum Gathering in Seattle:

Narrative Means to Therapeutic Ends, White and Epston, 1990
Narrative Therapy, Freedman and Combs, 1996
Maps of Narrative Practice, White, 2007
Practicing Narrative Mediation, Winslade and Monk, 2008
Coaching Agile Teams, Adkins
Dave Snowden and Cynefin - http://www.cognitive-edge.com/articledetails.php?articleid=65
Switch: How to Change When Change is Hard, Heath

Scrum Doesn't Work for Us

2011-04-22T07:41:00.000-07:00

"...because..." and then I hear a list of how a company, or a team, or a project is 'different' from others out there. This is common, and though there are great assessment tools out there, let me share with you three common issues that I and other coaches see.

1. The user stories are not estimated in points. I've heard lots of explanations of why, or how management doesn't understand points but understands hours, or points-to-hours conversions posted on the walls. In the end, the principle remains that we don't estimate well (just refer to the initial estimates of pre-agile projects). We compare well, referring a current feature or request to a simple, previous one that we know well. Also, estimating hours is often unconsciously optimistic. Not only do we think in terms of ideal, uninterrupted hours, but we don't stop and factor in risk, complexity or unknowns when saying "That will take 8 hours". Estimates are planning Marc and Liz's 2 hour meeting at church on Saturday, story points are planning Marc and Liz's wedding.
2. The team isn't voting on the size. Sam the Helpful Manager says, "Joe's the architect and he just tells us how many story points it is." Well, just because Joe (AKA Smartest Guy in the Room, whether others agree or not) is the architect, doesn't means he's as smart as everyone else on the team combined. No one person can see all the issues, has all the combined detailed experience, has all the creativity and innovation to come up with the best solution. And, worse yet, my experience is that it is less about Joe voting and the team missing out on better sizing, it's more often about pride, power and control. Joe likes his position and title and doesn't want to share power or the stage or 'important meetings' with those less than him. And because the team doesn't discuss and vote on the size, they don't feel or have a psychological ownership of the work. Someone else signed you up "Bob's Crazy No-Pain, No-Gain Exercise Boot Camp" how much will you really be into it? If the team didn't vote it, the team doesn't own it.

3. Don't know that you don't know. This is perhaps the most dangerous because teams think they know what to do and how to do it (but don't). It's like visiting another country and plugging in your hairdryer as a means of learning that voltage is different in other countries (and then blaming the hair dryer manufacturer). The first antidote is having an expert on site - someone trained in agile. The second is getting as many people as possible involved in the agile community (conferences and local events) in order to keep learning.

Humility - The Trait of a Good Coach

2011-04-01T12:46:00.000-07:00

The last few months, I've met several great ScrumMasters and coaches. They understand agile and are helping their teams and organization in very important ways. I doubt that most companies, no matter how big the budget, can achieve success without people contributing in ways like these people are.

Given that people in coaching or ScrumMaster roles often know quite a bit about Scrum and agile, and given that those they are supposed to help in the organization do not know as much, it can become all to easy for the ScrumMaster or coach to feel important because of this knowledge, special, even superior. This subtle form of arrogance may not even been there before, but takes root and grows like a weed as people come to you to ask for information, help, solutions, or advice. And they're not just asking you about technical help, but for teams, departments, and management. How do you feel when you talk to them? When you educate them, direct them, help them, coach them? Are you there to serve them? Arrogance or pride prevents us from being truly effective in coaching by limiting how much we are able to help someone or how many people we can assist.

Arrogance will tell you that you're in a special position of honor and influence, at the top or over others in importance or ability. And you'll believe that having this high place is solely due to YOU (not good fortune or opportunity that others did not get). Pride tries to lure you into believing that its solely because of the effort you have put forth and your knowledge and abilities.

Not that you're effort and natural and developed skills and knowledge aren't important. They are. But would any of us have been in our current position if we were born in Libya or Haiti? For myself, I ask "What if my pervious employer hadn't paid for me to go to Certified ScrumMaster training so many years ago? What if my first big Scrum project had been cancelled after the first week? What if the first full agile adoption had been with an awful client instead of a great one (they had found me, not vice-versa)? What if I hadn't been selected to speak at the Scrum Gathering and Jean Tabaka just happens to sit in my session and we end up talking about Rally? Yes, I hear some of you saying that I helped create some of these "chance" opportunities because I was doing the work - submitting to the conference, leading the first project, going to the training.

But if we fall prey to the fully self-made position, then we'll become convinced that we ARE better because of who we are and choices we made. And everyone else wanting or needing our help? They must be either less talented or did not make good choices. What gets transmitted with this worldview, knowingly or not, is coaching via "Do what I do and try to become like me." And if that is true, then what hope does the one helped have of getting better? If you have arrived, are at the top, the coached try to get better by aiming for the goal, which is...YOU. To improve, they have to think like you, solve problems like you, lead like you, behave like you. They have to become you, because that's the goal. But how can anyone be someone they are not wired to be? How does the researcher become all about action? How does the thoughtful consensus builder become Type A Get 'Er Done?

Also, arrogance prevents us from helping because we're not really listening. We think that ff someone isn't understanding, it's because they're not trying or they're not very smart because it's certainly not because of us. We have all the right answers and communicate the right way, including telling them what to do. The truth is that it's hard to receive from someone who's not really listening or showing that they value and care about what you have to say.

Rather, in acknowledging we are in a position of influence partly due to good fortune and providence, we can know that other people may end up in similar positions for the same, which allows them to be them (and you to be you). They don't have to become like you to be successful. And you can then share what you know from a stand-point of how fortunate you've been, and that you're just paying it forward. You can help because you've been helped. You're grateful for the opportunity to serve others knowing that you just as easily could have been in a very different situation. You teach knowing that you can learn from others, since you're not at the top of anything, but on a path like everyone else.

In an agile leadership economy, we don't raise parity unless we buy into the truism that to those who have been given much, much is expected.

You Have Something of Mine

2011-03-10T22:42:00.000-08:00

I was speechless. What I saw left me dumbfounded, like when you realize it was a trick play and you were chasing the person who didn't have the ball. I had been working so hard for months on proposals for the Agile 2011 conference - hours of collaboration, hundreds of pages of reading, a day long seminar. I've been waiting to hear whether I would be rejected again (for the fourth year in a row) when I saw the hornswoggling statement. A session had been accepted that was a summary of a book very similar to one that I had read. Helpful, yes. But cutting edge? World changing? Revolutionary? No, but that's where I was wrong. And I had been robbed.

Like many others, I'm always learning - reading books or blogs, talking to others and taking notes. New things are always interesting. But that doesn't mean that the old things are not still valuable. Also, those those old things are still new to other people. But that's not where I was robbed.

I was robbed when I listened to the voice that said, "No one's interested in the little things, the common things, that you value. It has to be completely new, completely unique, and obvious that it required lots and lots of effort."

I find that same line keeping me from giving my best to my team. "Don't share that with the team, they'll think its useless. Write up a bulleted summary with all the links. That would be better," "Don't tell him 'Good job!' What until the whole thing is finished, then tell him. It will mean more then," "Don't bring in cookies for the team. They'll think that's corny. Wait and ask the boss for approval to take them out to lunch." All those opportunities to give something good to others are robbed, robbed by the mirage of Great - the gold-plated big-bang delivery of perfection. Perhaps I would be better off to be agile and give out what I have to offer early and often. Which leads me to be my next point.

You have something of mine - some story or tip or example that, although free for you to give, would be valuable to me. Don't hold back. Don't be robbed as I was. Let others decide the value, just like the Product Owners or customers we serve.

One Month to Live

2011-02-28T06:44:00.000-08:00

My friend Brad asked a question last week that struck me so hard that I lost track of the conversation for a bit, lost in my thoughts. What if I only had 24 hours left on this earth? For most of us, it's fairly similar - going and letting all those we care about how much we love them, maybe forgiving some people or asking forgiveness. As powerful as that is, in my friend's opinion, how much more powerful if the question was "What if you had a month to live, or a year?" That question is richer, deeper, because you had time to do something, other than just communicate. You can change. And you can change lives.

Brielle Murray has changed a lot of lives. Barely 13 years old, she has touched many, many lives as she faced RMS cancer for the last three years. She passed away on Friday, February 17 at 9:45 A.M. In her room were still thank you cards and valentines that she was making for others. Brad's question had me going over and over Brielle's short life - here she was thinking of others while facing unbelievable challenges. Perhaps that question is part of the answer.

In our culture of Me First, we don't often think of what's left behind when the Me is gone. And yet, that's what's lasting. Recently, I was talking to a key person in one company's agile adoption and he kept referencing how one executive had made such a difference. When I went on LinkedIn to find out more, I saw that the executive had moved on to another opportunity years earlier. But you wouldn't know it from the way the agilist was talking - it was like the executive was still there. In some ways, he was. That exec was still making a difference through how he had impacted this agilist, and now how that agilist was coaching his ScrumMasters, QA folks, developers and others on the teams he was over.

You can make a difference. You can change lives - the way people view challenges, believe in themselves, respond to failure, treat others. But it doesn't start later. It starts now. It's starts with the focus, resolve and passion you would have if you were just told that you only have months or a year to live.

Below are some resources on how others responded to the same question -

Tim McGraw - Live Like You Were Dying - http://www.youtube.com/watch?v=6xSGLZd9Vg4
The Fray - How To Save A Life - http://www.youtube.com/watch?v=cjVQ36NhbMk
Switchfoot - Dare You To Move - http://www.youtube.com/watch?v=iOTcr9wKC-o
One Month to Live: Thirty Days to a No-Regrets Life - http://amzn.to/hkiXzg
Tuesdays with Morrie: An Old Man, a Young Man, and Life's Greatest Lesson - http://amzn.to/fx1Xsy
Death Be Not Proud - http://amzn.to/eYGti5
Alicia's Story - http://www.sfgate.com/alicia/

Technorati Tags: agile, scrum, coaching, lifecoaching, ScrumMaster

ScrumMaster as Coach: Mentoring & Drawing Out

2011-02-17T11:32:00.001-08:00

In my Implementing Agile Teams trainings and Certified ScrumMaster classes agile training classes we discuss the various roles that the ScrumMaster plays. One of those roles is Coach. Although we usually have a good discussion, there's been a nagging sense that it wasn't complete or as deep as should be.

I had some insight today from Leadership Coaching. Essentially, you, the ScrumMaster/Coach, are tasked to impart, strengthen or correct certain skills and practices. For example, making sure teams have daily stand-ups, but also tweaking and optimizing how it's facilitated, or explaining to others why daily stands-up are powerful and effective tools for collaboration. Perhaps you're helping coach on test-driven development or continuous integration. All great, valuable skills and practices. I think this type of coaching is Mentoring.

But coaching is not just imparting skills and practices, coaching is helping people become someone they were not before. We want, no, expect those on teams to be Open, Courageous, Focussed, Respectful, Committed. We want team members to trust, have healthy conflict, hold each other accountable and attentive to results (to borrow from Patrick Lencioni). We want them to ask powerful questions, collaborate effectively, be servant leaders. But my experience has been that I can't just walk up to a hardcore power-ogre team lead and say "Go forth and be highly collaborative!" or go wave a wand over a 15 year command-and-control PM and say "I bless you with the gifts of Facilitation, Listening, and Service. Go and empower someone today!" These things are not that easy. These involve people changing, not just learning. So, how do you help people change?

It Starts with You

"Becoming a transformational coach starts with being transformed." There are disciplines, skills and heart involved in helping people change, but we'll focus on the heart. As Tony Stoltzfus writes, coaching begins with a heart that radically believes in people. For example, in my training classes, I talk about three levels of listening. Although those are good to know, if you as coach don't value people, it won't matter. It won't work for you. Per , "Coaches don't listen because listening is a good technique…A coach listens because to listen is to believe in you." My sharing about listening skills will only help those who are becoming someone who cares about others. We can not treat coaching as a set of techniques over being - style over substance. If you are just after results, than "technique without heart is manipulation."

I'll share in a later post about some of my practices in trying to become more and more of someone who has this kind of heart. For now, let me encourage you that believe the change we want to see in others already resides in them in some for. The preferred way we'd like to see them collaborate on the team has happened somewhere before and we as coaches help draw out what's already in there. We don't need to prescribe solutions and advice in the area of personal growth. Keep that to the skills and practices.

Mentor coaching is giving what we know. Transformational coaching is drawing out what's already inside.

Assessing Your Learning Needs

2011-01-28T07:35:00.000-08:00

There are lots of resources for continuing to learn about agile, the roles, engineering and test practices and adoption approaches, but where do you start and how much of an effort can you expect to invest? Well, it depends. As a rough guide, use the grid below. Chose one item per column that matches your situation, and score yourself according to the following:

First Row: 1 point each

Second Row: 4 points each

Third Row: 10 points each

Experience Level	Likely Future Number of Teams
Advanced	1 - 3 Teams
Intermediate	4 - 9 Teams
Basics\Boot Camp	10+ Teams
Business or Project Environment	Business, Stakeholder Attitude
Basic Environment	Eager, Supportive
Complicated Environment	Listening, Cautious
Complex Environment	Hostile, Contrary

Add up the values you selected for each column. For example, a common situation I see is:

Experience Level	Likely Future Number of Teams
Advanced	1 - 3 Teams
Intermediate	4 - 9 Teams
Basics\Boot Camp	10+ Teams
Business or Project Environment	Business, Stakeholder Attitude
Basic Environment	Eager, Supportive
Complicated Environment	Listening, Cautious
Complex Environment	Hostile, Contrary

This would yield a formula of 10 + 1 + 1 + 4 = 16

For scores below 15, you may only need to drive through the several items from a few learning areas, and then more at your leisure and discernment on what next from items referenced on this blog or lists elsewhere on the web.

If your score is near 20 or above, you likely need to go through a lot of material of it at a good pace, and those beginners items are critical. Not only that, but you likely need to go through the material with others in your group in some fashion. More on that (Community) later.

If your score is higher than 25, you need to power through all basic and intermediate material, and cover the advanced topics as soon as you can, with several others in your organization. Education will be instrumental, if not critical, to the success of agile in your company.

I'll provide a list of my recommended materials in a follow-up post.

agile, management, scrum, leadership

Meeting with Executives Key to Growing Agile Success

2011-01-20T07:08:00.001-08:00

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.

What I Learned This Year

2010-12-31T07:42:00.000-08:00

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

2010-10-19T06:56:00.000-07:00

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

2010-10-13T06:31:00.000-07:00

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"

2010-10-01T07:32:00.000-07:00

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

2010-09-21T08:17:00.000-07:00

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

2010-08-11T13:47:00.001-07:00

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

2010-05-24T08:18:00.001-07:00

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