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!