Learn from Project (and Life) Mistakes Using the 5 Whys

You don't have to be using Scrum to have regular lessons-learned sessions on your project. I think these meetings, called Retrospectives in Scrum, are more helpful when you've gone through the entire  Define-Build-Test-Acceptance cycle, but they were all too infrequent when at the end of my traditional projects.

When journaling this morning, I found myself doing the 5 Whys for root cause analysis on something that happened yesterday, and I thought it might make a good (although somewhat painful and embarrassing) example.

Problem: I went the wrong way on Interstate 10 yesterday and it changed my 1.5 hr drive (left early) to 3.5 hours. Why?

1. I didn't put the map directions on my phone to navigation mode. Why?
     A. I didn’t because the battery was too low. Why?
          1) It was low because I didn’t charge it at the client. Why?
               a. I didn’t charge it at the client because I didn’t have a charger in my backpack. Why?
                    I. I didn’t have one in my backpack because we don’t have a spare at home.

Solution: Buy one and keep it in the backpack for client use only.

How would this look on your project? Here's another real example.

Problem: Requirements keep changing (sorry if none of you can relate...). Why?

1. The team makes assumptions that are later found to be wrong. Why?

     A. The Product Owner doesn't put in enough detail. Why?

        1) He doesn't have much time since he's on the road visiting clients. 

Solution: Long term - Find another Product Owner who can dedicate more time. Short term - have a Business Analyst flag and clarify the product backlog item requirements that are thin. 

Although great for projects, these are also great for life (and when's the last time you took time out to work on your life?) Here's some for you to try:

1. I, or significant others, feel like my work-life balance is way out of balance.
2. I'm not motivated, much less inspired, with my current job and workplace.
3. My job/this project is too chaotic.
4. I don't feel like my team is close or acts like a real team (unity, group decisions, comfortable with each other, clear purpose). 
5. I/we keep repeating the same mistakes.
6. I don't feel that I'm growing in my career and/or personally.
7. I don't feel I've done anything significant (worth mentioning in my Christmas letter) this last year, and next year looks like it will be no different.

If some of those resonate with you, try the 5 Whys on them, and look at resources such as the Storyline conference, The War of Art, Drive, The Leadership Summit, Love Does, or your personality and strengths with Myers-Briggs (free), StrengthsFinder or Action & Influence. 

If you're a ScrumMaster and wanting to grow, I'll be having a something out soon that provides small, actionable steps, day by day. Reach out to me and stay posted. 

Great Product Owner Resources - Primer, One-Pagers & Posters

Just yesterday someone asked if I could clarify the role of the Product Owner in Scrum. The engineering team was saying the the Product Owner has to be the Business Systems Analyst. Not necessarily. I replied and included my favorite Product Owner references. Enjoy - 

My favorite primer is What Every Product Owner Should Know from ScrumSense - http://www.scrumsense.com/wp-content/uploads/2011/02/Product-Owners-Manual.pdf

Great one-pagers from Agile Learning Labs - http://www.agilelearninglabs.com/wp-content/uploads/2010/06/what-is-a-scrum-po.pdf and http://www.agilelearninglabs.com/wp-content/uploads/2010/06/as-a-spo-you.pdf

And my favorite poster by William Gill, shared by a Product Owner at ServiceNow - http://williamgill.de/2012/10/01/the-product-owner-the-poster/

Product Owners Caught in the Middle

In my Certified Scrum Product Owner class yesterday, the top question on people's minds - agile adoption. The PO's want to know what's expected of them because often it's IT or top leadership dictating (but not always leading) the agile efforts, not the product group. And Irvine, Anaheim or all Orange County is not that different from most of the US. We're in the Late Majority segment of adoptees and its just harder. 

Perhaps the Scrum Alliance needs a class on just adopting and scaling, like the Scaled Agile Framework (SAFe) or other proven patterns. In the meantime, I reply with "Its hard. It takes a long time. There's options. You'll needing coaching. And there are very, very few good coaches. Good luck to you."

The Unanswered Offshore Question, Pt 2

So, how do you know if your offshore team is as productive on onshore, and therefore saving money (as is typically the primary reason for offshoring)?

Work from one backlog (combine backlogs if working from more than one). Without specifying which team would do which story, have both onshore and offshore teams participate in sizing, or estimating, from one larger pool of user stories. You may do it together, or start by doing a few together and the rest separately. In the end, sample enough of the stories that both teams agree on how many story points various stories are.

At or before the planning meeting(s), randomize the stories or alternate each team getting whatever story is the next one pulled. At the end of the planning meeting, you'll have an estimated amount of work for each team, which gives you an idea. At the end of the sprint, you'll know for sure. Even with various issues (no product owner, newer/smaller/etc team), you'll have a number.

If you can't have both teams estimate and pull work without upfront planning or designating due to resource, knowledge, or other silos or barriers, I think you have other problems that Scrum will fix (if you want it and let it).

Thanks for all the great feedback from the first offshore post (and all the spam comments for offshoring ;-)

Business Wolves in Agile Clothing

Sorry if this upsets anyone, but I'm going to be transparent about something I've been wrestling with ever since I've gotten into agile coaching and training. These are just my thoughts as I'm processing them. I don't have a concise summary, and certainly not an answer, for it. But I'm hopeful it will resonate with like-minded people in the community, and perhaps, together, we can change the world of business.

I understand that most of the world behaves in ways that are not transparent, open, respectful. They used processes and tools, such as $100 Billion in ads or commissioning sales forces (odd, because we don't give programmers commissions for doing more work) to do get more business. And most business grows their business for no other purpose than to make more money and grow more.

Yet we know it shouldn't be this way. Seth Godin makes fun of the Revlon and Betty Crocker model. Daniel Pink warns of when the profit motive gets unmoored from purpose (which we all need).

And as agilists, I always felt it was going to be different because our work was values-based. We'd be freed from the profit-driven model, and we'd show the marketplace how it could be.

I mean, how do you teach about collaboration over contracts and then ask someone to sign a large contract? How could you work intimately with others while not having the openness or respect to let them know any of the business agreement details - the dollar value put on your service by the customer vs. the value from your business partner? What about teaching about the importance of sustainable pace, while putting three times the standard working hours? Where is courage to tell a client that there are others who could provide the same services you provide and letting the client choose what they think is the best for them?

Below is a fictional conversation stitched together from many that I and others have had.

--------------

A customer needs help and asks ACME for coaching. ACME doesn't have a coach, they hire on a contract basis. ACME doesn't tell the customer this, but says "We should have one available in about two weeks." "Great!" says Customer.

ACME then calls up Joe Coach. "Hey Joe, this is Don. Are you available for a coaching contract? We have an excellent opportunity. You're the best one out there, and we'd love for you to be part of our team on this." 

"Sure." 

"Okay, let me send over some documents and set-up your email account real quick. "

"Email account? Why?"

"Because you're doing it under our brand."

"Okay, but why as ACME and not just me, a trusted partner brought in via your valuable network?"

"Because we found the client. It's our opportunity."

"Yes, but I'm known for [X], and that might be confusing when you guys are known more for [Y]. I'm happy with the rate you're offering, and that is monetary compensation for the lead, but I'm confused why you want them to think I'm ACME, when I'm not. I'm not right now, haven't been, and even when I'm there, I'll only be introduced by the ACME sales rep and handed off. You don't offer anything in the way of supporting me on the engagement, do you?"

"Ummm..well, no."

"So I'm not really ACME, am I? I'm a subcontractor. Since we both teach about transparency, shouldn't we model it ourselves and be transparent about the arrangement?"

"Well that's different. This is business."

"Aren't we helping businesses become agile? This might be an opportunity to help your business be more agile, too."

"Look, we landed the deal. It gets arranged according to how we want it set up. The name it's under matters because that's what we use for further lead generation."

"Uh-huh. To get more opportunities that you can't staff. I see. It's your deal, but aren't we partnering on it? You said I'd be part of your 'team', so doesn't that mean collaboration over contracts? 

"Look, I want to grow the business. It's that simple. Same as everyone else."

"Why?"

"What do mean why?!"

"I mean what's the purpose in more business? We both know the importance in purpose in work, the big vision. What is it for ACME?"

"Our mission is to be the market leader."

"So that you can…what? Let's say you became the market leader tomorrow. How is the customer, the market, the world any better?"

"Look, it doesn't sound like this is going to work out, and we're not really getting anywhere with this interesting conversation."

"It seems to me that you need to wrestle with some tough questions. It's just my observation, but it appears that you might be teaching principles that you don't fully practice, or perhaps even fully believe yourself. The short term goal of immediate gain overshadows any core values. It seems like the same problem we're trying to help business avoid. We're all on a path that is taking us somewhere. Where will we be in one, two or five years? Is it success, or significance? I understand we're not on the same page now, but I hope we can keep this dialog going. I appreciate the offer, nonetheless."

Don gets back to say inform them there's a delay on getting the coach in there due to some reason other than the real reason. 

The Unanswered Offshore Question

Student: "But how does agile work with offshore team members?"

Me: "Well, let's start by asking another question - 'Why are you offshoring?'"

Student: "It was a management initiative."

Me: "Why?"

Student: "To save money. The hourly rate is lower."

Me: "But agile depends on high team interaction and collaboration. This change in how work is done might have changed the economics of the decision. How do you measure how productive those offshore teams are? That is, how do you confirm that you are indeed saving money?"

Student: "Ummmm…I don't know."

I've asked this question dozens of times. Always the same answer.

When I am coaching clients, and ask management about this, and most of the replies are essentially "It was the VP's decision, and it's not to be questioned or challenged." Considering that the VP lobbied for it as a good decision, it may not be something most would like to look into and find that they were actually wrong about that $6,000,000 decision (multi-year deal given the resources I've seen). 

The only hard numbers we traditionally had to make a ROI decision on offshoring was the hourly rate, typically somewhere from $40 - $60 for developers, and I've seen as low as $20 for testers. Seems like we're saving money, given the typical $100 - $120 rates I've seen for US developers. But what if those developers don't get as much done due to the fact they can't talk to the subject matter experts and other team members in the U.S. (at least not much of the time, and not without delays, and rarely face to face)? If agile depends on that kind of collaboration, aren't we setting the offshore team member up for frustration and failure? 

Add to this the aging of the decision data. A senior manager in India recently told me, "Those CEO's in the U.S. made the decision to offshore based on very old data." Ten years ago, he told me, you could get a ridiculously brilliant 5 Star engineer in India for 1/10 the cost of the same in the U.S. Many companies rushed into India to take advantage of this - taking all the 5 Star/One Tenth engineers (Such a deal!!), then moving quickly to the 4 Star/Three Tenths engineers (Pretty good business decision). Then large outsourcing shops and system integrators rose up to take advantage of the great staffing and consulting business opportunity. By bundling long term, large team deals, they smoothed out the bumps that they were starting to run into with 3 Star engineers and a moderately lower rate. Now, my friend said, it is very hard to find good to great engineers, so the U.S. is being offered 2 Star (and sometimes even 1 Star!) engineers for a rate that might look like a deal on paper, but these engineers are often not as good as most U.S. company's own developers, AND we using agile. 

A year or two ago, I was coaching a team that was waiting to start their project after they go the resources from the offshore partner. But there weren't any. We waited several weeks before they got one potential to be interviewed. The interviewee didn't pass the technical interview. Not even close. Nor the second, third or fourth. Finally, nearly three months into the original project schedule, the team compromised for fear of either having the reschedule or cancel the project.

If don't get the benefit from the cost/benefit analysis, is this truly best for the company? If we extend the team to realize the value for a project, because it takes 50% - 100% longer due to communication exchanges, the value itself is diminished. And the hidden cost of the quality of resources is certainly higher than the information and stories based on 5 - 10 year old projects. 

And if a company is saying that going agile is a strategic decision, we have to look at the offshoring decision to see if that is best for the teams and therefore the success of agile.

My next post will be on how to objectively, quantitatively and qualitatively evaluate the productivity and cost effectiveness of the offshore teams.

Most Popular Event Ever? Free September Lunch on the Scaled Agile Framework

There's a September lunchtime event in Los Angeles (El Segundo) put on by Rally that will give a good enough overview to understand the basics of scaling agile including Vision, Strategy, Roadmaps and using the Scaled Agile Framework, and how it incorporates agile portfolio and program management.

I've been mentioning in my ScrumMaster and Product Owner classes that I really believe SAFe is the next wave, especially for large, Late Majority (risk averse) Scrum and agile adopters. My opinion was validated when a recent enterprise tool vendor said that their recent webinar on SAFe was the most popular EVER!

I recommended taking a look if you either:

1. Aren't familiar with the SAFe, 
2. Have more than 50 people involved in one project or program, or 
3. Don't have your program or portfolio management tooling directly connected to your agile team's data or 
4. Aren't currently using rolling wave planning via strategic portfolio allocation.

I covered part of this at the Orange County PMI event in July on Agile Portfolio Management and the Scaled Agile Framework.

If you are interested in becoming certified as a SAFe Agilist, or using the 15 credits from the class towards becoming a Certified Scrum Professional, take a look at my Leading SAFe class in November.

Scaled Agile Framework - Is it Agile?

I was observing Mike Cohn's Certified ScrumMaster class today and noticed that when he listed everything under the agile umbrella (covered by the Agile Manifesto), he mentioned the Scaled Agile Framework (SAFe), as well as XP, lean, kanban, Disciplined Agile Delivery, and others. I agree, but not everyone does.

I'm including a great post on supporting points for the Scaled Agile Framework from author, popular speaker and originator of SAFe Dean Leffingwell. The post also includes links to articles on InfoQ and NetObjectives.

Personally, I appreciate what tooling can now do to support real-time decision making from portfolio through program management to teams. See Rally's support for SAFe and a nice post 41 Things You Need to Know about the Scaled Agile Framework.

My Agile2013 Recommendations

Here's my recommendations for sessions at the Agile2013 conference next week. -

Creating and Sustaining High-Performance Teams through Team Cultural Understanding (Peter Saddington)
Peter has done and pulled together fascinating work related to the the science of teams and personality testing. On top of that, he is a VERY energetic, passionate and charismatic speaker. This session is already full!

What is Devops? (John Willis) DevOps has a lot to offer pure agilists, and brings a new and beneficial mindset and solutions to operations and the dev-to-operations mindset.

User Story Mapping in Practice (Steve Rogalsky) If you've never done user story mapping (Product Owners!), it is a great, powerful tool for the team to see the whole and to carve out cohesive, complete and minimal releases.

Self-Service Build and Deployment at Netflix (Gareth Bowles) If you want to hear about DevOps in real life, this would be a great spot to be.

Conflict Facilitation as a Leadership Skill: A Systems Approach for Leaders & Coaches (Michael Spayd, Lyssa Adkins) Lyssa Adkins is both a Certified Scrum Coach and certified with the International Coaches Federation, as well as the author of the often recommended book Coaching Agile Teams. If you haven't put your toe in the waters of coaching, this would be a great session to check out.

Designing Empathy--Learning to Walk in Your Customer's Shoes (Jean Tabaka, Robyn Mourning) Empathy is gaining attention in the business world for the value it brings, and the work at Stanford's d.School is cutting edge and making an impact.

Empirical Leadership: Proven Alternatives to Agile for Executives (Christopher Avery) Getting management's support is key, and being able to speak their language is a huge advantage. Christopher Avery knows his stuff. Take the opportunity to expose yourself to his work and ideas.

The Agile Cognitive Bias: How our internal models affect the problems and solutions we see (Manoj Vadakkan, Bob Payne) We bring in biases continually, typically unaware. The little time I have spent in this area has been very rewarding. Additionally, I respect the work that Manoj and Bob have done, and them personally as well, serving the agile community and others.

The Storytelling Battle : To Lead A Change , Create Its Story (Oana Juncu) The feedback (and requests) I often get in my classes are about the real life stories. Most of us in IT, though, often try to win people over, or arguments, with only logic, and even then by often relating to theoretical situations. Much more powerful to tell stories, and this is an area where a little time spent will add a lot of value.

Agile Requirements & Product Management (Jeff Patton) Jeff Patton is THE Agile Product Management guy, scary smart, and one person's you just HAVE to do.

So You Want to Do a Startup! (Abby Fichtner) You may not be starting a company, but this is a great session to hear about Lean Start-up, which I believe is one of the next big waves.

Agile at scale at Spotify (Joakim Sundén, Anders Ivarsson) Spotify has been very successful as a business, and their means of scaling has been interesting and already a pattern used by other companies. Definitely worth hearing their story.

Active Listening for Agile Coaches (Chris Sims) ScrumMasters, go! I used to touch on this in my Certified ScrumMaster class, but an hour deep dive is the way to go, and Chris is a great, interactive, funny and knowledgeable presenter.

Leading Agile Engineering: Helping Your Team Improve Its Ability to Ship Software (Arlo Belshee, James Shore) I think James Shore is one of the top experts in this area, one that all developers and ScrumMasters should be aware of and growing in. James and Arlo are also dynamic, often hilarious and irreverent, presenters.

Be Agile. Scale Up. Stay Lean. (Dean Leffingwell) Covering the Scaled Agile Framework, this is a session that gives an overview of an approach, framework and tools that are a proven solution to scaling. There is some controversy over adding some prescriptive process to Scrum, but many Late Adopter stage companies appreciate and do better with more structure and guidance.

Lean Leadership - How to change as a manager from expert to coach (Ed Kraay) Ed, Agile Coach at Yahoo! is great, unbelievably smart and well read, and is very well liked and respected in his company and the agile community. He has a lot of good stuff to share, so take the opportunity if you can to get hear what he has to share.

Experimenting in the Enterprise (David Bland, Brian Bozzuto) Great topic on doing Lean Start-up in large companies. David Bland is a expert with proven success at this amazing new field, and Brian is a ridiculously good enterprise agile coach. Not to be missed. Heck, I'd go listen to them talk about raising chickens. 

Does TV Stunt Your Agile Career Growth?

Call me goofy, but I have to be transparent and tell you of a pattern I see all the time. I often start my Certified Scrum and agile training classes with an exercise. I ask everyone line up according to how much TV they watch (or Netflix, Hulu or video games they play, etc). After a brief discussion of how the group managed to do that without detailed instructions, I then ask them to line up according to agile experience. 

Again and again I see the majority of people who watch TV (or play games) the most switch places with those who don't. That is, many people watching TV the most have the least amount of agile experience, and many who watch TV the least have the most agile experience. 

Let me suggest two stories that might be happening. 

Booby loves TV. Won't miss an episode of Real OC Vampires, Food Wars or Celebrity Dogs. He hears that his company is going to "go agile." "Cool," he thinks, "hope they pick my team to pilot it."

Peter loves learning. Won't miss a blog post, new book or even his monthly issues of Tech Talk. He hears his company is going to "go agile." "Cool," he thinks, "because I've been talking about it to my boss, my team, and the project managers, sharing what I've been reading. I'm getting a lot more out of the Scrum book I ordered, know that it may happen any day. I hope they pick my team to pilot it."

Who might you pick to be the ScrumMaster on the pilot team?

By the way, I sometimes share in my class how my pre-marriage counselor requested us not to have a TV the first year of marriage to improve our communication. Something about men not being as natural at listening as women. Not sure. I wasn't paying attention...

Why a ScrumMaster Might Lie

One question I ask in working with new groups or retrospectives is how far away is everyone now from where they were born. If we're talking about self-organization, I can ask the team to line up in that order, and watch the interactions go.

It's surprising to me how little we know about the teams we work with. That knowledge we gain, with sometimes only minutes of talking, pays dividends in a more trusting, productive working relationship and environment. 

I worked with one Project Manager turned ScrumMaster, and he was struggling with a decision the team wanted to make that he didn't agree with. He even went so far as to tell the team that their Director wanted it the ScrumMaster's way, which turned out to be not true. Not very good servant leadership. Management wondered if we needed to pull this guy out of the ScrumMaster role, for he had been an effective project manager, from what I understood. 

Then one night I ran into the ScrumMaster at Chili's and we shared a meal. In the course of that hour, I learned how he had come from a powerful Middle Eastern family. He was the eldest son and had high expecations put on him, a burden that he seemed trying to meet, thousands of miles away from his family, through work performance. All these details helped me see a fuller picture of this man who had been raised to make things happen and carry the full burden of responsibility himself. 

In this case, the struggle wasn't about Scrum, it was about a new personal definition of success and learning to trust. I would never have changed my coaching approach had I not stumbled across this new perspective of my teammate. 

Where Do You Draw Inspiration From?

Where do you draw inspiration from? Yesterday I was inspired by two people in my class, Dennis and Wes. Dennis doesn't let his age, in an age-predjudice marketplace, hold him back. He was pointed out in the class as being the key contributor in solving a class problem (which he politely denied was the case). And Wes doesn't let his lack of background in IT hold him back. He was one of the most engaged people, stayed after class, and was so interactive that I kept mistaking him for an experienced Scrum team member.

You give get knocked down from time to time, and lose your strength or hope or fire. A community around you can help you draw strength when you don't have it in yourself.

Upcoming Agile & Scrum Conferences

Including coaching, testing, small and intimate, and large and comprehensive. I included this list in a follow-up email after my Certified Scrum Master and Product Owner classes, but I thought others might appreciate the list. 

• June 2-7 Agile Development Conference West (includes opportunity for QA Certification class) @ Las Vegas
• June 3-5 RallyON @ Boulder, CO - Awesome small conference with focus on agility in business and very high coach-to-attendee ratio). Don't have to be a Rally customer. Great for business, execs, agile leaders
• August 5 - 9 Agile 2013 @ Nashville, TN - The granddaddy of them all. My session is on the Agile Leader Storyline.
• August 8-9 The Leadership Summit - Where I first heard Markus Buckingham & Jim Collins. This year Patrick Lencioni (5 Dysfunctions of a Team) and Colin Powell, and more. Simulcast around the world. Find a site near you. 
• September 11-13 Agile Open SoCal @ University of California, Irvine - Put this on your calendar now! Small, intimate Open Space unconference with a high percentage of coaches for small sessions and hallway conversations. The only SoCal agile conference. Meet people form area companies who are doing agile.
• December 6 - 8 Scrum Coaching Retreat @ The San Marcos Resort in Chandler, AZ.  Heard great things about the previous coaching retreat. Don't have to be a CSC or titled "Agile Coach."

The 3 Steps of a Change Agent

From July 2005 - 

------------
Welcoming Reality - The Furious Indifference to Our Cause

For all my talk, I weekly come back to the question "So how do we put this into effect here where I work?" It is not uncommon for those in IT to rarely see the ideal solution, method or process actually put into practice.

Recently I've seen the confluence of, at first glance, unrelated items. When seen holistically, though, these items point to what I feel is at the heart of leading change in the workplace.

You Need to Fight, but Fight Right

"A soldier surrounded by enemies, if he is to cut his way out, needs to combine a strong desire for living with a strange carelessness about dying. He must not merely cling to life, for then he will be a coward, and will not escape. He must not merely wait for death, for then he will be a suicide, and will not escape. He must seek his life in a spirit of furious indifference to it; he must desire life like water and yet drink death like wine." - G.K. Chesterton

In business terms, a leader is surrounded by all the reasons things don't change in their workplace. If he is to succeed in making a difference, he needs to combine a strong desire to keep his job and favor with his boss and colleagues with a strange carelessness about being fired. He must not merely worry about keeping his job and what those in influential positions think of him, for then he will be a coward, fearful, and he will not make a difference. He must not merely wait to be fired - saying things and taking actions that communicate not caring about being fired or about what his boss or those in influential positions think of him, for then he will be fired and he will not make a difference. He must seek to make a difference in a spirit of furious indifference to whether he actually succeeds in creating change.

First, we must decide that we're going to fight to make a difference. This is the "strong desire for living." Making a difference takes effort, commitment, determination, and often much more physically and emotionally exhausting than just accepting a substandard environment.

Second, we realize and accept that making a difference is a desire, not a goal. Desires are what we strive for, goals are what we can actually achieve. Often, people and circumstances get in the way of what we hope to achieve. If they get in the way of goals, we can become frustrated, angry, resentful. With desires, it is easier to accept failing to attain the end result in its entirety - not getting closure. This helps one to keep from reacting. Instead, they respond. The focus is on the action(s) or logical argument(s) in question positions being discussed, not the people themselves having the dialog.

Third, we find a way to put ourselves second to the cause and the possible consequences of advocating the cause. This is the "strange carelessness about dying." We stop looking out for "#1" - ourselves, as paramount. I haven't found a way to be effective in making a difference when I am thinking of myself first because I keep getting in the way. That is, while trying to convince someone of my point, fear and doubt keep me thinking in the back of my mind, "What if they think this is a truly bad idea? If they did, would they communicate that to my boss? What then would he think of me?" At times, I become competitive. I approach discussions where a decision outcome will occur as a zero-sum game where if I don't win, I'll lose. In these cases, I must win because if I don't, I'll appear weak, foolish, less-than, that my ideas aren't sound. This emotional reaction can be especially strong in a public forum, such as meeting or an email thread with many recipients.

These three points are simple, but not easy. Making a change to the way things are done involves other people. We are interdependent in all but the smallest IT organizations. And it is our interactions and relationships with these people (and their attitudes, beliefs, understanding, motives, agendas) that are principally the challenge.

If You Want a Queen, You Have to Be a King

There's a saying in courtship that if you want a Queen, you have to be a King. This means that if we want a certain reality, we have to be the type of person deserving of that reality. We have to be a person of character if we are to expect a working environment where there is good, healthy interdependence and commonality.

Creating the unity necessary to run an effective business... Requires great personal strength and courage. No amount of technical administrative skill in laboring for the masses can make up for the lack of nobility or personal character in developing relationships.
In addition, we can see on an even deeper level that effective interdependence can only be achieved by truly independent people. It is impossible to achieve Public Victory with popular "Win/Win negotiation" techniques or "reflective listening" techniques or "creative problem-solving" techniques that focus on personality and truncate the vital character base. - pp 202, 203; The 7 Habits of Highly Effective People, Steven Covey

The combination of these two quotes from recent reading and my concerns on how to truly create change in our IT department occurred as I reviewed a document this week. It was a going-away present for a coworker. This coworker is widely viewed as an exceptional and very well respected senior level developer in our organization. The gift was a list comprised of individual submissions from his colleagues of the positive traits they saw in him. For all his wealth of technical and intellectual talent, by far the most common items in the list were "patience", "persistence", "friendly", "helpful", "giving." After working alongside him for a year, I had been mistaking the dominant reason he was so effective. It was because of his character, who he is. He was a great worker because he was a great person.

To be change agents, we need to commit to the cause, let ourselves be second, hold on to what we want with open hands, and have the kind of character which nourishes good relationships (and effectiveness) with our coworkers.

What Happened When I Spoke Out

My recent post about being a change agent reminded me of one of my personal favorite posts I wrote back in July 2005 titled "Welcoming Reality - The Furious Indifference to Our Cause."

I was writing about a time when I was in the midst of a bad work situation, but at the same time was inspired by a great worker and some great change agents (several of whom didn't last). Specifically, I was wrestling with "Do I save my skin and compromise my values, or do I step out and speak my mind, and whatever happens happens." The risk was real. Over the previous year and a half, I had kept a tally of 17 people in our group who had been let go for various or mysterious reasons. As a manager, I tracked this and other turnover in our department. We were something like 300% over the average of the rest of the IT world.

Well, I chose to speak out.

And I was let go as part of a second round of layoffs couple months later. Terrible? Yes, and no. I'm writing this now to let you know:

1. I lived, and 
2. I'm better off

When I talk about courage in my ScrumMaster classes, I look at students in my class and I think of this valley in my life. I know that these situations can be scary for many of them.

But these tests and trials develop something inside us that you can't buy or get from a book. It's only from experience. And your people will respect you for your courage and selflessness (can't buy that, either). These tests develop perseverance, and that gives you genuine character, which leads to hope. Hope is a core leadership trait per Jim Collins and Gallup (see The Stockdale Paradox and What Followers Want from Leaders). Personally, since that time I've gone on to speak my mind more often (and learned to position, influence and build support much better - great skills for a change agent) and live a life where I don't dread coming in to work, no matter what the situation.

I'll re-post it soon, so keep an eye out, and I sincerely hope you enjoy it -

ScrumMasters, I Hope You're Being Criticized!

This recent post, The Catch 22 of Criticism, was great. Here's why it matters to you.

ScrumMasters, one of the most powerful aspects of your role is that of Organizational Change Agent.

Whomever started your large company, he or she surely didn't say to themselves at the beginning, "You know, I'd really love to create a large, slow bureaucracy. That'd be awesome!"

Yet, the company grows. And adds dev, QA, and business analyst silos. And grows. And adds management layers. And grows. And adds project management layers. And grows. And suddenly management is wondering why it takes so long to get anything done.

As the change agent, you're giving constant, prompt feedback to what is keeping your product-focussed team from being super productive. And I've seen again and again pushback from those in the middle who are fearful, or resistant to change, or have other motives, or have something to "lose." But...

Don’t let it change what you’re doing entirely or who you are. You must understand the type of criticism, the story line, and the intentions. Don’t be reactive, simply sit back, enjoy the show.
The catch 22 is that if you’re being successful at pushing boundaries, you’ll get criticism. If you aren’t getting criticism, you’re not pushing hard enough or actually making change. So look at criticism as a gift, or a sign that you’re doing something right. 

By the way, I love the storyline mention. That's the topic of a session I proposed (and was accepted) at Agile 2013. More on that to come...

3 Things To Do Today To Add Agile to Your Project

One morning at a client site, I came across a small group of people standing up around a table in a conference room.

"So you guys are using Scrum, too?" I asked." 

"No, we're not using Scrum at all. Our project has a deadline coming up to deliver, and we thought it would help if the team just met each morning for a few minutes to talk about what got done yesterday, what's on tap for today and if anyone was having any problems."

Whether using Scrum or not, you can apply these action items below to add some agility to your project. Keep in mind that when I say agility or being agile, I mean activities and attitudes that reflect the values listed on the Agile Manifesto.

1. Meet with your project team (those doing the work) each morning for 15 minutes. Ask someone on the team to facilitate each person answering these three questions:

• What did I accomplish yesterday?
• What do I plan to accomplish today?
• Is anything blocking me from getting my work done?

Interactive displays and interesting conversations at EWEA 2013 by European Wind Energy Association

Attribution-NonCommercial-NoDerivs License

If any problem solving or discussions beyond these three questions come up, the facilitator should ask that they be held until after the meeting when others who are interested can stay and continue the conversation. This is called a daily scrum or daily stand-up meeting. It's not a status meeting, but a collaboration touchpoint for folks doing the work.

See the thorough article It's Not Just Standing Up for a deep dive.

2. Use simple collaborative tools. Especially given that most individual contributors in IT are introverts, tools such as fist-to-five (or fist of five), dot-voting, using stickies to brainstorm or provide feedback provide an amazingly different amount and type of feedback. Anytime I just ask for ideas, or what people think, I'll get a third of what I would if I asked the group to write down their ideas, or give me a fist-to-five.

The Fist-to-Five: When you're in a group deciding on something, such as where to go to lunch, you can simply have everyone hold up fingers representing where they stand: 5 means they love the idea, 4 means they like the idea, 3 means they're not that happy but they won't get in the way, 2 means they have some questions or concerns that if answered they can get onboard, and 1 means no way ever never. Fist of five is a great way to hear everyones voice and quickly see who's not in agreement and why (and then work to get them in agreement).

3. Estimate together. Estimate without bias.

I used to go to each of my team members individually and ask them to estimate the effort for their or their people's tasks. What works much better is to bring all the team members together and have them do a blind vote on what they think the estimate is. I commonly hear of only the leads or architects being asked for estimates, but whenever I ask the team if they would like for someone else to estimate their work, they say know. I think it disenfranchises them, eliminates real commitment, and therefore hurts motivation and productivity.

In the big picture, it's best if the work to be done is defined in terms of small units of working software (user stories) and using relative estimation (points) to derive when the work will be done. But that's a big shift, and if your team or company isn't going to okay using Scrum or other agile approach anytime soon, you can still use some helpful aspects of this approach.

Describe the work to be done. Ask if there are any questions. After there are no more questions, have people write down the amount of effort they think it will entail. Pick the persons with the lowest and highest numbers and ask them to explain why they thought so.
Vote again.

Although I hope they'll agree on the same number, they probably will only get closer. It's best to let the team decide the final number. Regardless, I've found that the conversation and team member engagement was so much greater in regards to the requirements and the estimates than I ever had before, and this thoughtful, focused exercise will yield much better understanding and therefore estimates.

These are just some things you can do today to improve your project with collaborative practices that shift focus towards agile values such as individuals and interactions over processes and tools.

3 Reasons to Give Story Points to Defects

An agile manager recently asked if the teams in his department should size bugs, the same as they estimate user stories with story points.

My response was that I prefer to story point escaped bugs. Escaped defects are those not found within the sprint (because sprints should be zero-defects).

Sizing defects helps:

1. development teams get credit for the work that they do, which often can often include fixing bugs.
2. the Product Owner determine priority (maybe he doesn't really want to fix a defect for IE 5.5 users in Estonia if it means 40 points of work.
3. track another view of defect trends for your product (not just defect count but also total effort/complexity/doubt, priority when combined with feature requests, real progress trend, etc).

5 Things To Do on Your 1st Day as ScrumMaster

As I work with students in my Certified ScrumMaster classes, coming from all roles (developer, lead engineer, project manager, quality assurance, and on), I find there is perhaps a gap in clear next steps guidance.

Scrum helps teams to focus, but perhaps it's a bit overwhelming at first. Here's somethings you might consider on Day 1.

In Scrum, the first day or step in the process is a sprint planning meeting, but let's assume that you're not there yet, but simply have been told your you're now a ScrumMaster.

1. Are all your meetings (daily stand-up, planning, sprint review and retrospective) scheduled? What about grooming meetings? Check my blog post for ideas on a "day in the life of Scrum" calendar. Just having the dates for the meetings will help you and your team to focus. Will you have stories ready to demo at the sprint review? Maybe, maybe not, but it's better do something and then inspect then results, rather than wait until you or others feel ready.
2. Do we have a prioritized backlog of product backlog items (typically user stories, and the top ones with acceptance criteria)? If not, schedule a story brainstorming meeting with the Product Owner and team. To start, you only need enough work backlog to fill the first sprint, plus another one to two more. That gets you going. 
3. Do we have a Product Owner? Does that person understand what expected of them in this new role? Here are two videos - a short animated video on the Product Owner role, and an hour conference session on the Essential Product Owner that might help.
4. Do we have a team? Ideally five to nine members, dedicated (not shared on other projects), cross-functional (not a dev Scrum team, and a QA scrum team), and co-located (all in the same location and within talking distance). Any variations to this, and the challenges and likely weakened results should be communicated to the stakeholders and sponsors of the agile effort.
5. Has your team had agile training or experience? If not, I encourage you to set up an Introduction to Agile or Agile 101 type session. You may not feel qualified, but even walking through Mike Cohn's PowerPoint presentation Introduction to Scrum (and you can find lots of SlideShare and PDF's on this) will stir and help conversation, shared understanding and agreement. It might lower your anxiety and the expectations you put on yourself if you consider yourself less an instructor and more of a facilitator. I would expect at least one to two hours, but formal training is typically a day on this.

I also wrote a document for next steps after the ScrumMaster training. It is broad and beyond Day 1, but it might help.

Good luck, and enjoy the journey!

You Already Chose Failure (or Success)

Ever wonder if it's going to work? Is this role right for you? Can you successfully lead this team? Will the project be a success?

Although we may have the skills and experience to be successful, much more is determined by the intangibles - passion and drive, collaboration skills and empathy, work ethic, vision and values.

We all have roles, and those roles are our decision filters on how we behave, and therefore our success. We are acting out of those roles whether we realize it our not, and often it's not the roles we want to be in, but default or roles not appropriate for the situation.

I might know a lot about parenting, but if my primary role when I come home is (still) business, then my actions are based on that, and I fail. I'll be trying to get one more email done. I'll be thinking about upcoming meetings and not listening to my family. I won't be present emotionally, even if there physically. And I certainly won't be leading my family to a vision of what we can be, something they get excited about and get behind.

The roles of the ScrumMaster include Servant Leader, Impediment Remover, Coach, Educator and Evangelist, Organizational Change Agent, Chief Mechanic and Shepherd an Guardian of the Process.
Our roles act as a decision filter. When you're at work, try consciously wearing one of these hats. That way, we take initiative in stopping our default responses or reactions and start acting from who we want to be.

For example, if I'm late to work, my default role of employee or reports-to-someone pulls me towards trying to sneak in unnoticed. Now, my teammates or those I lead will notice this. I've not only missed a coaching or learning opportunity with them, but I've actually modeled just the behavior that I don't want  them to have.

Instead, if I am late to work, but I'm wearing the role of servant leader, I'm thinking of my team first. I transparently check in with them, letting them know that since I was late, I might have missed something they needed (or worse, the daily stand-up). I might model vulnerability about how I'm wrestling with my own inspect-and-adapt cycle on how to solve this on-time problem.

Repost - Buckingham on Management, Leadership & Employee Engagement

Marcus Buckingham has been one of the biggest influences on how I work with people. His books First Break All the Rules and Now Discover Your Strengths (published 1999 and 2001) are still in Amazon's Top 100 Business and Management.

 

I've stitched together three posts I wrote a while back that summarize Buckingham's book "The One Thing You Need to Know...About Great Managing, Great Leading, and Sustained Individual Success"

Part 1 - http://scottdunn.blogspot.in/2004/08/markus-buckingham-one-thing-you-need.html

Part 2 - http://scottdunn.blogspot.in/2004/08/you-need-to-know-pt-2-management.html

Part 3 - http://scottdunn.blogspot.in/2004/08/you-need-to-know-pt-3-leadership.html

And two other summaries:

A nice, but low res, video with some key points - http://www.youtube.com/watch?v=RYbzV8SDkdY

And a good, concise summary of the book (and my take-aways as well):

• Managing: "Discover what is unique about each person and capitalize on it." 
• Leading: "Discover what is universal and capitalize on it." 
• Sustained individual success: "Discover what you don't like doing and stop doing it." 

Along the way, Buckingham provides some excellent points of focus, including a very important differentiation between managing and leading that too many of his contemporaries have overlooked: "When you want to manage, begin with the person. When you want to lead, begin with the picture of where you are headed."

We're Distributed - Can Scrum Work for Us?

Another common question at my classes - "Our teams are distributed and remote. Can Scrum work for us?"

Before I answer that specific question, let me quote something recently that struck me -

When we're trying to make distributed work as well as co-located teams, why aren't the teams co-located? Is it to save money?

Henry Ford said that if he listened to what customers said they wanted, he would have given them faster horses. That's partly because customers will ask for what they think will solve their problem, but our job is to try to solve the problem. And if it's a complex problem, then our job is to plan on making multiple passes at a solution, evaluating the results each step of the way.

So, most of the time teams are distributed because they are outsourcing because management saw it as a strategic way to save money. Traditional management doesn't understand agile, how it works and how good it can be. It's often seen as a cost-cutting approach, as well. And you can imagine the frustration, and confusion, when management expects to add another layer of cost savings (agile) on top of outsourcing, when in actuality they are mostly in conflict. Perhaps a first step is to run an experiment with a team or teams fully co-located and measure their productivity.

Sadly, every time I've asked either how the company is measuring the cost savings, or how they even measure productivity of the teams, there's no answer. This might be a good opportunity to start.

As far as making your distributed team work. Did you ever have a long distance relationship? How well did that long-distance relationship work? For those whom it did work out for, what did they do? Most often they said, "This isn't working. We either move to the same city or call it quits." Okay, but in lieu of that, how much were you on the phone? How much did you visit each other?

Keep in mind, a lot of the following involve changing behavior, culture, how we work, opinions and raising the bar. Having said that small bit...

Best practices from a number of agile leaders from companies include:

• Most importantly, you must travel, at least yearly. Preferably quarterly. Both ways. One company measure the productivity increase at 50% after a 3 week visit by just a few people from the offshore team.
• Video chat. Given all the options and low cost, this should be a given. Have a webcam in all the meetings, and each team member should have one and ability for others to know when they're available. And get a good, hi def camera.
• Screen sharing. Expect developers to pull up the code with remote team members when discussing questions and issues. There are even people who pair program remotely most of the day.
• Collaborative design tools like Cacoo, and estimate together using planningpoker.com or everyone hitting the number key for their vote at the same time when conferencing.
• Dedicated desk or person place. Some teams keep a computer and webcam running for the remote person. If you need to talk, just walk over to them as if they were there. 
• Rolling video cart with multi-account video chat and large flat screen to have others join your team's meeting where ever it is. Cheaper than you think to build one yourself, and there are sites out there that provide the specs and how-to.
• You must have the all the meetings together, as much as possible. To show respect for the other team members, alternate who (onshore or offshore) has to be joining at odd hours. 

ScrumMasters, Be Different from the Inside Out

Reading up on Design Thinking, I came across this part of the process and was dumbfounded.

"Set aside emotion and ownership of ideas."

Oh, really? Is it that simple?

Personally, I've practiced self-awareness, servant leadership, and been coaching teams and individuals for years, and I struggle with setting aside emotion and ownership of ideas. What about people who don't even understand others, much less themselves?

And here's where I think Scrum and Agile struggle. We can teach the framework and values, but it doesn't equip us for

• the people issues, 
• the resistance to change, 
• the turf wars and politics, 
• and the fear, uncertainty and doubt that these newly minted ScrumMasters will face back at their organizations.

Besides the classic resources I would recommend, I can honestly say that I think the ScrumMaster or agile servant leader needs to be a different person from most of the people in the workplace, different inside than 95% of the people around them.

1. They need to be hopeful and believe they will prevail, regardless of the circumstances. And when bad things happen, they need to believe that good will come out of it.
2. They need to be patient, continuing to work and work towards the goals. Not patient in terms of days or weeks of not seeing results, but sometimes months or years.
3. They need to look for the good in people, while having firm and respectful boundaries that cordon off the bad.
4. They need to know the worst of humanity that impacts our efforts in the workplace - ego, selfishness, inability to admit mistakes or lack of knowledge, revenge, fear, control, but not react to these when they come out. 

Not should they not be naive about these negative aspects of the workplace we navigate. In fact, they will have even greater impact if they have been the victim of some of these abuses and not only come through it, but have no resentments. They dealt with the emotional baggage, have forgiven the person or people, and let it go. These are people that no how the game is played, don't get angry about that reality, and are still effective in getting immediate results with that environment, while slowly helping to change it and make it less dysfunctional. When South Africa began to deal with all the residue from apartheid, Desmond Tutu actually asked for just these sort of people to lead the cultural change.

Finally, they need to have a source of fulfillment that doesn't depend on their results - personally or with their projects, because these results may or may not come, not fully in this person's control. Yet they should still be a leader in that they always have something to give others, and they can if their personal tanks are full. This could come from their own personal growth, or how they've helped others grow.

We want these leaders in our workplace, but they are rare gems indeed. Be the change you want to see. Don't try to act like someone amazing, that will run out. But start becoming someone amazing, and then the actions just become natural.

Find a guide to help you grow:

• The Road Less Travelled - A classic text on personal growth
• Storyline - a new workbook to trackback the events in your life and how they are telling a story of your purpose here
• How People Grow - Thorough book by well known psychologist
• The Search for Significance - Another workbook that is a guide for finding significance over success

and be inspired - find some heros:

• Love Does: Discover a Secretly Incredible Life in an Ordinary World - A fun read by a surprisingly unconventional, almost wacky attorney who founded Restore International, a nonprofit human rights organization operating in Uganda and India.
• The Hiding Place - The riveting story of how a middle-aged Dutch watchmaker became a heroine of the Resistance and a survivor of Hitler's death camps.
• Kisses from Katie: A Story of Relentless Love and Redemption - An 18 year old leaves everything in American to start an orphanage in Uganda.
• Pranitha Timothy - Has lead dozens of rescue missions to free slaves.
• Freedom Writers - A movie about the teacher in the inner city who changed lives.
• Amazing Grace - The movie of William Wilberforce who began the movement to end slavery in Britain.

Great Forrester Comment - "PMO's are Becoming Incredibly..."

One of my favorite quotes on the PMO comes from this frank and humorous comment from Dave West, VP Research Director at Forrester Research. You can hear him and the other panelists on Agile Portfolio Management Q & A Panel at the link below. Dave's comment starts at 1:30.

"It's interesting, what we at Forrester have observed across the industry this particular kind of  maniacal kind of addition to the program management kind of practice. PMO's have grown in size and stature in organizations and become incredibly…big, in terms of their execution. One thing that it illustrates is that complexity does not solve complexity.  As organizations wrestle with increasingly diverse portfolio, time-to-market pressures, one thing that they want to do is add more complexity. "When in doubt, add more governance!","When in doubt, add more people to manage the people that are managing the people!" "When in doubt, get more Gannt charts!" And I think that we've found that that does not work. I think it's clear that breakthrough companies or companies that are definitely driving the industry around change and innovation are not solving those problems with complexity."

http://www.youtube.com/watch?v=kN99R6Plw3E

10 Most Used Resources in My Certified ScrumMaster Class

This is what I reference most often in my Certified Scrum Master training, or show during the lunch breaks in class. Enjoy!

Material Used in Class

1.     New Scrum Primer 2.0, from four Scrum Trainers - http://assets.scrumfoundation.com/downloads/1/scrumprimer20.pdf

2.     Agile Manifesto and 12 Principles - http://agilemanifesto.org/

3.     Do Better Scrum - http://www.scrumsense.com/resources/do-better-scrum

4.     Scrum Handbook – http://jeffsutherland.com/scrumhandbook.pdf

5.     (CSPO) User Story Primer - http://trailridgeconsulting.com/files/user-story-primer.pdf

Videos Often Shown in Class

1.     Marcus Buckingham, Strengths. We watched one of two videos:

a.     Trombone Player Wanted http://www.tmbc.com/assets/sc/go/tpw-player.html

b.     The Business Case for Strengths http://www.youtube.com/watch?v=1KeNfhw7bK0

2.     Daniel Pink on Motivation – The longer TED talk, and the RSA animated version on YouTube

3.     Simon Sinek, Start with Why – “Very, very few people or organizations know why they do what they do. And by "why" I don't mean, "to make a profit." That's a result.  By "why," I mean: What's your purpose? What's your cause? What's your belief? Why does your organization exist? Why do you get out of bed in the morning? And why should anyone care?” http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html

4.     Agile Product Ownership in a Nutshell - http://blog.crisp.se/2012/10/25/henrikkniberg/agile-product-ownership-in-a-nutshell

Videos Related to Material Often Mentioned in Class

1.     Switch, How to Change When Change Is Hard - Heath 

a.     Want Your Organization to Change? - http://www.youtube.com/watch?v=JhBzxy7CneM 

b.     Why Change is So Hard - http://www.youtube.com/watch?v=RpiDWeRN4UA 

c.      How to Find the Bright Spots - http://www.youtube.com/watch?v=zbLNOS7MxFc 

d.     Shrink the Change - http://www.youtube.com/watch?v=j-iXOvkyAOk 

e.     It's the Situation, Not the Person - http://www.youtube.com/watch?v=Qp1_6hufkoU