The Best Team Building Exercise

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

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

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

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

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

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

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

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

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

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

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

Building a Heathly Organization

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

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

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

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

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

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

"Looking for my earrings," she replies. 

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

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

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

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

Organizational health is the multiplier.

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

A Slice of Humble Pie

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

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

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

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

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

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

A Sample iCal Calendar for Meetings in Scrum

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

Sample Sprint Calendar

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

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

• Sample Sprint meeting schedule - iCal format
• Sample Sprint meeting schedule - PDF file 

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

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

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

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

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

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

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

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

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

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

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

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

Who Should Be the ScrumMaster?

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

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

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

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

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

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

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

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

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

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

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

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

Common Scrum Questions

I recently did an agile overview for a company's IT group, and was again surprised by the number of questions that could be answered by someone attending a Certified ScrumMaster class and, living out the role as educator, lets the team and others know how and why Scrum works. I'll go through the more common questions on my blog over the next few weeks.

Here's a few questions I see commonly.

1. Who should be or become a ScrumMaster? That is, which role: project manager, lead developer, functional manager, anyone but one of these roles?

2. Should the ScrumMaster be telling us how to do our work?

3. Does Scrum really work? I had a friend that worked over that Company X, and it was all messed up over there.

4. What's the right way to do Scrum? I worked at Company Y where they did Scrum, and my friend at Company Z does it a different way.

5. What about budget?

6. Our teams are distributed and remote. Can Scrum work for us?

7. How long until we start to see improvement?

8. Should we still have project managers and a PMO (project management office)?

9. I'm in QA, and this Scrum stuff stinks for me. I'd rather have it the old waterfall way.

10. Do we still need to do requirements in agile?

11. We don't have a Product Owner, but we know what needs to be done. Can we still do Scrum?

12. Management says we still have to hit deadlines that were set 15 years ago. Isn't that not really agile?

13. Is the ScrumMaster a fulltime role? What about what I used to do?

14. What if some of our work is dependent on people in other departments, like Operations (and they don't care that we're in two week sprints!)?

15. What if there are dependencies on other Scrum teams, and our commitment is dependent on them getting their stories done?

16. How do we do good architecture without doing some sort of good (or good enough) design upfront?

17. What do we do if our stories aren't complete at the end of our sprint?

I'll answer these, and more, over the next few weeks.

It's Not Scrum, It's You

I was recently teaching a Certified Scrum Master class and was told by a student that Scrum didn't work because management still comes and demands additional features or projects and sets or keeps the deadlines and not asking for estimates of how long it will take. 

That is not a Scrum problem. That's a business environment problem. And the solution is often the person lamenting it the most. Perhaps it's like the guy that complains about women because he is married to someone who makes demands and doesn't respect him. It's not women that's the problem, it's his allowing his wife to control him. 

These are the type of complex organizational development problems that are difficult to solve. They take more than a two day class on Scrum fundamentals to solve. They may be very difficult and take a long time, but they are possible. Don't think that they are not. There is a world of difference in the mindsets behind possible and impossible.

If you fall into the trap that they are impossible, you give up trying - looking for possibilities, options, trying out new ideas. You lose hope. Certainly if you are a leader, it is incumbent upon you for the sake of the people who follow you. The book Strengths Based Leadership lists the four needs workers have of their leaders: hope, stability, compassion and trust. If you are an agilist, you are acting as a servant leader, and therefore need to maintain hope. 

I couldn't tell this student how to solve his problem - that's contextual and that's why there are coaches helping organizations with these types of cultural and management changes. Even without a coach helping, there's a lot of places to look for good information on this.

But you won't take that first step if you are stuck thinking it's impossible. 

Recommended Reading for January

John Deere's agile success story - Not mentioned is that they have 105 teams all on two week sprints and 8 week release cycles. In one year, warranty expenses are down 50% and there's a 20% increase in first-to-market features. Read more on the blog of their agile transformation lead, Chad Holdorf. Dean Leffingwell helped John Deere, and his enterprise approach is covered in his great Scaling Software Agility session at Agile2011.

The SOPA and PIPA protests were impressive and effective, but there's more. Noted author and technologist Joel Spolsky writes about what's next. Also, we may see the birth of something truly transformative as crowdfunding becomes a platform for the common people to be heard in Washington. And in case you're wanting something to have a voice about, here something from the NY Times on how we have not taken care of the least among us.

Photos of dozens of agile team rooms. Great for ideas of how to improve your teams' areas.

Almost a dozen helpful agile tools (burndown charts, Kano analysis, checklits) available on Paul Hodgetts' site.

For those into strengths, here's a great review comparing Marcus Buckingham's new strengths assessment StandOut to StrengthsFinder, and a great interview of Marcus on StandOut, his strengths assessment and strengths in general on Drucker on the Dial.

And, on a related note, the 360 performance review is flawed because it, as a relative assessment, only says if the person getting surveyed is more or less compared to the preson asked.

Lots of interesting things coming out of Agile Leadership Europe. I particularly like the fun idea of Bathtub Conferences. Bit of info on ALE, and a rant, from Jurgen Appelo.

Need some recommendations for reading? Here's a nice, commented list of best business books in many categories for 2011, 2010, and on.

And last, do you know anyone who pair programs 40 hours a week? What if it was remote pairing? Videos, slidedecks and more on pair progamming, along with great presentations (and presentation surveys).

Looking Back at 2011

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

Must Read

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

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

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

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

Insightful

Mindset - The New Psychology of Success

Interesting 

The Black Swan - The Impact of the Highly Improbable

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

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

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

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

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

And ONE "Must Attend" conference:

The Leadership Summit

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

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

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

Agile Presentation - Dear 31 Year Old Me

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

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

Deck available here - 

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

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

Three Simple Tools for New Teams

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

Photo by Greencolander via Flickr.

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

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

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

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

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

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

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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

1. 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. 
2. 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.
3. 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.
4. 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. 
5. 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

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

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

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

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

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

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

Overcommitment

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

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

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

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

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

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

Dealing with Challenging People

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

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

Bill broke down an approach in the following way:

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

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

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

The Idea Lifecycle Diagram and a Defeated Mindset

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

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

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

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

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

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

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

Hybels left everyone with a challenge, 

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

Also, check out this great summary of Hybels talk. 

Summary of Agile 2011 Conference

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?

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

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.

1. Have they been a ScrumMaster on a team?
2. Have they been the ScrumMaster on a project in Scrum from inception to completion?
3. Have they worked in 1, 2 and 4 week iterations?
4. Have they been the ScrumMaster on a  project with distributed team members or with a vendor?
5. Have they introduced Scrum or agile to an organization where it was new? Specifically:
6. Did they train team members on Scrum? 
7. Were the teams fully-dedicated, cross-functional teams?
8. Did they work with department managers on team composition, managing team members and other changes?
9. Was there a PMO in the organization? Did they work with them on the agile roll-out?
10. Did they initiate and facilitate release planning?
11. Have they lead a multi-team roll-out? 
12. Have they coached other ScrumMasters?
13. Have they facilitated multi-team release planning?
14. Have they collaborated with company leadership on crafting an agile adoption plan?
15. 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

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

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.