Assessing Your Learning Needs

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

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

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

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

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

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

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

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

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

I have learned that being pleasantly surprised is a mindset.

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

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

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

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

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

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

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

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

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

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

The Already and The Not Yet

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

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

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

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

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

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

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

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

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

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

The Principle of the Agile Path

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

People Help Agile Adoptions

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

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

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

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

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

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

Getting Executive Buy-in for Agile

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

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

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

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

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

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

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

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

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

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

Strengths of a ScrumMaster

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

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

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

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

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

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

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

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

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

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

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

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


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

Starting Strengths-Based Teams

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

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

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

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

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

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

Introduction to Strengths-Based Teams

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

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

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

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

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

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

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


agile, strengths, management,Scrum

My Work Manifesto

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

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

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

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

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

Goals for Agile Teams

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

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

My Goals for New Agile Teams :

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

And my personal goals when coaching agile teams:

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

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

Kanban Book Review

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

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

Here are some of my favorite quotes from the book:

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

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

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

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

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

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

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

Technorati Tags: agile, kanban, lean, scrum

Agile Adoption

Several good posts related to agile adoption -

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

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

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

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

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

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

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

Other articles or posts you would recommend?

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

Agile Leadership and Management Presentations

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

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

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

Salesforce.com's Success with Agile

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

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

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

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

View more presentations from Steve Greene.

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

Offshore Agile Teams

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

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

Technorati Tags: agile, offshore, Scrum, software development

Example of Team Agreements List

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

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

Here's an example of a Team Agreements list:

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

Sample Agenda for a Sprint Planning Meeting

Here's a thorough, high-level agenda for a Sprint Planning meeting. Of course, don't use what you don't need...

1. Product Vision and Roadmap [Product Owner]
2. Development status, state of our architecture, results of previous iterations [Team members]
3. Iteration name and theme [ScrumMaster]
4. Velocity in previous iteration(s) [ScrumMaster]
5. Iteration timebox (dates, working days) [ScrumMaster]
6. Team capacity (availability) [Team members]
7. Issues and concerns? [ScrumMaster]
8. Review and update definition of Done [Team members]
9. Stories/items from the backlog to consider [Product Owner]
10. Tasking out [Agile Team]
11. Issues, Dependencies and Assumptions [ScrumMaster]
12 Commit! [Agile Team]Technorati Tags: agile, scrum, sprint, project management, scrummaster, project manager

Iteration vs Release Planning

Saw this simple sprint iteration and releases comparison chart in a Rally training page. I like the line on the difference of focus - release is "what" and iteration is "how." Just keeping that in mind will help guide sprint planning meetings much better. Also, given that the focus of sprint planning is task-estimating, not story-writing, the assumption is that the top of the product backlog (sprint backlog) is well groomed. Taken from Rally's Agile Planning Step-by-Step Guides.

Technorati Tags: agile, scrum, project management

Should ScrumMasters Code?

One of my mentor's believed that ScrumMasters should be programming as part of their general duties. If you're in IT, it's likely you know some piece of the programming being done, and if not, have the ability to learn some small aspect (SQL, scripting, batch files, etc).

As I finish up my first Rails project several months ago, I learned a number of things. In the end, I switched my laptop over to a dual-boot Windows\Ubuntu machine. I'm been using Ubuntu ever since, and only had to use Windows for old specialty apps (and even those now have web-based versions). I'm emailing, exchanging and editing documents, tracking bugs, organizing and prioritizing work all from Ubuntu. The boot time is faster, installing apps is easier, and viewing all my windows greater in Ubuntu.

I went to Ubuntu in order to get the developer's web site up and running on my machine. Along the way, I've learned about Subversion and Git, production vs. dev mode on Rails, and how configurations are saved and published (or held).

On my current project, I've started using soapUI to help do some testing for the QA team members. By reading a few pages of the documentation, I learned how to automate the tests and use XPath to confirm data items in the responses. Just getting that hands-on to know the versions of our WSDLs, the endpoint changes, seeing data and changes in the payload gave me a deeper and stronger understanding of the work (and challenges) of what the team is trying to accomplish.

I have a renewed belief that the agile project manager is much more effective when their hands are in the code at least some small percent of the time.

If you're a ScrumMaster, are you doing any programming? Would it help? If so, how? If no, why not? If you're not a ScrumMaster, but a team member, how would you feel about your ScrumMaster getting involved in this way? What if it meant asking more questions, learning and perhaps even making some mistakes?

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

Kanban and Scrum, Black Box and White Box

This post is a good description of Scrum vs. Kanban - Scrum is a black box (and I'd add "a closed black box", isolated from the Enterprise, but that's part of why it works) and Kanban is a white box. It seems part of the success of Scrum is it's simplicity - you can cover the process, roles and artifacts in 10 minutes. But my experience is that it works best out of the box in small, flat, focused, and/or aggressive companies and needs adjustments for other environments (not thrown away, just adjusting). I've seen some throw it away because Scrum didn't work immediately and easily. Scrum is not a panacea, but commitment and tailoring when needed (e.g., combined with Kanban) will still bring success.

Technorati Tags: agile, scrum, kanban
Trackback: http://www.typepad.com/services/trackback/6a00d83452ee9169e2011571fcf307970b

Improving Retrospectives

For years I've done the classic retrospective at the end of each sprint, asking the team "What worked? What didn't work?" or "More of? Less of? Start? Stop?" But I tried some new techniques recently, and the response was much better.
Most importantly, I used several ideas listed and described in Agile Retrospectives. To start, I asked the team members to choose one of four categories to represent how they felt about being there. This helped to focus and confirm what they hoped to get out of the meeting. I then clarified our values, updating our team agreement with this key, guiding information. The last thing I did was have each of the team members write down 5 idea for improving our scrum. After collecting their papers, I wrote them down on the wall and had the team come up and cast four votes per team member (we had about 20+ ideas).
Throughout the rest of the week of sprint planning, their clarified values and top ideas/problem solutions were referred to again and again, and really helped to shape and guide how the user stories and acceptance criteria were crafted, as well as how the tasks were broken out.
You can also use the "What worked/didn't work" at the end of any recurring meeting in order to improve it the next time.
I highly recommend Larsen's book. The return on investment for improving your retrospectives is significant.

Looking Outside for Ideas

As much as people want to "think outside the box", it really is very difficult to think of an idea or a viewpoint that you wouldn't naturally think of.

As recent Wall Street Journal article describes how Campbell Soup is looking outside for ideas (MarketingProf's summary here). This same approach that a gold mining company took is described in detail, including the great results, in Mavericks at Work.

If this is a good, successful idea, how are you doing it? Scenarios could include asking a Scrum Coach to review your work (your product backlog, sprint backlogs, user stories), setting aside time regularly to read on the topics you're involved in at work (Scrum, QA, automation, tools, the business sector you are in), and setting up periodic meeting-of-the-minds, whether trusted colleagues, a conference or seminar.

I have not once regretted the time I have set aside for any of these. There are always new ideas that I never would have considered that were immediately application to situations and challenges that I was facing. Yet I still don't make it the priority that reflects the value it is.

How about you - where do your ideas come from? How do make sure you put things in place that help you at what you do?

Story Card Template

As I was setting up another new project in a tool I use, I reviewed the default template used for the story cards. Although I always only use parts of it depending on the project, I think it's good to review all of it each time to consider what the needs of the new project are, rather then be unthinking somewhat and stick with "what works" in a general sense. The template follows:

Story Card Description

The 2-3 sentence version of what the card is about

Business Context

Why is this valuable to the business? What is the goal?

Scope Exclusions

Call out anything that is explicitly not included in the card that could be inferred.

Prerequisites to Card Development

* Other story cards that need to be played first
* Data requirements

Detailed Story Narrative

Step by step description of the happy path scenario. Can be numbered or bulleted. Alternate flows can be captured in the acceptance criteria.

Validations

Include any special business rules or validations here.

Authorization

Include special security requirements here.

UI

Indicate what views are impacted by the card. If possible, include a reference to a low-fi prototype.

Additional Notes for Developer

Include any additional notes that you would like to include here to help the developer understand the context of the card.

Open Issues

Include any questions or open issues that we don’t know the answer to when writing the initial draft of the card. Often phrasing the issue as a question and following it up with the solution clearly labeled as the ‘Answer’ helps with readability.

Sample:

Should there be any restrictions based upon the party being a minor, a fatality or having legal representation?

Answer: No. At this point in time, the business has asked for this as a convenience feature that will always bring them directly to edit mode. Even when these scenarios occur today, the Contact Tab is filled out and the Contact Notes will indicate details about the contact (i.e. spoke with the parents of this party or the next of kin).

Acceptance Criteria

Things that the BA will verify during card signoff. Will be used as the starting point from which QA will expand when creating their test cases.

Scenario 1: Description of Scenario

1. Step 1 to demonstrate the criteria
   
2. Step 2 to demonstrate the criteria
   
3. Step 3 to demonstrate the criteria …
   

Problems with Mingle Project Management

I like Mingle, but it's not perfect. I've posted a few times about the benefits of using Mingle, so now I'll mention the problems.

We had read of performance issues, but I experienced where the cliff is. We have Mingle running on a virtual server with 4 GB of memory. We created a custom project using one tree and approximately 15 fields in the card. As we approached 1200-1500 cards in the project, performance dropped significantly. Users could count to 10 - 30 before items loaded, especially in grid view. As we neared 2000, grid view failed completely. Users new to Mingle started asking for another tool. Stakeholders in planning meetings would lose their patience waiting on it. My advice is find a way to keep bugs and features separate. Delete old, fixed bugs, and be disciplined to keep the features list (product backlog) short. Why keep low priority items when there are months of highs in the list?

Exporting data is a pain. Cut and paste text into Excel gets you by, but you can't use any filters (WHERE clause) nor choose what fields to include or exclude. You get it all. Massaging it into something useful for management can become hours per week if you have large backlogs.

As far as I can tell, you can't enforce data integrity. I tried without success. And garbage in\garbage out feeds the two items above that can become a monster.

The project templates look wonderful (XP, Scrum, Agile Hybrid), but there's only one thin page of documentation on their site for each one on what comprises each template. Trying to figure out how to use them (what the workflow is, the objects, details) is essentially up to you. Don't get me wrong - I really appreciate these views into how Thoughtworks does agile project management, but as I kept poking around, feeling like I was trying to put together the lifestyle of some ancient race based on artifacts, I kept thinking, "The creator of this template could have taken one day to document it and the whole world would be ready to go." As is, the whole world will play Sherlock Holmes and my guess is many will give up and go to what they know and lose out on a great agile mind-share opportunity.

agile, scrum, xp, extreme programming, project management, mingle

Agile Planning Poker Rules

I posted earlier on planning poker, and since it's a popular post, I thought I'd post again on it.

One item that came up in a recent sprint retrospectives (in the "Where do We Need to Improve?" list) was getting better requirements and estimates. So, after the following planning meeting, where the CEO selected his highest priority items, the team met to review those items.

The meeting seemed to be another poor meeting of nothing definite or different being done - lot's of "Well, I'll need to look at that one more," or "Well, management says it needs to be done by next week, so what does it matter how long I think it will take?". I was ready to call the meeting until Martin asked about the planning poker cards (shwag from Phil Scott at the Agile Panel Discussion at the LA Code Camp). He hadn't used them before so we walked through the instructions:

1. Each team member is given a set of cards.
2. One person read the item to be estimated.
3. The team & customer discuss the item.
4. Each team member privately selects a card representing his/her relative estimate.
5. After all have chosen a card, everyone shows the chosen card.
6. If all estimates match, that item's estimate is complete.
7. If estimates are not the same, the group discusses the differences (focusing on the outlying values).
8. Repeat until consensus is reached.

Few notes on modifications we made to the rules -

• We don't have any business members there, but call in the requester if needed.
• We re-estimate until within one card value of each other, or take the median value if there's a majority.

The team really enjoyed, and benefited from the experience. The secrecy of each persons' pick not only made it fun for them, but it got each person so plugged into the task at hand. There was kidding of those who's estimates were way outside the norm. For outrageously low estimates, we rewarded the low-bidder's confidence by giving them that task, but with an agreement that if they met the estimate, we'd buy them lunch. It was particularly enjoyable to see how much this engaged Jeoff, our only team member with the strength Competition. There was great discussion on all the tasks the team had ahead of them, and we left the meeting with a lot more shared knowledge, both where we're weak and where we're strong.

You can buy planning poker card sets from Mike Cohn's Mountain Goat Software site.Technorati Tags: agile, scrum, project managment, software, team building

Agile Leadership Coaching Quotes

I was at a leadership coaching event and had these quotes as good takeaways. Although the training wasn't specific to agile environments, I think they all apply quite well.

• It's a leader's job to make the goals clear, and the team's to make it work. 
  
• In a dynamic environment, it's more important to have strategic positioning than strategic planning. 
  
• The fix for bad leadership isn't teams or teamwork, it's good leadership. 
  
• You don't know what you're capable of. 
  
• There's often a gap between information and application. 
  
• What are your growth hashmarks? Because speed acclimates and it will be hard to tell if you are growing as a leader or not.
  
• The ideal situation is the right job [or role] + the right mindset.
  

Agile Project Management Tools - Mingle, Rally, or...?

I previously posted on comparing different agile project management tools: Mingle, ScrumWorks and an Excel file with dates, hours and a burn down chart. After hearing several agile consultants at Code Camp, I thought I should pass on their (better?) response. 

The question on a tool recommendation came from an audience member who said they had been using Rally, and end the end required one person full time just to manage the tool and data. KenKolcheir, who works for ThoughtWorks, obviously recommended Mingle, with a laugh, but I heartily agree it is a great, easy to use tool. Denise Phillips recommended VersionOne.

But the consensus from all the panelists was to keep it as simple as you can. If you can get by with cards on Post-Its stuck to a wall, do it. Also, this method provides a ready "information radiator" that helps visibility, communication and focus for those nearby or come and go interacting with the team. If you choose to use a the tools from ThoughtWorks, Rally, VersionOne, or Microsoft's Team System 2008, it would be very helpful to have a large monitor or fatscreen on the wall with your cards or a dashboard (with burndown, etc) as the information radiator.

I tried Post-Its, but switched to Mingle so our CEO could access the product and sprint backlogs from his computer and be more directly involved. This is what we needed and has been a key to the success of the organization really getting behind scrum.

USC SoCal Code Camp Presentation Docs

Below are the handouts used for the presentations at the SoCal Code Camp at USC. 

Session 1 - Leading a Team and Developing Team Members - Currently or hopefully leading a small team, managing a project, or over a department? We reviewed the research from several top management experts including Jim Collin's Good to Great, Marcus Buckingham's First Break All the Rules, and Ken Blanchard's One Minute Manager. Using agile as our team context, we reviewed leadership, management, the difference, and what is the role of management today when agile teams are self-managing - the Agile Manager and organizational change. The handout is here. 

Session 2 - Agile Scrum Method with Strength-Based Teams - This session was an overview of the Scrum agile process, tools I've used such as cards and Mingle, and highlights a strengths-based approach which takes advantage of using team members for tasks and roles where they are more likely to excel. Scrum is simple (but not easy) and a tremendous help to achieving success in projects. Agile environments are designed to capitalize on each individual's unique strengths, but there's not much guidance out there on how to do this. This workshop reviewed the different approaches and levels I've used with a strengths-based approach on my Scrum teams. The handout is here.

Session 3 - Discovering Your Strengths - What are you naturally best at? How can you leverage that to become world class? It might be innovation, bringing out the best in others, or knocking out task after task. Many of us don't know our strengths, much less how to build our work day and careers around these natural talents. Instead, guided by our managers and others, we become experts in our weaknesses and spend our lives trying to address these "areas for improvement", while our strengths lie dormant. We review some of the book StrengthsFinder 2.0 and watched the first of six videos from Marcus Buckingham's strengths video series. We covered how to leverage your strengths and how to continue to develop them. The handout is coming...

Session 4 - Agile Panel Discussion with Phil Scott - Neudesic, Denise Phillips, Paul Hodgetts - AgileLogic  and Ken Kolchier - ThoughtWorks. No notes yet but I will try to collect the questions and answers. 

Code Camp Connections

If you are coming to the SoCal Code Camp, you can stay connected to others through the SoCal Code Camp group on LinkedIn. Click here to join and connect with others who are a part of it. Also, you get get real time updates and join the code camp conversation on Twitter. Click here and then click Follow.

Agile and New Ideas for the Enterprise

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

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

Book Review - Agile Software Development w Scrum

ASDS is a very good book, but only for the few who want to be Scrum experts. The material is thorough, and not necessarily easy to get through, in part because the Schwaber and Beedle walk through every part of Scrum in detail, as well as cover situations that likely don't apply to most, and they even go through philosophical views that some may care little about.

To be sure, there are gems in the book, and I learned a few important points, but I have been to ScrumMaster certification training, read two other agile books, and been mentored by a CSM/PMP. I feel the book only moved me from 80% comfort level with Scrum to 85%.

If you are a consultant managing projects, or you want to teach, coach or train in this area, read the book. If you a internal project manager,product manager, or IT manager, I recommend you get Agile and Iterative Development: A Manager's Guide and read the section on Scrum. It's simpler, cleaner, and the rest of the book gives good background to agile and options you may want to consider.

If you are a team or development lead, or the senior developer, get Agile Project Management with Scrum. It's an even easier read, focused solely on Scrum and gives lots of enjoyable stories of real situations the author went through, good and bad.