Scrumology

Everyone Has a Voice in Retrospectives

David Bland — Tue, 02 Mar 2010 03:45:54 +0000

It can be difficult to get team members to be vocal in retrospectives. I’m always wary of the stronger personalities controlling the conversation, and I’ve found that going around the room calling people out by name can have mixed results. After reading a recent article on effective retrospective formats, I decided to write my experience with finding every voice.

Step 1 – Red & Green. Distribute 2 colors of post-its and a sharpie to each team member. Explain how we are going to use the next 10min to write independently. I recommend starting simple with red & green, and also having a legend on the whiteboard to help people remember which is which. You’d be surprised how quickly they forget! Use the green post-its to write down what helped the team during the iteration, and the red post-its for what hindered them.

Step 2 – Every Voice. Go around the room and allocate 3-5min for each team member to stand up and discuss their post-its. Have the team members listen while the post-its are stuck up on the whiteboard 1-by-1. It’ll look a bit unorganized at first, but after the 2nd or 3rd person you should begin to recognize common threads throughout the conversations.

Step 3 – Group Organization. Have the entire team come up to the board and categorize the post-its into themes. This is important because it is a group exercise, rather than having the facilitator do it by himself.

After the team comes to a general consensus, have them sit down and talk about the groupings. It should be easy to visually recognize the trouble areas, as they are most likely in red post-it clusters. I recommend starting the conversation with those and ending with the green collections. Be certain to call out action items as needed throughout the discussion.

Feel free to customize this format as you see fit. You can spice it up with an egg timer to denote the end of the writing exercise, or add new colors for ideas that do not fall into the helped or hindered buckets. Be aware that the less vocal team members may write very little at first.

In the end, it isn’t important that you stick to a script, but instead ensure that each and every voice is heard.

It’s an Agile Sabotage

David Bland — Fri, 26 Feb 2010 03:03:08 +0000

Agile adoptions in the Enterprise are difficult and complicated, perhaps that is why I often read stories on Top Down vs. Bottom Up techniques. I feel as though we focus too much on these and overlook the Middle, which can lead to disaster.

Middle management is arguably the toughest obstacle in any large scale Agile adoption effort. This is most apparent in situations where they’ve repeatedly fired people below them to make ends meet. An environment like this does not exactly foster job security and yet middle management becomes adept at navigating the murky waters of office politics. Anything new and disruptive in nature such as Agile, is generally not received well.

Top down Agile adoption is the way to go, you must have executive buy-in!

In a top down approach, one would assume that mandates from above would be followed within reason. However those in middle management can seriously hinder an Agile adoption by sheer incompetence or worse, sabotage. Unless your top down approach has eyes from above keeping tabs on things at the day-to-day level, there is a good change middle management will screw it up.

Grass roots Agile is the most rewarding, and you’ll be a beacon of success for the rest of the company!

With grass roots Agile, one would assume that your successes would be recognized by the executives as you deliver value early and often. However more often than not, those success stories are reported up the chain by middle management, not by the worker bees themselves. Middle management can craft the message as they see fit when sitting down to update their superiors. I’ve witnessed people take credit for work they did not even begin to understand and massage the communication to further secure their job. It happens every day.

Middle management can make or break your Agile transformation.

I recommend that anyone stepping into the Enterprise do their homework on middle management. While your Agile efforts may have a three pronged attack on the top, middle and bottom of the organization, I suggest burning significant calories on the middle. Spend one-on-one time with them and try to understand their background by asking them how they achieved their status within the organization. Gather insight into their personality, and their thoughts on new techniques or ideas. When on site during the transformation, make it a point to be involved with their day-to-day activities to address any fears they may have.

In conclusion, don’t get too wrapped up in Top vs Bottom and overlook the Middle. Your Agile transformation may just fail as a result.

Sizing Up the Enterprise

David Bland — Sun, 24 Jan 2010 23:26:47 +0000

As teams begin to estimate User Stories, they may explore different approaches such as T-Shirt sizes and Fibonacci sequences that stop at 8 or go much higher.

This freedom to choose a relative sizing style allows a team to adopt what fits well within their work environment.

While this flexible approach is quite useful at the grass roots team level, it does pose an interesting challenge in the Enterprise setting where Agile teams roll up into an Agile PMO.

How do those in charge of the overall strategic planning, make informed cross team decisions with Product Backlogs of such varying size criteria? How can they identify the features that involve the least complexity, effort and doubt coupled with a high return on investment?

Before we go into my suggestions on how to address this, let’s explore a common fallacy that is being evangelized in the Enterprise today.

Mandating Story Points to Ideal Days Solves Cross Team Sizing Inconsistencies

“1 Story Point = 1 Ideal Day (6 hour work day)”

Seems quick and easy doesn’t it? Mandate that all of your Agile teams conform to this and your problem is solved!

By doing this, however, you’ve inadvertently stripped the Story Point of its original intent while roadblocking your team from personalizing (and humanizing) the process. You risk dismissing the conversations about complexity, effort and doubt while focusing on the mythical 6hr work day.

Another unintended side effect of tying Story Points to actual hours is that it isn’t long before people make the dangerous link between Story Points and Budget.

So what is the silver bullet to this issue? As is the case with all things Agile, there is no silver bullet! Solving this issue depends on the nature of the Agile teams and their relation to the business within the Enterprise.

Are these teams separate business units within the organization, or do they all contribute to the same product?

If the teams each have their own role within the organization and are only loosely tied to the same business goals, my suggestion is to let them be for the most part. Sizing, and especially Velocity, does not translate well across teams or up the organization. It will be an apples to oranges comparison, and you should keep your eye on delivering business value. As long as your teams are collaborating by sharing their Release Plans, does it really matter if they use a T-Shirt size or a Fibonacci scale as a means to an end?

If the teams do happen to roll up into an overall product, then I suggest that sizing occur from a single Product Backlog before decomposing them into each Team Backlog. With this approach, you can have the overall strategic conversations early. I would much rather have representatives from each team weigh in on a single Product Backlog, than try to make sense of it from the bottom up. This also brings a consistency to the sizing while allowing each team to have flexibility at the Sprint Planning level.

To summarize, tread carefully when trying to apply consistency across Agile teams within the Enterprise. It may not make sense to mandate sizing techniques, especially if it causes more harm than good.

An X on the Agile Waterfall Lifeline

David Bland — Thu, 21 Jan 2010 02:34:14 +0000

Over these last few months, I’ve had the pleasure of speaking with people across the country about their thoughts on agile transformations. In doing so, I noticed a recurring theme.

We tend to categorize companies, or subsets of companies as Agile or Waterfall.

At best, openly categorizing in this manner is an over simplification; at worst it can be damaging to the organization and people.

I do not find it productive, nor do I agree with some of the techniques used to make these categorizations. For example, I respectfully disagree with the approach of throwing out terms in rapid succession and have your audience respond with either Agile or Waterfall.

“Describe Marriage!”
“Agile.. wait it is Waterfall!”

These techniques are divisive, whether it be in a group or 1-on-1 setting. Companies, especially software companies, are complex and are not easily categorized.

I think part of the issue is that the methods and techniques used to analyze organizations are kept close to the vest. Agile Coaches and Consulting Agencies have their own “secret sauce” for evaluating a client, and therefore we rarely share them with the community. I’d wager the more successful ones respect the existing culture and nature of the organization, while informing their employees of other avenues to release early & often.

I’m not asking that we all bare our intellectual property to the world, but I do request that we all do our part to change the tone of the conversation.

Remember, it is about humanizing the process, not applying labels to organizations and people.

2009 Retrospective

David Bland — Wed, 30 Dec 2009 17:45:49 +0000

If you are like me, the New Year is one of those rare occurrences in which I can actually take a break from work and reflect on what I’ve accomplished.

This is why I suggest that we all take a step back, breathe and go through our own New Year’s Retrospective.

Sit down with a piece of paper and a pencil.
Draw 2 columns.
In column 1, write down what worked well for you over the past year.
In column 2, write down what didn’t work so well for you over the past year.
Discuss your list with friends & family.
Write out a series of Action Items for the New Year.
Be sure to thank your friends & family for all of their support.
Put your writings in a safe place where you can find them next year.

If you are motivated enough to do this over several years, you can revisit your lists and reflect on where you’ve been and where you are going.

For my personal 2009 Retrospective, I’ve found that I am even more energized about helping companies become Agile. I met quite a few experts and picked their brains about where Agile needs to go, and what challenges we face as a community. I’ve learned that applying Scrum in a large, geographically dispersed enterprise is quite challenging.

I’ll not publish my Action Items, but it’s safe to say that I have some very exciting things in the works for 2010. Next year I hope to revisit my list, reflect, inspect & adapt.

How about you?

A Community of Thinkers

David Bland — Tue, 08 Dec 2009 02:15:39 +0000

I am a member of a community of thinkers. So are you.

“A Community of Thinkers”

I am a member of a community of thinkers.

I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

I challenge each community in the software industry to:

reflect and honor the practitioners who make its existence possible;
provide an excellent experience for its members;
support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
exemplify, as a body, the professional and humane behavior of its members;
engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
embrace newcomers to the community openly and to celebrate ongoing journeys; and,
thrive on the sustained health of the community and its members through continual reflection and improvement.

I believe that leaders in each community have a responsibility to exhibit these behaviors, and that people who exhibit these behaviors will become leaders.

I am a member of a community of thinkers. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.

”A Community of Thinkers” by Liz Keogh, Jean Tabaka and Eric Willeke is licensed under a Creative Commons Attribution-Share Alike 3.0 License. Please attribute to the distributor of your copy or derivative.

Distributed Video Standup

David Bland — Wed, 25 Nov 2009 02:58:24 +0000

Distributed Teams need high bandwidth bidirectional communication to succeed, and the organization should provide these tools for collaboration. Luckily for us, Video Chat and Broadband are becoming more and more affordable so this is no longer an unrealistic goal.

With a decent Video Chat setup you can teleconference with teams around the world and pick up on body language that you’d otherwise miss using only the phone or chat.

So why is it that some Distributed Teams sit around a conference table while on Video Chat?

In short, they shouldn’t.

The Scrum Master needs to do everything in his power to ensure that the teams have an area to stand up for their Daily Scrum on Video Chat. Just because you are thousands of miles away, it does not mean that you can be lazy. If you lead your Daily Scrum sitting behind a desk using Video, it’ll be harder to keep team members from pontification. It’ll also become much more difficult to change the team’s behavior later on down the line.

So fellow Distributed Scrum Masters, please stand up when facilitating the Daily Scrum over Video. Encourage others to stand up if they are reluctant, and try your best to make those visual connections early. It’ll keep the team focused and you won’t start your day by dismissing one of the key aspects of your Scrum!

Google Wave Invites for Agile Signatories

David Bland — Mon, 23 Nov 2009 15:08:20 +0000

As a member of the Agile community, I’m always looking for new and intriguing ways to collaborate with my team. I’m currently previewing Google Wave, while others like ThoughtWorks are already integrating into it.

In an effort to help out fellow collaborators, I’m giving away 3 Google Wave invites!

How can you win one you ask?

Leave a comment in this post with:
1. Your Name
2. Your Email
3. A link to your Agile Manifesto Signature.

What’s that, you’ve not signed the Agile Manifesto? I suppose if you go sign up and paste a copy of your confirmation email I’ll allow that as well. Winners that meet the above criteria will be chosen at random from the comments section in this post.

Good luck!

Scrumology Library

David Bland — Fri, 20 Nov 2009 03:29:05 +0000

You may have noticed a new tab appearing at the top of the site entitled Library. This is a new section in which I’ll make my training material & presentations available for public consumption.

In an effort to reduce noise, I’ve disabled comments on the Library section but there are several ways to get in contact with me if you have suggestions.

To be honest, I’m overwhelmed that 99% of the feedback so far has been positive on the Scrum Master presentation. It even made it to the Hot on Twitter List for SlideShare, so thank you!

What will you do tomorrow?

David Bland — Fri, 13 Nov 2009 03:02:26 +0000

Distributed Scrum Teams can be a challenge on many different levels. In the past, I’ve attempted to explain this by deep diving into all of their idiosyncrasies while citing Jeff Sutherland’s excellent White Paper on the issue. I’d then draw communication diagrams and illustrate how bi-directional, high bandwidth communication is important instead of using uni-directional, low bandwidth channels. Next I would stress how discipline and not protocol is the key to success. (and so on…)

Today, many of the distributed scrum scenarios include U.S & Indian team members. I’ve decided to take a step back and explain this adventure in very simple terms that any Scrum Master can easily relate.

A typical, Collocated Scrum Team begins their Daily Stand Up with the following:

What did you do yesterday?
What will you do today?
What is blocking progress?

Simple enough right? You are all face to face, and within 15 minutes should be wrapped up and back to work. The Scrum Master may follow it up with a Daily Sit Down to learn more about the impediments, but all-in-all it should be collaborative and efficient.

In contrast, a Distributed Scrum Team that includes U.S & Indian team members is now at least 9 1/2 hours apart. Your early morning Stand Up will instead begin with the following questions:

What did you do today?
What will you do tomorrow?
What is blocking progress?

Can you feel the efficiency and collaboration begin seep out of the process with that subtle shift from today to tomorrow?

Forget the high tech video conferencing and online agile software for a moment, and try to wrap your head around the impacts of your Daily Stand Up agenda.

Do you mind keeping your team members from their families as you sit down and try to better understand the impediments?

Are you able to remove those impediments while half of your team is asleep?

I’d suggest that all aspiring Distributed Scrum Masters understand those questions before deep diving into white papers or focusing on the tools and technology.