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!