John Doe, MBA, PMP, EIEIO

Just ran across a profile of an ex-colleague who had abbreviations following his name on a networking site.

We should all be proud of our educational accomplishments and certifications, and they certainly hold a place in the job-search process. But I find the addition of these attributes to be out of place in many environments (e.g. Linked-In, Facebook, and resume titles).

Joe Schmo, HS Grad, BSCS, MBA, PMP, CSM, MCSP, MCP, NCP

Let's remove the certification crutches and talk about what you're doing and how you add value.

- Cranky

defenestration hotel ads

Looked up defenestration on the web (dictionary.com) in order to provide the link to someone. I found the ads an interesting mix.



I can understand ads for hotels in Prague, given the defenestration of Prague, but I'm curious about any heretofore unreported defenestrations in Orlando.

Peeling potatoes

I had an interesting conversation with an enlightened product manager recently. We love to converse in analogies, and a recent one surrounded the difficulty of completing the required scope of our release plan in the timeframe allotted. So, out sprung the analogy... trying to fit 10 pounds of potatoes into a one-pound [capacity] bag.

The extension to the analogy is that peeling the potatoes to make them fit is an insufficient approach. It may be appealing in the sense that you're making progress, but the order of magnitude difference required to make the potatoes fit will never be satisfied by a peeling approach.

A similar analogy might be suggesting to folks on the Titanic that they pick up a bucket and start bailing.

When great change is needed, great courage is required to make game-changing differences in approach. Otherwise, you're just postponing your date of failure.

Path to Passion

I had an interesting dialog with a colleague recently. He left a long, multi-year consulting stint a few months ago to join a start-up in Silicon Valley. He's absolutely loving it. The excitement and passion are prominently on his sleeve.

Many of us have probably felt this excitement on certain jobs or certain assignments. A year ago I had a job/assignment where, on occasion, I would wake up on a weekend, think about getting ready for work, and feel disappointment upon the realization that it was not a work day. What a wonderful sensation. I've worked on other projects where I've felt similar passion.

Of course, I have also been in jobs where I've been so sapped of energy and enthusiasm that it seems, in hindsight, that I simply marched like a lemming in the proposed direction. I remember trying to change things and meeting more resistance than I could surmount, and then, sad to say, submitting. I was professionally... dead. I can blame it on my youth I suppose. The last time I can recall being severely numb was around '94 or '95. I never wish to experience that again. More to the point, I will never allow that to happen again.

As a consultant, I get to spend time with different companies of different sizes in different industries. I really enjoy the work - particularly in the first month or two as I learn about the client, domain, people, challenges, and ... opportunities. As I spend time in these new places, I find some people who are passionate about what they are trying to achieve. This always gives me hope; it is typically these people to whom I gravitate. But I also see many who seem to be marching or strolling along, without passion, desire, or commitment. I find this frustrating.

Of course, we don't all have to draw deep satisfaction from our work; other priorities can make up for the lack career excitement. But here's the thing... if you have to spend 40 hours a week doing something that doesn't get your motor running, why not find something that does? It doesn't necessarily mean you quit your job for another, but at least make progress towards that other thing that excites you. If you're a musician and would rather be playing in a rock band than doing corporate tax returns, practice, go out and meet other rockers, attend open mike nights, etc. Make some progress.

Don't accept a job you're not passionate about unless you can find a path to passion. And if you're in a job with no path to passion... snap out of it man !

Wanted: Software Development Leader

One thing led to another and there I was contemplating the job req for what I would look for in (and what I strive to be as) a software development leader.

Experience:
- Development experience - preferably within the last decade

Aptitude:
- Can tell a crappy architecture from a sound architecture
- Can tell a crappy implementation from a sound implementation
- Can tell the difference between someone who is busy and someone who is productive
- Can discern the difference between a good candidate for a position "on paper" and a good candidate for real
- Demonstrates a deep understanding of what quality means for a software product (including non-functional requirements like performance, supportability, and extensibility)
- Can tell when an architect, developer, QA, BA, or business partner is blowing smoke up his hind quarters
- Can speak the dialect of business - ROI, NPV, customer acquisition cost
- Can relate to business stakeholders and build collaborative relationships
- Can connect to team members on a personal level
- Has a good sense of humor
- Understands the difference between a prototype and a production application

Attitude:
- Will call out a crappy architecture and drive change
- Will call out a crappy implementation and drive change
- Will call out the busy-bees and the smoke-blowers
- Will demand demonstrable quality (including non-functional requirements)
- Will demand reasonable tests (unit tests, component tests, system tests)
- Does not suffer fools gladly
- Will not sit through a PowerPoint that depicts supposed progress without demanding demonstration of said progress
- Will not abide bubble gum and duct tape solutions to production (or development) defects
- Demands continuous improvement
- Demands root cause analysis (5 why's)
- Demands customer involvement in product development
- Continuously seeks to improve efficiency by asking "why" and "how can we do this more efficiently" (e.g. - PMO requirements for excessive documentation)
- Is willing to fight for the resources required by the team to deliver
- Cares deeply about the team
- Cares about the career development of team members
- Cares deeply about product quality
- Will celebrate true success with the team (no gratuitous applause please)
- Will always give credit to the team for success
- Will remove team members when necessary
- Has a coaching mentality
- Is willing to get hands dirty (writing code, writing/running/debugging tests, fetching pizza)
- Is always available to the team
- Exhibits patience, when appropriate
- Exhibits impatience, when appropriate

Integrity:
- Tells the truth - for instance about project status
- Is clear to team members on expectations and performance on a regular basis (not just at review time)
- Is willing to stand up and fight for the team

Ah... it's late. that's as far as I got. I felt like the integrity section was short, but many of the integrity issues bled into attitude. What did I miss? What do you disagree with?

Dysphemism and cross register synonyms

I love learning new words. During a conversation in our open-space collaborative software development team environment last week, I used the term euphemism incorrectly. Thanks to Steve Moyer for pointing out the error of my ways.

Apparently, the subtlety is that a euphemism substitutes a less harsh term for another term. I can't remember what I said, but it was akin to saying "The head" was a euphemism for a restroom. Since "The Head" is harsher, it was not a euphemism, but a dysphemism.

Had I said that "Powder Room" was a euphemism for "The Head", I would have been correct in my usage.

By the way, these two terms are considered cross-register synonyms. Cross-register synonyms vary across some orthogonal degree on their subject. For example - dysphemism and euphemism are cross-register synonyms that vary in their degree of harshness. I found a good description of this particular cross register synonym and cross register synonyms in general here: http://www.linguistics.ucsb.edu/faculty/cumming/ling50/euphemism+dysphemism.htm.

Agile Pants

I found these "Puma Agile Pants" when doing a search on Amazon for agile literature:



Agile Pants... don't pair without a pair.

Test Lookup

Kris Kemper has a nice blog entry on finding tests related to code you are changing that lines up well with a concept I've been pondering today.

I have a colleague who asked me to look over a rather large C# software system, made up of many (>20) .NET projects. In the best agile way, he is relying on his elegant structure and well-named/concise tests to serve as the documentation for anyone who might try to understand the code.

Being self-aware, my colleague understands that he is too close to the subject to be able to determine "understandability" of the code by others. So he asked me - an outsider - to take a look. I think he was also hoping that if I - as a supposedly post-technical project manager - could understand it then he could brag that his code was so understandable that "even a PM can understand it". (Reminds me of those old Life cereal commercial where Mikey, who never likes anything, likes the cereal and his siblings declare "Even Mikey likes it !")

So I picked a class at random. Nice short methods, but reading the code didn't give me as much insight as I hoped. Then I thought... ah the tests. I'll read the tests. So I right clicked, searched for usages, and navigated to the location that had "unittests" in the name. Then I thought - wouldn't it be nice if I could right click on a method name, or a class name, and - instead of asking for usages - I could ask for tests.

That got me to thinking - what would constitute a test? A unit test that simply invokes a method or instantiates a class may just be using it for setup or for supporting scaffolding. But then wouldn't that be a smell? Shouldn't that irrelevant setup junk be in a setup, or injected or...

Anyway, Kris gets to much of these points... my main extending thought is simply - wouldn't it be nice if the tools could help us navigate to tests and sniff out those smells (rather than force them by removing the method, as Kris's technique suggests)?

Halftime

In American football, the game is divided into four 15-minute quarters. There's a short break between the first/second quarters and then between the third/fourth quarters, but the middle transition is longer. It's called halftime.

During halftime, teams return to their locker rooms for respite, but more importantly, coaches use it as an opportunity to adjust the game plan and motivate the team.

Much is made of the halftime break in football. I think the concept is equally useful in ... agile software development.

I introduced halftime on a couple of agile software development teams to step back and look at iteration (or sprint) goals at the midpoint of the iteration, to see where we stand, and adjust our approach. It has been a good opportunity to refocus, adjust sprint content, and address issues.

In a recent halftime, I pointed out that the scope for the iteration was 63, and that we had burned up 20 points. I used the analogy that our opponents had 63 points and we had 20 and that we need to figure out how to make up the difference. We adjusted our approach, removed some scope and went on.

If you're stuck in a project where the iterations are too long (e.g. four weeks), suggest introducing a short halftime (30 minutes) to refocus the team and adjust. Even if you're in 2-week sprints, doing a checkpoint/halftime at mid-iteration can be useful. It's also a good segue into shorter iterations.

Is it ever NOT what it is?

The phrase "It is what it is" bugs me. It falls into the category that includes phrases/clauses like "Going forward..." (as if you could go backward) or "To be honest" (an admission that what you're about to say is a departure from the norm).

I just heard a new one in the concierge lounge at a Marriott: "It'll be what it'll be". I think it was related to sports.

So, here are some suggested enhancements to the dialect:

* It won't be what it won't be
* It will never be what it never could become
* What wasn't, wasn't
* To be or to be, that is the [rhetorical] question
* It probably wasn't meant to be because it wasn't meant to be

I'm sure there are more clever opportunities here.

Agile adoption by geography

I wonder if there is a geographical distribution to the adoption of agile philosophies. To find out, I used Dice's job listings as a proxy to determine percent of postings that matched the word "agile" by City.

Suprising to me, Salt Lake City seemed to take the honors @ 12%. Next tier: Richmond, Seattle, Portland, OR, San Fran, Denver, Austin, Raleigh, all between 5% and 9%. The remainder can be seen on the graph. It's probably a bit too small to see, but if you display it individually, you should be able to clearly see the list of cities and the rough placing of the cities within the distribution.

Results:

Open Command Window Here

I spend a great deal of time at a command prompt on my Windows system. I recently found a a nice little Windows XP PowerToy that allows you to right click on a folder within windows explorer and then click a menu item to open a command prompt with the directory set to the folder you right-clicked on. How did I live without this for so many years?

Go to http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx and download the "Open Command Window Here" power toy. (I actually did it by hacking the registry, but avoiding regedit is good practice).

Linked In Recommendations

To what extent do you think your Linked In recommendations of others, and others' recommendations of you reflects on you?

An old colleague requests a recommendation - you kind of know him/her, but not well. Or maybe you know him/her, but don't respect his/her work. Do you recommend? An incompetent ex-colleague offers a well-articulated recommendation for you. Do you accept?

NO !

Don't do it.

Maintain a high bar for your recommendations so that they mean something. Turn down requests for recommendations for anyone who you wouldn't hire yourself - into your own department, or, better, into your own company. I think the latter is a pretty good rule of thumb.

Don't accept recommendations from people who you would not recommend yourself. The volume of recommendations is not important; it's the quality - both from how well they are articulated and from the standards of the source of the recommendation.

I was thinking at one point of asking someone for a recommendation. This person has a title that would have made for an impressive recommendation. Then I saw that she recommended a person for whom I did not have high regard. I decided against asking. Why? My recommendation would have been devalued by the other recommendation. Granted - not many others would have known or understood... but... I would have known. And others' may have learned.

I want to be recommended only by people for whom I have the highest regard and who I would have no hesitation recommending.

And I want to be recommended by folks who have recommended others who have achieved a high bar of performance.

And I insist on only recommending those who I feel I can honestly promote - based on my interactions and experience.

You too, should maintain high standards in your approach to recommendations.

Interesting question on LinkedIn:

What is the difference between an approach and a methodology?

What is the difference between an approach and a methodology?
Is it true that approach is just an idea and is less proven while methodology would normally start as an approach but is eventually time tested and proven? What takes an approach to convert into a methodology?

Here was my response:

I think of an approach as the foundation, or underlying principles that guide you in how you get your work done. I'm an agile software development proponent, and I strongly support the approach/philosophy expressed in the agile manifesto (http://www.agilemanifesto.org).

Methodologies, to me, prescribe more detailed steps to take to accomplish goals. Scrum is, in essence, an agile approach (the mantra is "inspect and adapt"), but it gets applied in many instances as a methodology (Though shalt provide a burn-down chart).

Methodologies excuse people from thinking about underlying principles. If you follow the rules for making a burndown chart, your methodology has been followed, but if you are avoiding opportunities to gain greater insight by taking a different tack, you are avoiding the approach/principles.

An analogy to cooking - using a methodology is like following a recipe - with your measuring spoons/cups at hand, precise temperature measurements, etc. Using an approach/principle requires more understanding of the ideas... the fact that sauteeing onions releases liquid gives you some information that allows you to adjust to other aspects of your cooking (like don't try to brown your meat while sweating your onions, because the released liquid will cause your meat to steam instead of brown).

In sum, I would say an approach requires more thinking and adapting, while a methodology provides more training wheels to give you procedures that you may not be able to link to the underlying approach/principles. I think that beginners require methodologies (like beginning cooks require recipes) while experienced folks can apply fundamental principles based on sound judgment (like experienced cooks simply press down on the steak to assess doneness instead of measuring the time).

XP Game in Fort Lauderdale

I facilitated a lego XP game for the Agile SIG of the Florida .Net user group at the Microsoft campus in Fort Lauderdale tonight - great fun ! Thanks to two of my colleagues from Bayview for playing the customer roles: Howard Sims (project manager/iteration manager) and Samir Patel (development manager).

Dave Noderer blogged in real time and took a video.

It's fun to watch adults get so engaged with legos.

28nd of the month

Received from Linked In at 12:10 am EST on May 29 (9:10pm May 28 in PT terms)

LinkedIn is currently unavailable while we make upgrades to improve our service to you. We’ll return around 9:30pm (PT) May 28nd, 2008.

We apologize for the inconvenience and appreciate your patience. Thank you for using LinkedIn!

The 28nd?

9:30 PT update: new message:

We’ll return around 9:45pm (PT) May 28th, 2008.

I like the noncommittal "Around" as a qualifier...

A semi-clean, well-lit, open-place

These are a few pictures of my team room. I love this place - high ceilings (with plenty of space for information radiators), lots of card walls, lots of white boards, movable filing cabinets, and a few cubes for the stationary folks. This is really a retail space the size of which you could probably house a basketball court.

We had an open space in the front that isn't pictured with a couch, some beanbag chairs, a conference table, a projection screen with a projector. We almost never had to schedule meetings in the limited conference space in the main building again.

A good view of most of the card wall. This is fairly old - we now have flipcharts with our historic burnup charts posted over the card wall so we can see our trends.

This gives a good view of the dimensions of our space.

The little white box area in the back is a portable office - 10x10, with privacy for personal phone calls, personnel meetings, etc.

The continuum

Is your software development approach agile or not?

Are you pregnant?

These are different questions. The latter question can be answered in a straightforward fashion... either you are or you aren't.

Using an agile methodology is a different question. Or an agile approach. Or an agile philosophy. Are you agile... yes or no?

The answer is almost always somewhere in between. You can use agile techniques (pairing, continuous integration, TDD, refactoring, user stories (following the INVEST principle), standups, abstract estimation techniques (e.g. points), iterations, velocity measurement, etc... in any degree. But what combination makes you "agile" ?

I think the answer is never yes or no, but the degree to which you espouse, promote, and enact agile approaches.

I think the continuum concept applies much more broadly than folks presume. Is your team "self-directed"? That's not a yes or no answer either.

Is being agile a good thing? Yes. Consider any course of human activity... being agile is better than being less agile. Am open to contrasting opinions, but I can't imagine an argument espousing being less able to adapt to change as being preferable. The chunked-up question is ... how useful are agile techniques in getting software delivered? I argue that the answer is "very". Why? The first answer lies in the fact that you NEED to be able to adapt to changes in your environment. Guess I'll save the remainder of the argument for a follow-up.

Top Chef Leadership

I'm becoming addicted to Bravo Network's "Top Chef" show. OK, so I'm generally addicted to cooking shows, but have, heretofore, confined my addiction to the Food Network.

I feel the role of a chef is a melding of cooking and leadership. Top Chef seems to focus more on the cooking aspect, and the extent to which folks step up in the delivery of good food. I think this misses a large part of the role of a chef. It's not enough to be able to deliver high quality food. You have to be adept at inspiring the other cooks in your kitchen to deliver.

Nikki, one of the chefs who was eliminated recently, was canned mostly because the menu was Italian, and she didn't exert leadership in driving the menu; her forte' is Italian food. So her inability to exert leadership was pivotal for her. One of the guys who escaped elimination focused on one dish - vs. another who went to the mat for the team in doing almost everything else.

When the elimination was announced, other chefs shook their heads. They knew that the one-dish guy should have been the one to go...

An ex-colleague of mine regales me of similar stories from her company. Promotions that make mouths gape, people surviving layoffs when more capable people are released. She sees some of the same aspects from "Top Chef" in that company. One-dish wonders survive because they play the game better than others. I sometimes wonder why "Top Chef" doesn't ask the other cooks directly about who should be eliminated.I guess that's show business.

The "Z" Word

Zealot: A fanatically committed person.

Hmmm... good or bad?

It suggests an unfavorable hue to me. I've seen this word used before to describe folks' commitment to a particular technology platform. He's a .NET zealot, or a Ruby zealot, or Zope zealot.

In the case of technology (most cases?) zealots prefer their approach/solution to all(?) others. For instance, how could you turn back from having written significant code in Ruby to doing plain old Java? Those who aren't writing in Ruby have simply not yet been shown "the way".

I consider myself fairly pragmatic and reasoned, but I seem to have acquired the dreaded tag at work. My zealotry is in an agile approach to software development. (English zealots - note the use of the article "an" vs. the article "the" - it's an important distinction).

I'm measuring whether I should shrug the label off, welcome it with open arms, or fight it. Actually ... that's not quite accurate. I'm pretty sure shrugging it off will not be my chosen response.

At some level, I feel it's like being called a "rationality" zealot... or a "damned common sense practitioner". I'm a "Sunrise Zealot" damn it ! I find the agile manifesto chock full of common sense. (OK, here I see... manifesto => zealotry... maybe if Kaczynski and Marx hadn't also used the term manifesto we'd be in better shape).

Some software development professionals unabashedly promote a "waterfall" approach using a document-centric "SDLC" lifecycle. Templates are created to capture every known aspect of the project. Stakeholders are forced to "sign off" on documents, which form a contract-like agreement to what will be delivered. Of course, a change request process is included, which affords the opportunity to create change documents which are then signed-off.

Agile is not binary... agile is a continuum. There are agile development techniques and agile project management approaches. You can use any of them - or not. The use of one technique does not an agile project make.

Agile, chunked up, (to me anyway) is about focusing on the delivery of quality software over and above delivering service to a process. The customer is not a color-copier and a list of signatories to a spec. The customer is the user of the software; the organization that benefits from working, functional, valuable software. No organization prefers reams of documents over working software. And those that argue voluminous documentation better leads to working, functional, valuable software should start measuring the extent to which those documents are implemented as stated. After all, not many approaches refine their processes to eliminate waste (ala Lean).

One should question the value of accepted process (using the Five Whys, for example) in order to assess the usefulness of documents and other artifacts to ensure they stand the test of reason.

OK, my writing therapy is done. I hereby embrace the label "Agile Zealot". I also accept the following additional labels: "Fatherhood Fanatic", "Beer Lover", and "Education Enthusiast".

I do like the alliteration angle though... may I please be an "Agile Aficionado" instead? Ah, but perhaps that doesn't quite capture the intensity of my rapture.