Introspective: Trying new things

This week my Introspective turned my thoughts towards trying new things. In that spirit, I've published this week's Introspective on LinkedIn. Let me know if you like it better, worse, or are indifferent.

http://www.linkedin.com/today/post/article/20140319202441-19267203-introspective-trying-new-things

Introspective: Systems and Serendipity

I recently met with a fellow alumnus of my Alma Mater, BYU (go Cougars!), who had sought out my advice. As I walked him through my brief career to-date, I commented on how serendipitous it sounded when the key events of the past six years were rattled off in quick succession. It's difficult to explain the hard work I put in; the difficult decisions I had to make; and the misfortunes that selective memory has edited from the easy retrieval section of my mind.

What I was able to tell him was that I have not landed where I thought I would have six years ago. My biggest take-away from my experiences is that goals are mostly useless; more specifically, the longer out the goal is the more useless it is. What got me where I am today is a system of looking for opportunities that would put me in a better position for luck to find me. I noted how fortunate I was to have recently read Scott Adams' book "How to Fail at Almost Everything and Still Win Big", where he talks about this exact concept; otherwise, it would have been much more difficult for me to articulate my journey without using the word "luck" a lot.

"Avoid employing unlucky people. Throw half of the pile of CVs in the bin without reading them."

What I've taken away from that experience is that I need to do a better job of documenting my journey. Without something I can reflect on, it is very difficult to explain to those unfamiliar with my journey that my success is not just a "fortuitous happenstance", a.k.a. serendipity, a.k.a. dumb luck. I feel the same way about luck as Peter Dinklage does, which he explained after making the remark that he felt "really lucky":

Although I hate that word—“lucky.” It cheapens a lot of hard work. Living in Brooklyn in an apartment without any heat and paying for dinner at the bodega with dimes—I don’t think I felt myself lucky back then. Doing plays for 50 bucks and trying to be true to myself as an artist and turning down commercials where they wanted a leprechaun. Saying I was lucky negates the hard work I put in and spits on that guy who’s freezing his ass off back in Brooklyn. So I won’t say I’m lucky. I’m fortunate enough to find or attract very talented people. For some reason I found them, and they found me.

"I hate that word -- lucky. It cheapens a lot of hard work."

By looking for opportunities and making choices that put me in a better position to find luck, I happened to be in the right place at the right time when opportunities presented themselves. I want to be able to tell my story better so that others can better understand and learn from it. This blog will be my primary vehicle for that, along with Twitter and LinkedIn, but I may end up looking at other options as well.

Introspective: Agile Metrics and Work In Progress

One of the things I've been doing lately is helping people understand what metrics you can use with Agile teams (there are tons!) and, more importantly, how to use them. Whenever I explain a metric to someone, I always include what behaviors the metric may drive and how to avoid misuse of the metric. When metrics are used inappropriately they drive bad behaviors and result in teams gaming the metrics. Even when used properly, leaders and teams must understand that almost all metrics have a shelf life - they cannot be used forever and continue to produce the same level of improvement.

One example is team spillover. Many see spillover as a cardinal sin and will not tolerate it. The guidance I give is you want to limit spillover, but occasional spillover should be expected as the team adapts (new tech, more robust Definition of Done, innovative practices, etc.) and shouldn't signal concern unless it happens repeatedly. Eventually the team will become so good at course correcting that spillover may not even be monitored. The team may move to a purely Kanban system where the focus is on flow and SLAs instead of time-boxed commitments. Regardless, spillover should never be used to evaluate team members. Including spillover on an eval is a guaranteed way to get sandbagging.

Why is this on my mind today? Because today is Thursday, and my Introspectives are due on Wednesday. My tardiness is due to a combination of too much WIP and plain forgetfulness. This past week has been very busy for me due to my division's Year Beginning meetings, the process of transferring to a new team, and my usual day-to-day work. I am focusing on limiting my WIP so that I can better manage what's on my plate. Next week's Introspective should come on Wednesday, but I can't guarantee that I won't miss my self-imposed deadline the rest of the year.

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.

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.

Introspective: Max allowed BMI at the Gym

As I've mentioned before, I'm overweight and have been for the majority of my life. I've been trying to change my habits and behaviors to foster increased health in hopes of lowering my BMI (Body Mass Index). One of the behaviors that I'm trying to make a habit is attending the gym regularly.

I have a friend that I usually work out with, and we've had conversations before about how non-judgmental most people at the gym are (at least at my gym). We've talked about how detrimental it would be to someone's health to feel unwelcome at the gym exactly because they are overweight and needed it more than those who are already fit. What good would a gym be if it had a maximum allowed BMI required for admittance?

Gyms want overweight people to go to the gym so that they can improve their quality and quantity of life. They know that not everyone who signs up will show up, and they know that not everyone who shows up will attain the same results. That doesn't stop them from doing everything they can to provide options and incentives for people to get the most out of their membership. Gyms would love for everyone to get down to a certain BMI or PBF (Percent Body Fat) and increase their lean muscle mass and stamina. Yet they also celebrate with those who are still overweight but have manage to get off of half their blood pressure medications. It's about developing a mindset and behaviors that help people trend towards greater health.

One thing that really bothers me is when "Pure Agilists" declare that you must be doing certain things or following certain methodologies or frameworks to be considered Agile. They further condemn any organization that's not operating under their gold standard of Agile. Some examples I've heard recently include: "If you have a hardening Sprint then you're not Agile"; "If you estimate in hours then you're not Agile"; "If your Scrum Masters aren't dedicated then you're not Agile"; "If your customers can't get involved daily with the team then you're not Agile"; "If your approach isn't endorsed by one of the original Manifesto signatories then you're not Agile"; etc.

As an Agile Coach, I have in my mind what I think an "ideal" Agile team looks like. Just as a team should have a Product Vision and a Technical Vision that guide the team's plans, they should have an Agile Vision to help guide their practices. Mine Vision is basically a flat organization of self-organized teams that are running DevOps using Kanban or something similar. They leverage SOA and have near-perfect APIs, making dependency management trivial. Production releases occur as frequently as new functionality is developed with zero defects slipping to production and high levels of customer delight. The teams are like families and there is no overtime.

Now I'd like you to take a stab at what my teams actually look like. Spoilers: it's not what I just described. It is impossible for an organization that is entrenched in heavyweight policies, Waterfall approaches, and a Command-and-Control management style to up an become "Pure Agile" one morning. It's too painful to succeed. What they can do is establish an Agile mentality and start making incremental changes. As they cut waste and increase value, they'll find themselves more and more resembling an ideal Agile organization.

"Scrum...but" gets a lot of flack, but I'd rather work with a "Scrum...but" team that's trying to continuously improve than a Waterfall team that thinks it's got it figured out. There is not maximum allowed waste cutoff for teams to start trying to improve. Those who promote Agile approaches need to be more open-minded about what is and isn't "permissible" for an organization that's trying to adopt Agile.

I had the opportunity to present on Agile to the local PMI chapter last night. For many of them, it was their introduction to Agile. If I'd have told them they had to go all or nothing, they would have shut down. My focus was on the Manifesto and its Principles, then showing them just how many Agile tools are at their disposal. I told them to respect reality, learn what's available, and continuously improve. Isn't that what Agile is really all about?

I know this is probably going to rustle some jimmies, and that's okay; if your jimmies are rustled, let me know why. What do you not agree with? How am I wrong? I don't claim perfection, and I'd love to learn from your perspectives.

Introspective: Moist Robots

I liked this book so much I bought it
for my brother's graduation gift!

One thing you need to know about me is that I'm a huge fan of Mr. Scott Adams of Dilbert fame. Sure his Dilbert comics are funny, but I'm much more fascinated by his non-Dilbert writing. I'm over halfway through his latest book, How to Fail at Almost Everything and Still Win Big, and it's a fascinating read. One concept that he's hit on multiple times, both in his book and in past blog posts, is the concept that humans are much more like moist robots than logical, rational beings. What we believe to be free will doesn't actually exist; all choices are determined by a combination of previous experiences, our body's current chemical makeup, environmental conditions, etc.

While I don't fully agree with Mr. Adams on the matter of free will, his hypothesis has tuned me into things that are easy to control and also lead to good decision making (versus leaving choices as hard and having to exert willpower, which is unsustainable). I was able to flesh these thoughts out a little more when a co-worker of mine asked me to revise one of our proposals to Agile2014 in response to the reviews we were getting. Our proposal, entitled "The Secret Sauce of Agile" (I'm open to alternative titles, by the way), builds on Mr. Adam's hypothesis that we are moist robots. I'd love your feedback on it.

Now let's switch gears and talk about how hard it is for lifelong fat people (such as myself) to lose weight. This is another topic that Mr. Adams covers in his book (though I haven't gotten to that part yet). I've had periods of relative health, but it's only considered health relative to the rest of my life. Compared to people who are actually healthy people, I don't think I can say I've ever been healthy. So I've been trying to get healthy by using the concept that we are moist robots. I have been on the lookout for things around me that are easy for me to control which will, in turn, make it easier to make healthy choices.

A lot of the things I am doing are just good sense: don't buy unhealthy food at the grocery store; don't go shopping when I'm hungry; don't carry change and small bills for vending machines; pack my breakfast and lunch; carry a water bottle; keep gym clothes in my vehicle; etc. The idea is to not focus on changing the hard things. I'm not going on a grapefruit juice diet. It's just not going to happen. But I can change a bunch of little things quite easily so that, when the time comes to choose between healthy and unhealthy, I can pick healthy choices while expending the least amount of willpower. After all, we humans have limited willpower to expend daily (some more than others).

This is applicable to everyone and everything. Use this with your Agile teams. What problems are the team having? What small, simple things can be done to prevent those problems from surfacing? What tweaks in the way your team runs can be applied to make it easier for each person to make more Agile choices? Seriously, what? Bring this concept to the table and let me know how it goes!

First (Legit) Introspective: Social Time vs. Quiet Time

Time Vortex, or Arctic Vortex?

The first couple of days this week were surprisingly productive for me. I say surprisingly for two reasons: 1) the "Arctic Vortex" (which totally sounds like something out of Doctor Who) caused school cancellations, along with reduced attendance at work and cancelled meetings; and 2) I still ended up spending almost all day Tuesday in meetings. This means that I was improvising on Monday and having my day planned out for me on Tuesday, neither of which have very good track history for me.

A couple of things made these days productive. First, my team spent some time on Friday to populate our backlog, which was in serious need of grooming. Having work ready for me to pull made it so much easier to fill my time productively. Please note that I'm not saying I'm not productive without a well-groomed backlog of work to do, just not as productive. Second, I had a nice balance between time to work with people, socialize ideas, and have healthy debate, and time to sit quietly at my desk and knock out work that needed to be done.

SERENITY NOW!!!

I've spent the better part of the year encouraging people to work together more: increased collaboration, co-location, pair programming, and the like. So the thought that I needed time to myself to be productive never crossed my mind. It was a weird realization to have, to say the least. I'm glad I had this experience (and even more glad that I took the time to reflect on it) so that I can more easily relate with those who raise concerns about the lack of personal space and private time as their team transitions to Agile. I also need to brainstorm ideas for creating a quiet, private space in the midst of a chaotic, Agile team environment. Any suggestions?

Introspective addendum

As I started today's Introspective I realized something important: Fridays won't work for Introspectives. For starters, I've only had a few days to reflect on this year. Also, I'm much more likely to be off work and/or unfocused on Fridays.

So I'm failing fast and moving my Introspectives to Wednesdays. Now I just need a volunteer to come to my desk each Wednesday and say, "Mike Mike Mike Mike Mike! What day is it?"

New Year's Resolution: Kaizen!

If old acquaintance be forgot and never thought upon then you're not holding retrospectives correctly.

I've never been a fan of making New Year's Resolutions - their short life spans are clichéd for a reason. I've also been reading Scott Adam's new book "How to Fail at Almost Everything and Still Win Big", and one of the major themes in the book is that goals are for losers; winners use systems. This resonates with the Agile principle of continuous improvement through inspecting and adapting.

So my New Year's Resolution this year is not a goal, but truly a resolution. I resolve to exercise personal Kaizen. Continuous improvement has been a major part of my life for as long as I can remember, but it hasn't always carried the urgency associated with Kaizen. I'm going to experiment more so that I can fail more so that I can learn more. I'm going to schedule Introspectives (1-person Retrospectives) on a regular basis whereby I can challenge my own personal status quo.

I wouldn't be an Agile Coach if I didn't encourage each of you to adopt Kaizen as a New Year's resolution as well. If you don't like the commitment associated with that term, can you commit to trying it just for January? Each Friday in January, I challenge you to hold your own Introspective. Ask yourself what you did well and what you could have done better. You may have made good decisions, but did you make the best ones? Did you have an answer for each time you were asked "Why"?

I'll be sharing the results of my own Introspectives every Friday this year. What I share may not be comprehensive, seeing as how I don't have the time to write out all the context for my results, but I'll share as much as I can within reason. I'll also work hard to blog frequently between Introspectives in an attempt to get more of a dialogue going than I've been able to in the past.

If you decide to take on my challenge, please share your results with me. You can comment on my blog, message me on LinkedIn, or tweet me @MLCarey321. I'd love to see the effects of personal Kaizen in your life!