Wednesday, February 26, 2014

Introspective: Conversation Framework

We're all just faking it and hoping everything works out.
What's in a Number?
For at least half a year now, there has been a growing movement in the Agile Community for #NoEstimates - the concept that estimating the size of your work, regardless of method, is detrimental. The idea is intriguing and thought-provoking, which automatically gives it some degree of merit among those who are constantly striving to push the boundaries of Agile. The thoughts on the subject that most resonate with me on this subject come from Dan Mezick of Open Agile Adoption fame and Valerie Santillo, a blogger I met last year in D.C. and have kept in touch with since. What both of these thought leaders have said is that the conversation that leads to the estimate consensus is the most valuable aspect of the estimation process, and that great care should be taken to maintain that learning process.

The question then becomes: can you have a learning conversation and reach some sort of consensus as a team without an estimate to trigger that the consensus has been reached? My intent here is not to answer the question, but to illustrate how powerful this concept - using a conversation geared towards achieving consensus as a framework for learning - can be in practice.

Meetings, or Games?
Dan Mezick describes this consensus-driving conversation framework in the context of gamification. He posits that all meetings are games, and uses Jane McGonigal's definition of good games to show that meetings are ineffective because they are broken! A good game contains: a clear goal; clear rules; a way to get feedback; and opt-in participation. In a later post, Dan details How Games Deliver Happiness & Learning by putting gamification in terms of senses: a sense of control; a sense of progress; a sense of membership and community; and a sense of higher purpose and meaning.

Estimation as a Game
I propose that Story Point Estimation, particularly the Planning Poker approach or similar, meets the criteria for a good game as stated above. First, there is a clear goal: to agree on the "bigness" of each User Story. This is where my concern with the #NoEstimates movement comes into play, though I'm definitely open to their alternatives. Second, there are clear rules; the team has a Definition of Done for each Sprint, and each User Story has Acceptance Criteria to help the team understand what the User Story is (and isn't). Third, there is a way to get feedback through both conversation and revealing of Story Points. Conversation, in theory, would be good enough. However, experience has taught us that assumptions not stated in the initial conversation are revealed when discrepancies emerge as Points are shared. By having disparity in estimates, we are providing feedback that our assumptions differ. Fourth, the participation is opt-in - or, at least, it should be. Estimation should be done at a time and for a duration that the team agrees to. Nobody on the team should feel like they are being forced to participate. If there are, the Scrum Master or Agile Coach needs to step in, mine for conflict, and find out why the team member is disengaged so that the team can fix it.

Now let's look at it in terms of senses. First, there's the sense of control. The process of Planning Poker should, again in theory, prevent the process of estimation from being dominated by a loud minority. Every participant should feel some level of control over the direction of the conversation. Second, the sense of progress. As votes are cast and the numbers converge, we feel like we are nearing our goal for each Story. On a deeper level, we're growing closer as a team and gaining a more in-depth understanding of the system being built, which provides us a feeling of accomplishment and satisfaction. Third, the sense of membership and community, which should have been fostered prior to the activity and is reinforced throughout the conversation. Finally, the sense of higher purpose and meaning. This sense is driven by the nature of the work being discussed and estimated; a team that isn't opting-in may not feel this sense.

Every Meeting as a Game
What I've just walked you through are the conclusions I've started to form about how ALL conversations should be structured. It's the context with which I constructed the training material for the senior management that my fellow Coach and I were tasked with training on Agile. We started with the goal: how will each person change their behavior as a result of the paradigm shift we take them through? The mechanism we chose was the 5-Spoke Wheel Retrospective that we would end the training with. Starting with the end in mind, we created a framework for having the participants discuss the Principles of Agile and the Themes of Product Development Flow that would result in them debating with each other and examining the work they do on a daily, weekly, monthly, quarterly, and annual basis. As facilitators, we spoke for about a quarter of the time, opting for audience participation and group teaching instead.

I was shocked and amazed with not only how smoothly the class ran with so little structure, but with the amount of positive feedback we got afterwards! I then thought back to my early days with my first Scrum teams, how they would talk about how little time they spend in meetings now that they've gone Agile. When questioned about their Daily Scrum, Story Time (Backlog Grooming), Sprint Review & Demo, Sprint Retrospective, and Sprint Planning meetings, they would respond, "Oh, we don't really think of those as meetings; they're more active group conversations."

Framework for Success
Personally, I like Story Point Estimation and will continue to use it as a tool to help people bridge the gap from traditional (Waterfall) project structure and more Agile approaches. If they decide to do away with estimation altogether and can do it in such a way that the valuable conversation is not lost, I say go for it. I will also begin to encourage everyone to take a gamification approach to meetings with the goal that people not only look forward to them, they are insulted at the insinuation that their conversations are called "meetings". After all, meetings are dull, pointless, no-fun snooze-fests!

Wednesday, February 19, 2014

Introspective: Recognition and Servant Leadership

Every February, my company has a host of Year Beginning Meetings (YBM - our fiscal year runs February through January). Within IT, we have several YBM activities. First, we have our pillar celebrations (we are a matrixed organization). Then we have a half-day General Session and a day-long Tech Fair. A huge part of all of these activities is recognition. There are a variety of awards that are presented to teams and individuals at the pillar and division levels, usually chosen by the award's respective management team. I love the emphasis on recognition, but I went into my pillar's celebration today wondering how you balance recognition with servant leadership.

I wasn't expecting to get an award, but I was thinking about what it would mean if I, who spent the entire year as an Agile Coach and Servant Leader, was chosen for an award by management. Shouldn't the recognition be focused on the team I worked with? More importantly, what would happen if I were selected for an award and my team wasn't? I would feel like a complete failure! What would it say about me if my management team thought I was deserving of one of the relatively few individual awards, yet my team didn't do enough to merit an award? I honestly didn't know how I would feel about it.

As it turns out, my team didn't win any awards. I'm going to brush past that for now, because I feel that they were truly deserving. As it also turns out, I won an individual award. It was an award that I sincerely did not expect to win - I was on my laptop with the company's internal social network pulled up and providing updates from the meeting when they called my name. It was also the only award I could have received in the absence of a team award that wouldn't make me feel like a failure.

Pillar Associates' Choice Award - the most meaningful award to me.

I won my Pillar's Associates' Choice Award. That means that, of the 250 people in the pillar that actually voted, I received more votes than anyone else. I don't know how many people voted for me, but the important thing is that it was chosen by the people. This wasn't something that management got together and decided to award me with. This award was selected by the people I was serving. I could not be more flattered and touched by any other award presented today.

What makes this particularly poignant is that I am in the process of transferring to another team in another pillar, and most people in my pillar that know me knew about my transfer prior to voting. They were willing to vote for me even though they knew I was on the way out. My six-year anniversary is in May, and I have spent my entire career to-date with the same team. Bittersweet does not quite capture the mixture of feelings that I'm experiencing, but it's as close as I can get.

I know I'm supposed to come up with something actionable out of this rambling, sentimental, nostalgic introspective, so I'd better get to it. I want to never forget this feeling, the feeling that I have succeeded as a Servant Leader in touching the lives of those whom I've served. As I move from area to area, helping them safely adopt Agile, I will strive to approach each one as if they were the family of associates that I first served. After all, they are all people, and they all deserve it.

Wednesday, February 12, 2014

Introspective: Agile is an Arsenal, Not a Silver Bullet

I recently gave a presentation to my local PMI Chapter entitled, "Agile is an Arsenal, Not a Silver Bullet". You can view the visual cues I used at http://tinyurl.com/AgileArsenal. The point of the presentation was that Agile means the manifesto and principles, so when someone says, "We're going AGILE!" your first question should be, "What do you mean by that?" There are so many approaches and practices available that using the term "Agile" is not adequate. Further, it is possible to employ Agile techniques improperly to actually make the organization less Agile. You could also apply "surface level Agile", which is basically a facade for the status quo.

When I talk about "going Agile", I make it clear that I mean "Being Agile". I want people to understand the principles and paradigm that the original Agile Manifesto Signatories had in mind. I want them to understand why popular Agile techniques are so popular so that they don't misuse them.

One of the gentlemen who attended my presentation came up to talk to me afterward. He said he had some Agile horror stories that he intentionally didn't bring up as a professional courtesy. I promptly chastised him, saying that the horror stories would have illustrated my point! He took me out to lunch yesterday to talk me through one of them. Sure enough, they were stories of salesmen who came into an organization that was already on an Agile trend and shoved them into the mold he was familiar with. It was not an incremental change - heck, it wasn't even an improvement! It was nothing more than an off-the-shelf methodology with all the right buzz words. This experience left a bad taste in his mouth for Agile.

I've often said that the biggest hindrance to an Agile adoption is that people will think you're trying to sell them a Silver Bullet. When they do, they will usually react one of two ways: 1) they will jump in without fully understanding and have their unrealistic expectations shattered; or 2) they'll be smart enough to know there's no such thing and turn on Agile with precision cynicism. Invariably, when I explain to people what Agile really means and the importance of "Being Agile", people get it and buy in. They make it their own and take charge in their personal and organizational transformation. They build their arsenal and never settle for what they have.

Wednesday, February 5, 2014

Introspective: Dealing with Disruption

This post is going to be short, folks. I live in NW Arkansas, and we're in the middle of our 3rd-straight snow day. The odds are in favor of no school at all this week, and my RWD pick-up doesn't do too well on snowy roads. Consequently, I've been working from home alongside my wife and two children, ages 6 and 2. These have not been productive days for me, as I'm constantly interrupted by the realities of home life. Even locking myself in a room doesn't work for long because they eventually find me and harass the locked door until it opens.

I wonder if this is what some people feel like at work - people who are on multiple projects at the same time with a micro-manager. How do they ever get anything done? How much more could they get done if they were left to get their work done on only one thing at a time? And how much happier would they be while doing it?