Adrian's Tech Blog

Stand-up efficiency and effectiveness

2011-10-06T10:16:00.000-07:00

I attended a user group meeting last week where a participant asked the question: “How do I keep my stand-ups from going so long?”. He cited greater-than 30-minute time for 10 people.

I didn’t get a chance to talk to him, but here is my advice.

First, discuss the topic with the team. Ensure that there is agreement that long stand-ups are negatively impacting the team. It may be (but it’s unlikely) that the content of the long stand-ups is important to everyone,

Determine root cause. I find a couple of causes that can be addressed in different ways.

Long-winded people offering irrelevant input or input that is relevant to only one other person: Record the contributions of each of the long-winded folks and review with them. Identify specific content that is not relevant to the team.

You’ll often find paycheck rationalization offerings (e.g. “I had my one-on-one with my manager yesterday”).

Or you may find someone simply regurgitating their calendar (managers are likely to be the offenders here).

Or it could be politically driven public thrashings that are more appropriate to share in private (“David – you seem to be checking code in without any tests. Remember, we agreed that we would write tests”).

I’ve seen stand-ups where multiple team members will regurgitate events in which the whole team participated. If the whole team attended the iteration planning meeting, there is no need to mention this in the stand-up.

Start timing folks. If anyone talks more than 2 minutes, make them stand on one leg, or ask them to extend their arm holding a heavy book while talking. Or use a timer (obnoxious alarms are best).

Conversations that are not relevant to the whole team: Institute a “parking lot” flip chart or white board where topics for further conversation can be captured for discussion after stand-up. Ask the whole team to help identify potential parking lot items when they occur; add them to the parking lot when identified and move on. Ensure that those follow-on conversations occur (else you run the risk that folks will continue to insist on in-stand-up dialog).

Use a speaking token and ask the team to be rigid about not talking when they don’t have the token. As conversations occur, the token passing will make it obvious that a conversation is occurring, which should help folks to self-identify opportunities to use the parking lot.

Explain to the team that the stand-up is not the only opportunity for conversation during the day.

Use a laser pointer to have folks point out the relevant stories/tasks on the physical card wall as they speak. They will be less likely to pontificate on irrelevant details if they have no card to point to.

I’ve attended stand-ups of over 40 people that have taken less than 10 minutes. That’s less than 15 seconds per person. Granted, these were teams that were pairing, so oftentimes the contribution of the second of the pair was of the form “ditto Joe”. Still – if a team of 40+ can get it done in 10 minutes, there’s no reason why your “2-pizza team” cannot.

Prioritizing vs. Sequencing the Product Backlog

2011-06-30T08:21:00.000-07:00

A primary tenet of agile software development is doing the highest business-value work earlier. The idea is that you achieve a minimal marketable feature set as early as possible so that a) you can issue releases earlier and b) if the money runs out, you have something more valuable than if you didn't sequence your work in that manner.

Another, less frequently cited agile tenet is to do the riskiest work earlier. The idea here is that you avoid late surprises when risky work turns out to be expensive. Better to discover this expense earlier.

When most folks talk about the backlog order, they refer exclusively to business priority.

I think ordering or sequencing the backlog must take more than just business priority into account. Yes, business priority is important, but so are a whole host of other factors, such as early exposure of risk. Balancing these factors is part of the art of project management.

Factors to incorporate into sequencing decisions:

Business Priority
Dependency Order: Despite our best efforts to decompose the backlog into independent stories, the fact is, the tension between the INVEST priorities sometimes cause us to define stories that are dependent on other stories.
Mixture: The Rock/Pebble/Sand metaphor is helpful here. Consider a bucket at the beach. If you fill it only with rocks, you have a great deal of wasted space in the bucket, due to the space between the rocks. Though it may be unable to accommodate another rock, you may be able to slip in a handful of pebbles, to fill the spaces. Following that, you may be able to slip in some sand, to fill the spaces that the pebbles were unable to occupy. So it goes with an iteration. You don't want to fill your iteration bucket with only large stories, because you're losing the opportunity to slip in smaller stories. For example - if a developer finishes a story at 3pm on a Friday afternoon, you'd probably rather have him knock off a small story in the next couple of hours rather than start a large story.
Crowding: Many advise that agile development teams define iteration themes. This is a good concept in theory, as it allows the team to focus on accomplishing a larger goal in the iteration. The risk here is that you have your whole development team working in the same parts of the code base. This can merge issues as the team commits code to the code repository. Consider the source-code crowding problem when sequencing the work.
Risk: As mentioned above, the earlier you schedule the risky elements of the project, the more insight you have into your completion date. One element of risk is embedded in non-functional requirements. For example - if you have performance or scalability requirements that are risky, it's better to implement the stories that are sensitive to those requirements earlier.
User Feedback: If you have elements of the software for which user feedback is critical to making the right decisions, schedule this work earlier. If you delay these features towards the end, the need to change the system in response to the feedback becomes a schedule surprise. Worse, if you decide not to incorporate the feedback in order to make your date, your users are not just unhappy; they'll feel that their input has been ignored.
Exercise the architecture: Scheduling the highest business value work first may avoid elements of the architecture into later in the development cycle. For example, perhaps the "happy path" of execution is deemed the higher business value. This might delay consideration of elements of exception handling to the end of the release. First pass implementations within an architecture are always riskier, and could introduce schedule surprise. It is wise to exercise all elements of the architecture as early as possible.

As I mentioned, these factors are often competing. The context of your project defines which of these dimensions are more or less important. Yes, do the highest business value work earlier, but don't forget to consider these other factors as well.

Feedback Manifesto

2011-06-28T19:07:00.000-07:00

I have come to value

Verbal, constructive feedback over written evaluations
Measuring output over measuring input
Frank feedback from colleagues over speculative management judgment
Real-time, frequent feedback over periodic high-ceremony assessments

Though the things on the right are commonplace and often dictated by antiquated HR policies, I value the things on the left more. Much more.

Principles

Giving feedback

My highest priority in giving feedback is to help my colleagues improve - to benefit them individually and the organization collectively. I always preface my feedback with this sentiment.

I understand that not all recipients are comfortable with feedback. I choose the time and place of delivery to respect this sensitivity.

I always ask the recipient if he/she is willing and receptive to feedback at that time/place and graciously accept "not now" for an answer.

My feedback focuses on behavior and outcomes - not the person.

When providing critical feedback, I consider the constraints and challenges in play at the time of the performance for which I am providing feedback.

I acknowledge intelligent risk-taking as a necessary component of creativity and delivery of value and incorporate my appreciation for it in my feedback.

I ask for feedback on my delivery in order to continually improve my ability to give constructive, valuable feedback.

Receiving feedback

I welcome critical feedback about my performance as a gift, and express my appreciation accordingly, regardless of whether I agree.

If I am not in a good place to receive feedback, I respectfully request an opportunity to reschedule.

I refrain from defensiveness or questioning the motives of the person giving me feedback in order that I can absorb the essence of the feedback.

The case against iteration based re-estimation

2011-06-20T14:22:00.000-07:00

Many agile practitioners recommend re-estimating stories at the beginning of each iteration. I disagree with this practice.

For one thing, I believe it's a waste of time. Any value that you might get (which I doubt - see below) from the practice is lost on the time spent.

It's worse than that though. By re-estimating the iteration's stories, you are almost always estimating with a greater level of detail than what you had originally. With this increased level of detail, in my experience, estimates tend to grow.

Why is this a big deal?

Let's try an example.

I come in to my iteration planning meeting with 30 points worth of stories from the backlog. The team commits to those stories, but in re-estimating, the 30 points inflates to 40. In fact, this always seems to happen, as the team gets a little nervous about hitting their historical velocity and they know management is paying attention. Let's assume the team gets them all done. This increases the observed velocity by a third (40 points is a third more than 30). Now, let's say I have 120 more points left in the product backlog to get to the minimal marketable feature set for release. How many more iterations are left?

If you said 3 more iterations (i.e. 40 points per iteration gets you to 120), you are ignoring your team's tendency to inflate estimates. Assuming your estimate inflation rate is consistent (a third), you really don't have 120 points remaining, you have 160 points, or 4 more iterations remaining. Or, calculated another way, if you consider only the initial estimates to calculate your velocity (30), then you can determine that you have 4 iterations of 30 remaining. In both cases, you end up correctly predicting 4 more iterations. Then again - if you use the initial estimates, what value did your re-estimation from 30 to 40 provide you ? I say none.

If you regularly re-estimate at iteration planning meetings, make a note of the original vs. the updated estimates. See if they grow. Consider what impact this is having on the accuracy of your release planning.

OK, I can hear you now. "My team's estimates don't inflate ... some go up; some go down". I haven't seen this, but let's say you do. Let's revisit the example from above with this assumption. You go into the iteration planning meeting with 30 points and walk out with 29. Your velocity is not materially impacted. You are still on track with 3 remaining iterations (roughly). So the question is this: what value did that re-estimation provide? I say none.

When *do* you re-estimate then?

I believe in updating estimates when information arises from experience that pertains to some shared aspect of a subset of stories. For example, let's say that your retrospectives have shown that every time you have a story that hits a certain database, it ends up being much more effort than expected. In a case like this, it makes sense to revist those database stories to ensure that this knowledge is incorporated into those estimates. I call this aspect-oriented re-estimation (adapted from the term "aspect-oriented programming").

The case against Chickens and Pigs

2011-06-18T05:53:00.000-07:00

Schwaber and Beedle's Scrum book introduces the pig and chicken fable to illustrate a point. It goes something like this:

Chicken:
Let's start a restaurant!

Pig:
What would we call it?

Chicken:
Ham n' Eggs!

Pig: No thanks. I'd be committed, but you'd only be involved!

The story is used to illustrate a difference between
a) the core team members - the "pigs" who are committed to the success of the project (blood sweat and tears maybe?) and
b) outside contributors - the "chickens" who contribute but are presumably not "sacrificing" for the cause

First - I think the analogy is confusing. I always have a hard time explaining it and I haven't heard a coherent verbal description of the concept. There's got to be a better way to make the point.

My higher purpose here, however, is to extinguish the point.

A commonly cited rule is that "only pigs can talk in the stand-up". There is an underlying premise here that anything a "chicken" or non-core team member has to say is wasteful of the team's time. A corollary perhaps: anything a core team member has to say is important.

I have participated in stand-ups where chicken "contributions" have been extremely valuable. Example:

pig: "My computer monitor froze last night; I need to order a new one"
chicken: "Stop by my desk after stand-up. I have a spare"

pig: "Today, I'm meeting with the product owner to review stories for the next iteration"
chicken: "Product owner is out sick today. Let's talk after stand-up about rescheduling or doing it remotely"

Or how 'bout a chicken who participates in the stand-up and shares relevant information. Maybe the normal contribution is "pass" (meaning - there's nothing of import to the team to share). But maybe she's got something important to say:

chicken: "Yesterday, I met with a group of 6 customers to review the prototype. Feedback was overwhelmingly positive. They had some good suggestions. Today, I'd like to sit down with Joe to review some of them and get stories added to the backlog".

What a great contribution to the stand-up! The team gets a valuable shot in the arm (positive feedback) and Joe gets a heads up on some work for later that day.

I've also witnessed many examples of core team members' verbosity and sharing unimportant information.

pig: "Yesterday I had a one-on-one with my manager and worked on my mid-year performance review"

Huh? It seems that this information is being shared not for the benefit of the team, but to justify someone's paycheck for the time they spent in the office.

pig: "I ran into an issue when creating the xyz service. When I compiled the code, I got an Exception in the compiler. I stepped through the compiler assembler logic, but couldn't figure anything out. I then spent about an hour on Google looking for the cause. I finally found this bizarre reference in a Japanese website - thank goodness for Google translation - but it's kind of funny how they botch the translation, I mean, it's not exactly the King's English. Anyway, I translated it, and found someone had this issue because they were running service pack 1 of the IDE without the next two patches on a MacBook Pro running Boot Camp. I installed the patches and still had the problem. I tried a bunch of other things after that and finally got things working. I think clearing the cache did the trick. I thought I'd be done yesterday, but that issue set me back a bit. Barring any other bizarre issues today, I expect to be done with the story by end of day.

OK, I made all that stuff up. This guy needs some coaching on being more succinct. There's some valuable info in there ("hey everyone - make sure you have those two patches", and "I should be done today") but it's buried in irrelevant detail.

My general point is this: I think the chickens/pigs designation is more harmful than helpful. Common sense - about what's valuable to share - should carry the day. Open and honest conversations with *all* participants about expected behavior in stand-ups and beyond should trump this arbitrary dividing line about whose voice should be heard when.

Agile talent market

2011-06-18T05:07:00.001-07:00

Do you have agile/lean running through your veins?

I know of a couple of great companies seeking agile/lean talent.

If you're not into travel - perhaps you've been on the road and are looking to settle down, Lab49 has opportunities in New York and London for agile UX, development (.Net/Java/other), and project management talent. Travel is minimal. Smart people. Finance domain.

If you're thinking of moving from a captive arrangement (employee of a company that owns everything you produce) into a more independent contractor arrangement, LeanDog might be the place for you. Their office is on a boat in Cleveland. A big boat. Great management team. Organizational transformation, coaching, training, delivery, multiple technologies, craftsmanship. Business is booming.

Contact me for an introduction to either of these great companies. Warning: both firms are extremely selective.

Agile within a non-agile ecosystem

2011-01-31T02:59:00.000-08:00

Agile, like Texas Hold 'Em poker, is pretty simple. The agile manifesto is straightforward. Some agile practices are more difficult than others. Stand-ups are probably the simplest agile technique (though it confounds me how difficult it is sometimes to get people to make them short and sweet, relevant, and focused). Test-driven development is one of the harder concepts to grasp. Estimation with abstract units is sometimes hard to grasp. These are all localized challenges that can be addressed fairly easily with team members that have the attitude and aptitude to change.

These team-based challenges are dwarfed in complexity, in my experience, by the immense challenges of adapting an agile team's relationship to the non-agile ecosystem in which these teams/organizations typically exist. These ecosystems often foist irrational demands on software projects in general (not just those of agile teams). An example: the budgeting process requires you to commit to your scope, schedule and resources up front. You're then damned when you ask for more time, money or request to reduce scope. This isn't just a bad practice for agile teams; it's bad practice for most software development projects.

Cultures that reward individuals based on heroics are another example of ecosystem conflicts with agile philosophy.

Leaders and executives who desire to nurture the agile teams in their organizations would be well-advised to help their agile teams address these "impedance mismatches" between agile and the ecosystem - and to stand up and defend the team's approach against the "that's the way we've always done it" mentality that oftentimes exists within the culture.

Simple UX plea

2010-11-09T19:53:00.000-08:00

Dear UX designers,

If I'm not authorized to perform a specific function in the application, please show me a grayed-out button or disabled select list, rather than not showing anything to me.

This way, I know that I'm not authorized, and I won't waste hours scanning the application looking in other corners of your app for the functionality you have simply hidden.

Thanks.

Verbal Combat

2010-04-26T23:46:00.000-07:00

And here is where the decision is made. Do I retreat to my established viewpoint? Do I dig in my heels? Or do I consider the alternative, offered by my combatant? And suffer the indignity of being judged wrong?

Truck Factor Mitigation

2010-04-16T06:55:00.001-07:00

One of the strong selling points of pair programming is that knowledge of the code base, techniques, and domain are shared across multiple people. We joke that this reduces the "truck factor" for a team. Truck factor is the risk to the team or project of any specific person getting "hit by a truck".

Some other phrases: "beer truck factor", for those who like to imagine being hit by a worthy cause, or "lottery factor", as one colleague suggested, since it is a happier ending.

High truck factors can be good for the individual. After all, if your specific knowledge or talent is critical to the firm, so too, is your ability to negotiate for higher compensation or to easily acquire extra latitude for resources and decision-making authority. Management does not want to scare away the geese that lay the golden eggs when they have no idea how the egg-laying works.

A high truck factor has a downside for the individual though. When you finally get tired of the same platform/domain/language and want to move on, the hand that feeds you is likely to restrain you from departing to other projects. Sometimes, the only departure path is to leave the company. That can be a good thing for getting out of a rut (and introducing potentially lucrative contract work with your prior employer), but can also force you to start from scratch in building a reputation in a new situation.

What of leadership/management? How do we reduce the truck factor for managers? They don't typically pair. What happens when opportunities arise for a promotion, or an exciting lateral move, but the leader is tied to his current position with no replacement in site? Perhaps he needs to turn the new position down. Perhaps the external market is tapped for a replacement. Perhaps he just adds the new position's responsibilities to his current responsibilities. These are smells of poor succession planning.

If you're a technical superstar, or simply a master of your technical niche, or
if you're a domain expert, or simply master of your domain niche, or
if you're a leadership expert, or simply the most ingrained leader in your current role:

Identify, train and groom your successor(s)

You never know when that lottery ticket will hit.

Talent acquisition and retention

2010-01-28T20:23:00.000-08:00

My friend, Brad Cross, posted an interesting blog entry recently on how compensation relates to attracting and retaining technical talent. This particular phrase resonated for me:

"Great workers long to work on interesting and challenging problems and collaborate with other great people who have a strong sense of vision and purpose in their work. They long for an open and supportive environment grounded in mutual respect that enables them to make their own decisions as appropriate."

His blog post goes on to relate the disconnect between the 10X productivity difference between the best and the worst software developers and the incongruence of the meager salary differential proffered by employers to recognize this difference (hint: it's not 10x).

Brad's post is thought-provoking, as usual.

No applause, just throw money

2010-01-26T18:16:00.000-08:00

I have an aversion to the applause that occurs in some iteration showcases (aka sprint reviews) on agile teams. The showcases are the meetings at the end of an iteration where the team shows working software to project stakeholders. Unfortunately, many teams end up displaying PowerPoint presentations instead or in addition, but that's a topic for another post.

I once witnessed a team that had 2-week iterations and held a 2 hour review at the end of each iteration. Each team member presented what he had worked on and accomplished over the course of the iteration. First of all, two hours was too long for this team for a 2-week iteration. They simply did not produce enough demonstrable working software to warrant a two-hour meeting. Worse, they often resorted to presenting partially completed stories - another problem, but again, fodder for a future post.

Having each team member speak and present his accomplishments might have been a good thing for that particular team. It can provide a similar social pressure that stand-up meetings provide - nobody wants to stand up and say they didn't accomplish anything, so each team member strives to deliver demonstrable value. The problem I had with this particular team was that the norms established that everyone applaud each person after his little piece of the presentation. Not only was the applause time-consuming, it was gratuitous. Folks in the meeting applauded simply because they were expected to, not because of any remarkable achievement.

In some cases, the team member didn't really accomplish anything of note on his own and the applause was simply out of place. It is as if my dog takes a dump in the middle of the carpet during a party and the crowd rushes up to pet and praise him, and offer him doggie treats. Clearly, this confuses the dog.

Though applauding every presenter is certainly overkill, I argue that applause at the end of an iteration showcase should be eliminated (or better, never started in the first place). In any case, it should never be de rigeur, and should never be instigated by an outsider who may have no clue as to whether the team really accomplished something special.

Applauding showcases for mediocre or even poor iterations can have a deleterious effect on motivation. Consider this possible thought going through a team member's head: "They applauded for this crap? They have no clue what we're doing".

We have a habit of rewarding performance. If my kids come home with straight-A report cards, I heap praise on them. If a see a C, I begin my own inspect and adapt cycle at home. But in report cards, the grades are clear, and are mostly objective. That is - the "A" reflects a large number of assignments, tests, and projects, and the teacher assessing the outcome has a substantial pool of similar production to compare against. Outcomes of iterations/sprints, on the other hand, are hardly objective, and are not comparable to other teams' output. It is truly only the team members who know, in their collective heart of hearts, whether they really deserve applause or not.

So my suggestion: omit the applause until the code gets into production and the customers' rave reviews start flowing. That's when the party should start.

Crew bags in the bulkhead overhead

2009-12-22T17:12:00.000-08:00

<pet peeve>

This has happened to me on several recent flights. I am seated in the bulkhead of the airplane - sometimes in first class. I open the overhead bins and airline crew bags are taking up that precious space.

As frequent travelers know, bulkhead travelers must put *all* baggage in the overhead, which increases their overhead space requirements. Flight attendants putting their luggage into that limited overhead space is inexcusable, particularly since there is no need for them to gather their luggage until everyone else is off the plane. When they use this space, bulkhead passengers must place their bags several rows back, making the deplaning process much more difficult (swimming upstream to retrieve bags).

</pet peeve>

Kudos to the Airtran flight attendants on my most recent trip, who spaced their bags out over several different rows beyond the bulkhead.

www

2009-12-21T15:23:00.000-08:00

Listening to the radio - folks talking about words. One problematic pronunciation is for folks pronouncing website names.

double-you, double-you, double-you ... 9 syllables, awkward

dub dub dub .... 3 syllables - better

Three-Dub ... OK - maybe this one isn't used - just throwin' it out for consideration.

Politics at work

2009-12-09T15:26:00.000-08:00

I just read The Five Dysfunctions of a Team on the plane this week.

I saw an interesting interpretation of the term "politics" which intrigues me:

"Politics is when people choose their words and actions based on how they want others to react rather than based on what they really think."

Threshold Anxiety

2009-11-27T10:15:00.000-08:00

"Kierkegaard, the nineteenth-century Danish philosopher, first described what has come to be known as 'threshold anxiety'. He describes the feelings of a young man who is about to leave home to go out into the world to seek his fortune. As he stands on the threshold of the house, about to leave, he feels that he's turning his back on everything that is warm, familiar, and secure -- what he has known all his life. Beyond the threshold lies the world, filled with all that is unknown and strange. If the young man turns back at this point, he is lost. If, however, he can take the fear of the unknown and turn it into the excitement of the unlimited possibilities which are open before him, he grows in the moment and is alive, as never before."

- Mildred Newmand and Dr. Bernard Berkowitz
How to Take Charge of Your Life

Squirrel Agile

2009-11-21T08:59:00.000-08:00

A client shared this term a few weeks ago that I really liked: Squirrel Agile. Thanks Steve.

I'm sure you've seen a squirrel trying to cross a street. The squirrel starts off on one side of the street, looks, darts out, then sees something scary and retreats. Sometimes he retreats all the way... sometimes he just stops in his tracks. When he starts again, he may continue trying to cross, or may high-tail it back to the original side of the street.

In agile adoption, we sometimes see fits and starts... and retreats - just like the squirrel.

One aspect of agile adoption - self directed teams - seem to me to suffer a great deal from this behavior. Management agrees to self-directed teams in principle, but as soon as the manager fears loss of control, or loses confidence in the team's ability to deliver, the agile squirrel darts back towards the original side of the street. The command-and-control tendencies return.

Other fits and starts occur when you start taking shortcuts in your approach. "We don't need to do a showcase this iteration; we don't have much to show". Or "We're 98% complete with this story - let's take credit for the story in our burn-up, since we'll finish it quickly at the beginning of the next sprint." I'm sure you can come up with other examples.

These behaviors mirror the squirrel's fear. These short-cuts and adaptations are typically not to improve effectiveness or efficiency, but reactions to fear of judgment. My suggestion: rather than darting back and forth as you cross the road, take a deliberate approach with courage.

agileshout

2009-11-21T08:24:00.001-08:00

I just recently discovered this StackOverflow implementation focused on Agile issues: http://agileshout.com. Seems to be low traffic at the moment, but perhaps my agile friends can find some value there.

I'm not quite sure why it's necessary to have a separate site from StackOverflow, since the tagging mechanism in StackOverflow permits differentiation of topics (e.g. "agile") and cross tagging of topics (e.g. "agile" and "BI") that might not otherwise find a specific home on a specific site.

Task breakdown - To do or not to do

2009-11-18T19:27:00.000-08:00

I've had this conversation with agile folks over the years. It's about task breakdown. This is not entirely fair, but I'll say it anyway: I consider it one of the "thou shalt" approaches of agile by the numbers... or by the tools.

Assume a master story list with estimates based on points.

The iteration planning meeting (IPM) looks like this:

Foreach Story in Candidate list:

Product owner: Describe the story
Team: break the story down into tasks
Team: estimate the effort for each task in hours
Iteration Manager: Increment the task hours counter by the amount of the task hours for this new story
Iteration Manager: Measure the task hours against the team's ideal capacity and report how full
Team: If iteration is full (based on ideal/actual capacity) leave foreach

As the iteration progresses, we see this:

Foreach Day in iteration:

Team member: update the remaining task hours for each of his/her tasks
Iteration manager: udpate/publish burn-down
Iteration manager: interrogate team members whose tasks are moving "slowly"

There are some benefits to breaking work down into tasks:

Intra-story progress can be measured by the iteration manager who can address slowness ("John: you reported 2 hours left yesterday morning and today you're still not done... what's up?"
The aggregate burn-down should show you how close you are to your target on a daily basis

My issues with this approach:

Tasks become the center of the reporting universe within the sprint and so progress against task completion may mask poor progress against story completion (e.g. due to undiscovered tasks)
Team "feels" progress based on completed tasks, rather than on the real objective: completed stories
Weird reward structures get created ("John - yesterday you said you had 12 hours remaining on the task, yet you finished it. Great job!")
Weird negative feedback is inferred ("John - yesterday you said you had 2 hours left and you're not done yet": inference - you're not working hard enough)
Daily reporting requirements implies distrust of the team to raise issues or problem: "If I don't keep an eye on the task level reporting, I can't hold them responsible on a daily basis"
Estimating iteration capacity based on ideal task hours may conflict with iteration capacity planning based on historical velocity. What happens if my hour capacity is reached in the IPM, yet my booked story point total is below my historical velocity? (I'll save the tendency for re-estimation for another blog entry). Reminds me of the old adage - experienced sailors never go to sea with two compasses. They go with one or with three, because if the two disagree, you have no idea which one is right.

I feel that task breakdown should be done only in limited circumstances and only to the degree where the benefit outweighs the admin cost:

if the team feels that the benefit outweighs the cost
if a developer or pair needs to break the story down into tasks in order to understand the work to be done, go for it (but don't worry about tracking all the details in a tool)
Perhaps if your team is not mature enough to understand how to break down a story into tasks, and so you must spoon feed them with tasks (even then, I think it better to have them pair with experienced developers to learn how to become self-sufficient.)
If the tasks to implement a story can be parallelized (different developers or pairs can be working on different tasks for the same story in parallel)
If your team has "silo dysfunction" that requires choosing stories that don't overload a skill or domain area on the team

Example: let's say you have a project with equal parts C++, Java, and Fortran code and you have C++, Java, and Fortran programmers who can't span technologies. In order to keep from overloading one technology group, you must choose stories that balance the work across those silos. Sometimes, the only way to create this balance is to task out the work across technologies, to ensure you're not overloading one camp.
By the way - removal of this dysfunction over time is recommended.

My feeling: Using the whole team's time in the IPM doing task breakdown and estimating tasks is usually wasteful. I recommend that task breakdown be undertaken, if necessary, at the last responsible moment... when the story moves from "ready" to "in development", rather than at the IPM. The developer or pair picking up the story should do the breakdown.

Task breakdown smells (and yes, I've seen them all):

The tasks look like this:

Design the code
Write the code
Write the unit tests
QA the code

Why is this an issue? You're probably doing mini-waterfalls, not simple, evolutionary design

The "remaining work" for a given task is reduced by 8 hours (or perhaps 6) each day

Why is this an issue? Team members are not providing real data, they're telling the iteration manager what he/she wants to hear

The hour-based iteration burn-down (or, as I prefer, burn-up) is practically a straight line.

Why is this an issue? In reality, many things take more or less time than imagined. Straight lines are an indicator of "cooking the books"

The iteration manager asks people throughout the day... "How many hours do you have left on this task? When will you be done?"

Why is this an issue? It's command and control leadership and dilutes the power of the self-directed team.

Iteration Planning Meetings (IPM's) take more than an hour and are more about numbers than about story understanding

Why is this an issue? You spend more time taking swags at hour estimates than you do actually thinking about the functionality to deliver

The iteration manager applauds the team for accomplishing "400 hours" when their calculated capacity was only "350".

Why is this an issue? It's focused on task hour accounting and doesn't imply anything about how successful the team was at completing stories

I've worked on projects with both approaches - task breakdown with hour-based burn charts and no-breakdown with point-based burn charts. My suggestion is to avoid speculation about the superiority of doing it the only way you've ever done it and at least give each approach a fair shot.

I remember my elevated caffeine intake as a developer at interminable IPM's where I just wanted to get on with the work.

I remember debating minutia about whether a task belongs or not, and whether it's 8 hours (by Kurman) or 16 hours (by someone else). Yes - all those issues that the point-level estimating deigns to abstract by using relative estimates can rear their ugly heads in hour-based estimating. (By the way - if your solution is to assign the tasks at IPM time, you'll suffer from other problems).

I remember being the first to pick up a story as a developer and finding a better approach that implied a totally different task breakdown. Yes, I used the new approach, and yes I had to fix the accounting (XPlanner) to reflect my new approach. (Umm... on second thought - I just left the existing task list in place and fudged the actual hours into the old list. You might think this was wrong. I knew, however, in my heart of hearts, that the micro-accounting really didn't matter).

I've also worked with teams that have eliminated task breakdown/estimates and felt freed by the defenestration of the bureaucracy.

This tends to become a heated topic of conversation. In the end, the best answer, I think, is to let the team choose the approach that's right for them. Mandating task breakdown or mandating against it is almost always wrong. Drive the questioning to determine if task breakdown adds value or not, and try it both ways. If you have an agile management tool that requires tasks in order to do reporting, and you want to avoid defining tasks, just create one task per story that says "Do it". (In parallel, find a different tool that provides more flexibility).

scrum terminology decoder:
iteration = sprint
iteration planning meeting or IPM = sprint planning meeting
iteration manager = scrum master
iteration showcase = sprint review = sprint demo
master story list = product backlog (or possibly release backlog)

PMO vs. PPM

2009-10-31T11:16:00.001-07:00

I have a visceral negative reaction to the PMO initialism; it stands for Project Management Office. I recently pounced (in an overreacting sort of way) on a colleague who was using this term. Sorry Carl.

I need to explain a bit. It's really all about the "O" - for Office.

"Project Management Office" screams bureaucracy to me. I've never seen an efficient and effective PMO. This is perhaps because most of them seem to be mired in "SDLC" - an oft-used euphemism for "waterfall" (despite it's innocuous spelled out translation: software development life cycle).

I once had to sign off on a 19-page document provided by the PMO to justify the acquisition of two load balancers for a test environment. This document had to be signed by 25 people in a 2000-person company. It was a stunning example of the need to feed the process beast. Some project manager in the PMO - who probably thought this process was necessary - filled out this template. My favorite section of the doc was "Metrics". Ostensibly this section existed to establish the metrics upon which the success of this project would be measured. The PM filling it out, indicated that 2 load balancers would be acquired - as if the number "2" satisfied whatever the template providers had in mind for metrics.

If we want to revamp the bureaucratic, inefficient, ineffective approach currently used for managing software project portfolios (the PMO), I think we need a departure from the term.

I'd love for us to agree to focus on the verb - not the noun. A brief digression:

I see many agile teams who use the iteration planning meeting - IPM - or the "sprint planning meeting" if you subscribe to that religion - as the only time in which the development team is exposed to upcoming work (other than, perhaps, estimation efforts that occurred months ago). I coach teams to treat iteration planning as a "verb": planning - rather than a noun: meeting. The "planning" should occur fluidly - some done in meetings before the IPM (e.g. estimation), some after (e.g. task breakdown).

Project portfolio management (the PPM in the title of this post) implies active engagement in assessing the health of the portfolio. The estimated release date or feature list should be adjusted after every iteration, and approaches need to be introduced to raise awareness of the new projections at least this often.

Let's please talk of project portfolio management, rather than project management offices.

97 Things Every Project Manager Should Know

2009-08-20T22:11:00.000-07:00

The book "97 Things Every Project Manager Should Know" has just been published. I have two contributions: "Use a wiki" and "It's the People Stupid". Get 30% off by entering the code ABF09 on the oreilly.com site.

Linked-In grammar issues

2009-06-14T15:23:00.000-07:00

John Doe "has added new links and updated their profile"

John Doe is an individual. "Their" is plural. I understand they're trying to avoid "his or her", but I'd prefer it.

Another example... when someone requests an endorsement, the message comes across as "Can you endorse me?".

The word "can" implies ability to do something, not willingness. I'd much prefer to see "Would you endorse me".

There. It's off my chest now.

Why Blog?

2009-06-05T18:58:00.000-07:00

I recently had an extended conversation with a group of about 10 folks who lamented the poor understanding of the value their particular functional role brings to a software development team.

One question I posed: how many of you blog on the topic of your profession? The answer was zero.

Why don't they blog? Here is my interpretation of the reasons for not blogging:

Not enough time - working 40 to 50 hours per week leaves little extra time to spend composing and presenting ideas in a professional manner, much less having a reasonable social life.
Lack of original ideas - there's not much I can think of to write about that hasn't already been addressed somewhere - whether in another blog, in a book, or in conference presentations.
Confidentiality - many of the examples from my work are proprietary; obfuscating the details takes time and can cause loss of message fidelity.
Low readership - the effort to reach a small number of readers, given the size of the blogosphere, has a low RROI (readership return on investment?)

My blogging is sporadic. I understand the effort required to wrap ideas in a digestable format. I also edit articles for an online IT journal (alphaITJournal.com). Editing is hard work. Blogging doesn't require the depth of perfection that articles do.

Sometimes you're better off taking a stab at it and clarifying the concept through further blog entries than simply waiting to start.

Who reads my blog? According to Google Analytics - about 15 - 30 people. That's the volume of hits I generally get with a new post. It's not much, but size isn't everything. Every once in a while a link to your post will get posted to an aggregate someplace (digg, reddit, Developer Zone, etc.) and will generate more traffic and conversation.

The benefits to blogging:

Personal brand promotion. As your blog is read by others, your personal brand improves.
Clarifying thoughts. Organizing and writing about a topic forces you to develop clarity on your topic.
An idea portfolio. When you apply for new jobs or try to sell to new clients, your blog serves as a portfolio of your ideas and promotes your depth of thinking on your profession. It also serves to show off your communication skills.
Writing skills. Most of us need to communicate through the written word in our lives. Blogging is great practice.

Here's a technique I use to generate blog entries. Whenever I get an insight or a flash, I start a blog entry in a text file. Sometimes it's just a thought (one file - pragmatism.txt - has the following: "Pragmatism vs. agile").

When I have down time (waiting in the airport, sitting on a plane), I take a look at my partials and figure out what I'm in the mood to explore. I happen to be on a plane as I type this.

Your topics will rarely be entirely original. What will be original, however, is how you shape your message with your unique perspective and background. Combining this uniqueness with the topic at hand is what renders insight.

Low readership is not an issue. The benefits of clarifying your thoughts, having an idea portfolio, and improving writing skills are all independent of the size of readership.

So go ahead and start. Create a blog and type "Hello World". You may be surprised at how the ideas start flowing. Start recording things you want to explore ... and start blogging !

Uncle Sam Industrial Average

2009-06-02T05:22:00.001-07:00

With GM and Citigroup being removed from the Dow Jones Industrial Average stock index, it occurs to me that we need a new index to track the health of government owned/quasi-owned companies. We should be able to come up with 30 by now, no?

I propose the Uncle Sam Industrial Average (USIA).

Jump in

2009-05-29T11:14:00.000-07:00

“It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood, who strives valiantly; who errs and comes short again and again; because there is not effort without error and shortcomings; but who does actually strive to do the deed; who knows the great enthusiasm, the great devotion, who spends himself in a worthy cause, who at the best knows in the end the triumph of high achievement and who at the worst, if he fails, at least he fails while daring greatly. So that his place shall never be with those cold and timid souls who know neither victory nor defeat.”

- Teddy Roosevelt

XP Game redux

2009-04-18T08:15:00.000-07:00

I assisted in another XP game with legos last Tuesday - led by my ThoughtWorks colleague Conrad Benham. Several other ThoughtWorks folks helped to facilitate. We did this at the Atlanta Agile User Group meeting. Kris Kemper captured some of the activity in his blog post. Another participant captured his perspective here. I particularly like his comment "I was stunned at how many real world challenges our team of 5 mirrored". I'm always pleasantly surprised at how effective these games are at conveying agile concepts

I facilitated one of these last year at a Florida .NET user group meeting which was captured in the Apress website in their content area that brings attention to various user groups.

If you have a desire to introduce agile concepts to an audience in a fun setting, you can't go wrong with an XP Game with Legos.

Euphemism in Podictionary

2009-04-15T13:19:00.000-07:00

I previously posted a blog entry on Dysphemism and cross-register synonyms. I sent an email to the guy who runs Podictionary - the podcast for word lovers, suggesting he use dysphemism in one of his podcasts.

Well, he did. Kind of. He used euphemism and mentioned dsyphemism. Check out the post here.

ThoughtWorks is seeking developers

2009-03-28T23:16:00.000-07:00

From Dice:

Title: Experienced Java, .NET, Ruby Developers with Agile exp. - Chicago
Skills: Strong technical skills and Agile best practices
Date: 3-11-2009

Description:
Isn't it about time you joined a company that really values your contribution? A company that is synonymous with innovation in the technical world? A company that is passionate about collaboration? Add to this our focus on Agile delivery and you'll start to see why working here is refreshingly different.

Welcome to ThoughtWorks!

We're looking for experienced Java, .NET and Ruby Developers

If you would like to:
* Use the latest tools and techniques (currently Ruby, Java, .NET, Agile Methodologies, Web Services...)
* Drive the design and construction of a client's complex business problems into innovative technology solutions
* Be a hands-on coder and proactively mentor developers and client (including pair programming)
* Travel to work at client sites Monday through Friday

And you have...
* At least 6 years of experience combining design, development and implementation of large-scale systems and large web applications
* Strong development experience with OO languages such as Java and .NET
* Strong knowledge of design patterns, refactoring and unit testing
* Working experience in Agile development best practices
* Excellent written and oral communication skills

80% domestic travel is required.

Our US offices are located in Atlanta, Chicago, New York, and San Francisco. Relocation is necessary if you do not live in one of these cities.

ThoughtWorks values aptitude, attitude and integrity.

We invite full participation from all of our people through a non-hierarchical organizational structure and open, honest and transparent work environment.

If you thrive on challenge, unlimited possibilities and unparalleled learning send your resume to work@thoughtworks.com or apply online now.

Thoughtworks, Inc.
200 East Randolph St
25th Floor
Chicago, IL 60601
Phone: (312) 373-1000
Fax: (312) 373-1001
Web: http://www.thoughtworks.com

Iron Chef Retrospectives

2009-02-17T07:58:00.000-08:00

I like cooking analogies to software. Lachlan Heasman recently posted a comparison between Iron Chef and scrum iterations. One missing component was the retrospective. It occurred to me that the chefs must do some sort of retrospective and that it would be interesting to see on TV. So I penned the following to Food Network this morning:

I'm a software engineer and a die-hard Food Network fan. I often use cooking analogies when coaching other software professionals on how to improve their approach to software development. Mise en place is one of my favorites.

I recently encountered a comparison of the Iron Chef competition to software development. One of the components of our approach in software is to use "retrospectives" to look back upon the iteration of software development we have completed to improve how we do things. We revisit what went well, what didn't go well and adapt our approach to learn from our mistakes

It occurred to me that the Iron Chef competitors must do "retrospectives" as well. I can imagine Cat Cora sitting around a table with her chefs over shots of Ouzo dissecting the completed competition and finding reasons to celebrate and opportunities for improvement.

I think it would be fantastic to have a postscript TV show to film the two teams in their analysis of the competition. You could intersperse clips from the actual competition when chefs refer to certain activities. It would also be interesting to hear what the chefs *really* think about the comments from the judges and how they might change what they did based on those comments.

XP Game

2009-02-10T08:35:00.000-08:00

In June of last year, I facilitated an XP Game (using Legos) for the South Florida .NET user group. We had ~30 participants. Dave Noderer captured some of the excitement on video

Iteration Length

2009-02-06T10:59:00.000-08:00

What's the right iteration length?

In Scrum, the recommendation is to start with thirty calendar days. From the Schwaber/Beetle book: section 3.6.3 Sprint Mechanics:

"Sprints last for 30 calendar days" and "thirty days is an excellent compromise between competing pressures". Though "Adustments can be made to the duration after everyone has more experience with Scrum".

My first reaction to the number 30 is that this is a nonstarter. What happens when your sprint boundary occurs on a weekend? How do you schedule sprint transition meetings? I know of no calendaring program that schedules meetings "every 30 days". Monthly? Yes. Every n weeks? Yes. But not every 30 days. The organizations I know that have implemented scrum by the book have scheduled n-week sprints, in order to maintain a consistency of scheduling (e.g. Wednesday afternoons are for sprint reviews).

Many novice scrum practioners resort to quoting "the book" when arguing for 30-day, by which they mean quad-weekly (which I will hereafter refer to as monthly for terseness) sprints. Suggestions to shorten sprints (e.g. to 2-weeks) yield objections along the lines of "with twice the meetings, we'll have less time to get work done. We already spend two days in our sprint transition meetings"

First of all, if the team is spending two days on monthly sprint transition activities, something is very seriously wrong. Really.

Sprint reviews (or showcases in the more generally accepted agile lingo) are about showing working software. They should not be about burn-ups and burn-downs and justifying the team's existence. You should never find yourself in a showcase/sprint review talking about the percentage completion of a story. Show the working stuff or sit down.

If you follow this pattern, the showcase/sprint review length should be proportional to the length of the iteration. If your iteration length is cut in half, your showcase should take half the time. After all, you're only showcasing half the functionality! (OK... maybe it's not exactly half. I would argue that two week sprints are more productive than monthly.)

Iteration planning should be a no-brainer. Preparation for the sprint planning meeting is on the business analysts, product owner, scrum master, project manager... everything should be pretty well layed out in advance. It should take no longer than an hour to do an IPM (iteration planning meeting). Unless, of course, you feel that task breakdown is necessary during the IPM (another Scrum approach with which I generally disagree). In any case, the IPM length should be proportional to the length of the iteration.

-begin sarcasm- How 'bout a 3-week iteration? Wouldn't that be a reasonable compromise? -end sarcasm-

Sprintly Retrospectives are another issue. Can you halve the time spent in retrospectives if you halve the iteration length? Probably not. But this, I feel, is not the right question. Are you getting value out of your retrospectives? If not, figure out how to get value. You don't necessarily need all the typical pomp and circumstance of a full-blown retrospective to impart the "adapt" portion of the "Inspect and Adapt" mantra. Too many teams, in my experience, adhere to the scheduling and process of retrospectives without digging deeply into different ways of adapting the team's approach to being effective and efficient.

More advanced teams can consider whether iteration ceremony is even necessary. A more lean approach would be to consider the flow of the work and to simply feed work into the development "machine" at a rate at which it consumes the work. "Inspect and adapt" would be continuous; retrospectives would focus on specific issues or areas of concern (rather than specific time periods across which many different kinds of issues may require attention). Classic iteration planning would yield to on-demand prioritization and estimation exercises - delayed to the last responsible moment. Reviews of completed functionality would be scheduled on demand for individual stories and perhaps with more ceremony when a critical mass of functionality has been completed.

What's the right iteration length for you? My recommendation is 12 days, 6 hours, and 24 minutes. (Oops... forgot the sarcasm tag)

Developing Extreme Talent

2009-01-26T19:47:00.000-08:00

Thanks to Jason Yip's blog entry: On chess grandmasters and the expert mind for pointing me to this fascinating article - The Expert Mind: Studies of the mental processes of chess grandmasters have revealed clues to how people become experts in other fields as well - from Scientific American.

From the Scientific American article:

"K. Anders Ericsson of Florida State University argues that what matters [toward improving one's chess playing skill] is not experience per se but "effortful study," which entails continually tackling challenges that lie just beyond one's competence. That is why it is possible for enthusiasts to spend tens of thousands of hours playing chess or golf or a musical instrument without ever advancing beyond the amateur level and why a properly trained student can overtake them in a relatively short time. It is interesting to note that time spent playing chess, even in tournaments, appears to contribute less than such study to a player's progress; the main training value of such games is to point up weaknesses for future study."

The concept of effortful study essentially suggests that you grow only when you push yourself. As a very-practiced and accomplished pool player (before I had a family and other commitments), I know that I only improved when I played better players. Seeing this article expanded my thinking on the topic into other areas... such as programming talent and general education (I have four young children).

"The preponderance of psychological evidence indicates that experts are made, not born. What is more, the demonstrated ability to turn a child quickly into an expert--in chess, music and a host of other subjects--sets a clear challenge before the schools."

This points to difficulties in making our educational system effective: teachers who are responsible for 15 or 20 students cannot possibly tailor the education to push the envelope for each child. Even with five children, a common lesson plan loses the ability to maintain that tension between comfort and discomfort that leads to the kind of discovery that keeps up with a student's need to push forward. This is precisely why parental involvement is necessary ... to maintain that tension and to challenge our children - not just in maintaining the necessarily dictated classroom pace, but in tapping into the wellspring of talent and desire living within our children. I see it so clearly now.

"Laszlo Polgar, an educator in Hungary, homeschooled his three daughters in chess, assigning as much as six hours of work a day, producing one international master and two grandmasters--the strongest chess-playing siblings in history. The youngest Polgar, 30-year-old Judit, is now ranked 14th in the world."

Perhaps Laszlo's ability to adapt the level of effort required for each child helped. I'm interested in learning more about how much of his lesson plans were chess oriented and how much were geared towards general education. There's also the genetics argument; if he was good at chess, perhaps he passed on the chess genes.

"[...] success builds on success, because each accomplishment can strengthen a child's motivation. A 1999 study of professional soccer players from several countries showed that they were much more likely than the general population to have been born at a time of year that would have dictated their enrollment in youth soccer leagues at ages older than the average. In their early years, these children would have enjoyed a substantial advantage in size and strength when playing soccer with their teammates. Because the larger, more agile children would get more opportunities to handle the ball, they would score more often, and their success at the game would motivate them to become even better."

This argument for driving towards early success is somewhat orthogonal to the "effortful study" thesis, but bears import to the parenting issue (and perhaps the programmer development issue as well). Positive reinforcement and successful results early-on can provide the confidence that children and programmers need to continue pushing forward.

If you are a parent, or a mentor of a young programmer (or any other professional I would think), these concepts bear consideration.

Non functional requirements - a tale of two cities

2009-01-22T21:21:00.001-08:00

I've been thinking about non-functional requirements lately. Ilities, some might say. It occurred to me that there are two classes of non-functional requirements: those that are visible to the user and those that are hidden.

Performance and usability are examples of non-functional attributes of the application that are visible to the user. I classify these as being "in front of the curtain"... or "part of the performance" (to use theatrical terms). Though attention to these issues is sometimes delayed to the end of the release, they occupy a high level of importance in delivery priorities.

Other non-functional requirements are backstage, and pretty much lead to efficiencies (or inefficiencies) for the development team. Examples include testability, supportability, maintainability and extensibility. These non-visible requirements bleed into visibility in some sense... for example, extensibility problems lead to delays in releases which impact follow-on release timelineness; poor testability leads to gaps in test coverage, which leads to bugs. But the impact of these issues often occurs long after the "current administration" has moved on.

I suggest that the order of priorities can be interpreted as 1) functionality, 2) speed of delivery, 3) visible non-functional requirements, and 97) non-visible non-functional requirements. Speed of delivery takes precedence.

Beware the "speed smell": sacrifices at the alter of speed, to the detriment of long term health of the system. In particular, beware these sacrifices being made by an administration that is poised to move on.

Good programmers: nature or nurture?

2009-01-21T22:58:00.001-08:00

From where do good programmers sprout? Do they come from top-notch collegiate computer science programs? Do they stem from a gene correlated with good problem-solving abilities and ability to think in higher level abstractions? Where does the balance lie between nature and nurture?

There's a difference here between good programmers and simply competent programmers. Competent programmers are good at coloring between the lines. Good programmers are good at defining where those lines belong, understanding when the lines need to move and when coloring outside the lines is appropriate. They could be good architects, but choose not to lose their relevancy by moving from code to box diagrams.

I don't know where good programmers come from. I have some observations though.

A college degree is not necessary. I'm not saying it's not useful, just that it's not necessary.

Curiosity is necessary. A BS in Computer Science with on the job training in programming and domain, but with no curiosity, will last a graduate 2-3 years, after which s/he will professionally stagnate. This mode is fine in a stable economy where these programmers can amass domain or technology knowledge with their current employer and become domain-sticky (e.g. the few who know why the business rules are structured as they are) or technology-sticky (the few who have been with the code base so long as to know the nooks and crannies of obtuse design and coding decisions). Lack of curiousity and experimentation - in learning new domains and skills - significantly reduces the shelf life of non-curious developers. In the current economy, this domain and technology stickiness are no longer sufficient safety nets to protect your jobs.

You don't have the time to address your curiosity? Make time. Many licensed professionals (e.g. medical professionals) require continuing education in order to keep their licenses. Software development professionals should have even higher requirements; our profession changes very quickly. Even if your employer doesn't have the budget to send you off to a conference, you should be able to negotiate some set-aside time to focus on sharpening the saw. Or spring for that conference attendance cost yourself if your company is unwilling to invest in you (and update your resume while on the plane). You should also be able to answer the question in an interview - "how do you keep your skills current?".

In the coming technology landscape: meta-programming, crossing-the-chasm from statically typed object-oriented languages to dynamic and functional languages, and solving more and more complex business problems requires more than just a basic understanding of Java and the list of standard Java-based acronyms. Beyond curiosity, the new landscape requires discipline (to understand before coding - and to keep from strangling yourself with the new rope that these new technologies provide). It requires persistence in teasing out the subtleties of the new technologies to fully understand them. It requires an ability to think in more abstract terms... in some ways, it requires returning to the Computer Science textbooks.

In sum - to improve your programming skills, cultivate and follow your curiousity, think more deeply about how to solve the problems at hand, try some of the newer (sic) languages (F#, Haskell, Lisp, Ruby, etc.) and practice thinking in more abstract terms. Be persistent. And find a smart, curious, thoughtful, persistent programmer who takes keeping his/her skills sharp seriously. Pair with him/her. Ask questions. Become a sponge.

John Doe, MBA, PMP, EIEIO

2009-01-21T01:10:00.000-08:00

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

2009-01-16T20:37:00.001-08:00

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

2009-01-06T21:54:00.000-08:00

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

2009-01-01T00:22:00.000-08:00

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

2008-12-22T21:48:00.001-08:00

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

2008-12-21T20:41:00.000-08:00

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

2008-12-13T16:06:00.000-08:00

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

2008-12-12T20:22:00.000-08:00

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

2008-12-08T19:38:00.001-08:00

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?

2008-10-28T18:26:00.001-07:00

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

2008-10-04T13:34:00.000-07:00

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

2008-09-11T07:08:00.000-07:00

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

2008-09-04T22:16:00.001-07:00

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.

2008-06-19T08:02:00.000-07:00

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

2008-06-17T21:01:00.001-07:00

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

2008-05-28T21:11:00.000-07:00

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

2008-05-15T17:01:00.000-07:00

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

2008-05-11T14:04:00.000-07:00

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

2008-05-11T12:53:00.000-07:00

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

2008-05-06T19:29:00.000-07:00

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.

Receiving Feedback

2008-04-20T13:12:00.000-07:00

My last post on feedback was on giving constructive feedback. Here, I'll focus on receiving feedback.

In the question of feedback - what, where, when, why, and how - the receiver of the feedback may not have control over many of the elements. To some extent, your ability to receive feedback effectively is determined by how effectively the provider shares it. But you do have some control.

If you have a regularly scheduled one-on-one with someone, or performance review meetings, you should always be prepared for feedback. Prepare yourself for these meetings with an attitude adjustment that suggests "I am open and willing to receive feedback constructively so that I can improve". If you enter meetings with this mental preparation, you are way ahead of the game.

Another attitude adjustment that helps you to receive feedback openly is to consider the alternative. That is - what if the person providing this feedback just stayed quiet? I assert that you always gain information and knowledge (even if it's simply an impression of the regard that the giver of feedback holds for you). Treat it as an information gathering exercise. You will learn

What that person thinks about your behavior - or even you

By extension, if that person holds that view, then others may as well

Hopefully - examples of the behavior that the reviewer deems in need of improvement

Suggestions of how you can improve

First, let's cover the "when" and "where" of feedback. I've already mentioned naturally occurring events where feedback will be shared. But it sometimes occurs (and should more often occur) in an ad hoc manner. If you sense that you are not in a good mental or physical place to deal with feedback at that time, it is well within your control to request a postponement of the discussion. Try something like this: "Adrian, I am very interested in hearing your feedback, but would it be OK if we schedule some time to discuss this privately - perhaps tomorrow morning? I feel like I will be in a better place to listen and take your feedback constructively at that time".

"What" feedback provided is primarily - but not exclusively - determined by the person providing feedback. If I tell Jeff that the coffee he has been providing me is too hot, that is the primary message. But if Jeff probes on what the temperature should be, what I feel the temperature has been and such, he can steer the feedback towards the constructive content he needs in order to improve. In this way, he can control the "what". In addition, he can use it as an opportunity to probe for related (or unrelated) feedback.

"How" the feedback is provided can be steered by the recipient as well. I mentioned in the "giving feedback" post that one should focus on the behavior and not the person and should provide specific examples of where the behavior needed improvement. If the feedback giver is speaking in generalities, you can steer him by asking for specific examples. If he can't provide specific examples, ask him to keep an eye out for instances in the future. Something like: "I appreciate your feedback that I'm often late for standups without providing advance notice. I can't recall an instance when I failed to notify you in advance - though I do remember the one time that I overslept, which I understand is not a great excuse. I will make every effort to be on time and to notify you if extenuating circumstances arise. If you find examples when I fail to do so, could you please notify me right away, so I can determine the root cause at that time". OK, I'm going on and on for a silly example; you get the idea.

Take notes. Sometimes - particularly if feedback is negative - our emotions cloud our ability to retain the information being provided. It is helpful to take notes to revisit once the dust settles.

Always receive feedback in a positive manner. Always thank the person for taking the time to give you the feedback - even if you disagree. We need to reward people with thanks for taking the time, effort, and risk of conflict to provide feedback. "Thank you, Adrian, for the feedback on the temperature of the coffee. Though I think I've been rigorous about controlling the temperature, perhaps if I find a thermometer for you to measure, you can let me know the temperature you find when the heat is unbearable. In this way, I can improve my coffee provisioning". (I'm getting tired of this example... from now on, no more coffee... this analogy has run its course).

Don't be defensive! Again, treat the feedback as a gift, not as an attack. You're not perfect. We all strive towards perfection, and the more input and feedback we receive from others, the more adjustments we can make on the path.

Don't fight back with criticism. "Yeah? Well, I think your burnup charts should be done in crayon, Adrian, because they're like the work of a 3-year-old."

Consider returning to the person who gave you the feedback after you've had time to digest and perhaps implement some change. "Thank you again for the feedback you gave me last week. I've been thinking about it, and have adjusted a couple of things. Can I share with you the changes I've made?" This shows a healthy dose of maturity, willingness to improve, and respect for the person who took the time to give you feedback.

I'm open to receiving [meta?] feedback on this post.

Giving feedback

2008-04-20T13:04:00.000-07:00

Giving and receiving feedback is difficult.

Umm... well. That's not exactly correct. Giving feedback is easy. Giving constructive feedback is difficult.

For now, let’s focus on giving feedback

In my team blog, I used the example of one of my team members getting me coffee. It was meant in jest, but I won't use his name here... Let’s use that as an example in giving/receiving feedback.

Adrian: Hey Jerry… I want to talk to you about something. The coffee thing isn’t working for me. You’re not satisfying my requirements. The coffee is frequently too hot, and you’re always late with it. I’m really annoyed with you.
Jerry: I don’t know what you’re talking about. I always get that seam thing right… well, most of the time. And I can’t control the heat of coffee. And I’m not late with it. You must be delirious. I’m doing the best I can. I’m better at getting coffee than David was.
Adrian: Come on, I know you can do better. Please, let’s get that coffee thing fixed.

What’s wrong with this dialog - everything?

No. There is something good here…. There is a bit of specificity in the feedback. There are three things brought up here… the heat of the coffee, delivery timing, and the seam facing the right way.

There are many things wrong with the dialog. Adrian is making several common mistakes.

Adrian should give positive as well as negative feedback. We tend to speak up when something is wrong and focus on what’s wrong. We should find opportunities to give positive feedback in relation to the negative feedback. So something like

Adrian: Hey Jerry… Thanks for getting me coffee. The other day when I got in, I was so rushed and needed to get off to a meeting; it was nice to have my coffee right here ready to go. It made a huge difference in my day that day. One thing I’ve been meaning to mention – it seems to be too hot sometimes. Last Thursday, it burned the roof of my mouth. Was there something specific you did that day that caused it to be hotter than usual? Is there some way that we can get the temperature down a bit?
Jerry: Gee, I don’t know. It may be that you got it that day right when I returned from the coffee shop. I can’t control the temperature of the coffee they serve, but perhaps I could get some ice cubes and have them available for you. Would that work? Or perhaps if you called when you are 10 minutes away from work, I can get the coffee then, so the coffee has some time to cool.
Adrian: Those are great suggestions. I hadn’t thought of ice cubes. Don’t worry about getting them for me; I’ll just get one and pop it in if it’s too hot.

Notice the difference in the tone of the conversation. Adrian and Jerry are collaborating in finding a way to get the heat of the coffee right. Also – Adrian is being much more specific.

It is critical in giving feedback to find instances where the results were not acceptable. “Last Thursday” provides a very specific example that Jerry can think back to. Last Thursday is also relatively timely. We’re not talking about last month.

The coffee being “always late” is clearly not accurate. Again, by providing specific examples and focusing on the behavior or results rather than the person, you are more apt to get the results you seek.

Here are some attributes of effective feedback:

• Specific – rather than general. With specific examples.
• Sharing impact. Why is the behavior a problem? What was the impact of the poor performance to the team, to the company, etc.?
• Timely – both in relation to the incident/behavior, and in terms of the recipient’s receptiveness (e.g. not when the person is on their way out the door or troubleshooting a high priority production issue).
• Focused on the behavior, not the person

There are more, but this is a start.

Next time, I'll address receiving feedback.

Polyglot Programmers

2008-04-20T13:03:00.000-07:00

Neal Ford from Thoughtworks has a good blog post on polyglot programmers. His argument is that single-language programmers are becoming a remnant of the past. To thrive in the IT environment of today, we should be open to using the right language for the job.

Attitude, Aptitude and Integrity

2008-04-08T17:42:00.000-07:00

This is the tag line for Thoughtworks: Attitude, Aptitude and Integrity. It's printed on the back of all business cards.

As I was saying goodbye to a colleague who is moving on to another position, I told her that I felt that she exhibited these traits. I think that's a high compliment. Good luck Grace.

What's in a blog? Facts? Or Insights?

2008-04-06T13:25:00.000-07:00

I recently viewed the blog of a colleague who was detailing a vacation he took. Much of the content was around the facts of the journey - the cab picked me up, the plane was late, etc.

I get more out of blogs that reveal insight rather than sequences of events. We bloggers should seek to convey insights rather than facts... and relegate the details to a journal or something private (still not sure what value such a collection of facts would provide).

I promise to seek to avoid regurgitating facts in favor of sharing insight here.

Stanford Entrepreneurial Thought Leaders

2008-03-15T10:05:00.000-07:00

Marcelo Olivas turned me on to these podcasts from Stanford (also available via iTunes). These are regular talks & interactive discussions with entrepreneurs and industry leaders who visit Stanford University. I learn something new from every episode. The lessons are applicable across industries and company maturity.

They also have videos available from their main page.

Highly recommended.

Sausage Making

2008-03-07T05:48:00.000-08:00

Otto von Bismarck – the “Iron Chancellor of Germany” in the 1800’s is said to have made this observation:

"Laws are like sausages, it is better not to see them being made."

The comment suggests that the making of sausage is a messy business. It’s better if you just avoid thinking about what goes into making the sausage and simply enjoy the results. Similarly, the making of laws is a messy business that can be unappetizing.

I use this reference quite a bit on projects. The extension to this in the software development world is:

"Software Releases are like sausages; it is better not to see them being made."

Software development sausage making includes our development approach (e.g. points, burnups, self-directedness) and in some cases, our technology choices. I have, at times, made the mistake of opening up the “sausage making” process for stakeholders to assess, critique, and well…watch. Sometimes this is appropriate. For example when getting into detailed conversations about cost/benefit analysis on technology purchases, or to determine whether those choices are in line with the corporate IT strategy, it makes sense to discuss them. Too often, though, I think we make the mistake of getting caught up in discussing the sausage making with stakeholders in many cases where, frankly (sausagely?), they might be better off not knowing how the sausage is made.

This is a classic mistake that technologists make. We get so enamored of our technology and our process, that we think everyone else must be interested in how we do our work.

We should focus stakeholder reviews more on the array of sausages we produce, rather than how they are made. Don't show iteration burnups, or discuss the nature of a "point" in the estimation process. Apply an adapter/interface on the information to convey only that which is appropriate to the audience. Consider this a sausage casing, if you will, that abstracts the detailed content regarding the inside of the sausage. So, rather than discuss with them that

"This sausage is almost done – it needs some fennel, and a little more pork fat, and a touch of lard."

we should be saying something like

"This sausage is almost done; we are 85% confident that it will be available for consumption in the mid-April timeframe and 98% confident that it will be ready in time for the Memorial Day picnic in May. If you want to increase the probability that it is delivered in time for April, we can eliminate one of the ten sausages we have slated for April and refocus on this one."

It is in these conversations that we provide our stakeholders with information that is suited to their digestive profile.

Seeing how others see

2008-02-26T15:03:00.000-08:00

I'm taking a Myers Briggs test right now. My whole team is taking the test this week. I learned alot from doing the test in grad school; it helped many of us adapt to our different approaches to working. But that's for another blog entry.

One of the questions: Are you more likely to
a) see how others are useful
b) see how others see

My answer is a), but I wish it were b). That's not to say I'm all about usefulness; I think I do probe on a deeper level more than most would consider typical of a manager. But I think there's something here to work on. The a) answer is more tactical I think; b) is more strategic. Are you seeking results? Or are you seeking to understand the people on the bus¹ to channel them effectively towards helping you to - not only answer questions and solve problems, but to - ask the right questions and identify the approach to solving the problem.

I blogged some time ago about this quote I like - "Managers use people to do work; Leaders use work to grow people." Related (same?) point.

¹Reference here to "Good to Great"... a book that suggests that one of the attributes of a company that bridges the gap from good to great is that it focuses less on the strategy than on the people you have defining the strategy... their metaphor is a bus, having the right people on the bus, and having the right people in the right seats on the bus.

Agile versus Discipline (sic)

2008-02-18T23:16:00.000-08:00

I recently gave a presentation: "Introduction to Agile" at a .NET CodeCamp in South Florida. One of the attendees commented that Barry Boehm had written a book called something like "Agile vs. Discipline".

My first reaction was that this must be a mistake. No informed software expert could possibly posit agility against discipline. I looked it up after the conference. This attendee was indeed accurate. I found Boehm's article: "Rebalancing Your Organization's Agility and Discipline" here: http://www.agileprojectmgt.com/docs/Boehm20.pdf.

Wow.

Wow.

First paragraph of the abstract says: “we realize that ‘disciplined’ is not the opposite of ‘agile’ but it is our working label here for methods relying more on explicit documented knowledge than on tacit interpersonal knowledge”.

That’s like titling an article as “Rebalancing gun control and murder” and mentioning in a footnote that not all murders are caused by guns, but that “murder” is our working label for lack of gun control. However you fall on that topic, you can see the illusion being prepared.

Table 1 shows that the home grounds of “disciplined method” include “stable, low-change; project/organization focused”. How many of you, dear readers, work in such environments? Any?

Table 1 also conveys that “quantitative control” is the home ground of “disciplined” methodologies. Is this to mean that us agilists just shoot from the hip and decry measurement? Not in the least. What’s your unit test code coverage, Mr. Discipline? Do you measure it? I do.

Primary goals of the “disciplined” include “High Assurance”. Indeed. Excessive documentation, analysis paralysis, waiting to show users working code for long periods of time provides “high assurance”? That’s your “disciplined method” for you. Documents in lieu of working code? Is that what assures highly?

I would prefer Mr. Boehm’s table of “home grounds” to relabel the columns “Agile” and “Disciplined” with these terms: “Planning” vs. “Plans”. Here’s the trick. Agile relies on the act of planning and the discipline of responding to change. His so-called “disciplined” methods rely on plans that usually remain static and get modified by committee.

Mr. Boehm’s spider chart shows dimensions for attributes of a project to show whether it is more or less amenable to agile or “disciplined” methods. I’ll take them one at a time:

Personnel. Essentially Mr. Boehm says you need smarter people to do agile. This is probably true. I would argue, however, that you’d rather pay one person $90K who can do the work of two people at $60K and that the diminishment of communication costs between people adds to the economies of scale beyond the numbers. This is true in any environment that you wish to consider. The best programmers, it is said, are 10 times more productive than the average. Why not pay twice the going rate for someone who’s only, say, five times as good?
Dynamism. (%Requirements-change/month). If your requirements don’t change as much, agile is not right for you. What a silly statement. They probably meant to say that if your requirements don’t change as much, you can hire cheaper help who can’t adapt to change. Agile works well in dynamic (i.e. most) environments. You might be able to get by in the rare “stable” environment with excessive documentation, and delay between idea and working code.
Culture (%thriving on chaos vs. order). I love this statement: “[disciplined devotee] thrives in a culture where people feel comfortable and empowered by having their roles defined by clear policies and procedures”. When’s the last time you heard someone say “I am particularly empowered when somebody tells me exactly what to do and when to do it”? I’d much rather have a team of thinking, adaptable, empowered developers than drones who simply follow the process. Am I way out there?
Size. This is the big knock on agile… that it doesn’t scale. I’ve seen it scale… well… fail to scale. I’ve yet to see a successful large-scale agile project up close and in person. But this should not be interpreted to mean that I discount the possibility. I believe it can be done. I just think that it requires enlightened leadership. That’s where the dearth lies.
Criticality. Really, this is plain stupid. Sorry Barry, but this dimension really irks me. When’s the last time you worked as a leaf-node part of a team on a project in either a waterfall… umm, I mean, disciplined… approach or an agile approach. This dimension alone conveys to me that you have lost touch with software development reality. Agile is not the antithesis of discipline. You probably think that agile means “no documentation” – like many ignorant folks out there. Fortunately they’re not writing about it; alas, you are.

One of the paragraphs urges readers to “assess the likely changes in your organization’s profile over the next 5 years”. Please. If anyone has visibility beyond the next year, my hat is definitely off to you. And write it down, revisit it in a year and see how wrong you were. 5 years? No freakin way. Your vision of possible organizational stability warrants an inclusion in the fantasy walk of fame.

Mr. Boehm has a bullet that implies that dependability is a hallmark of non-agile methods. It reads: “key future trends to consider include the increased concern with software dependability and need for discipline”. The authors have crossed a line here. They're no longer using “discipline” as a catch-all for waterfall methods, they’re now using discipline as an inarguable quality. Again, Agility is all about discipline. They are clearly out of touch.

Here’s a phrase that disgusts me: “Examples of potential anomalies are: Operating with agile, fix-it-later developers with a growing, increasingly enterprise-integrated and dependability-oriented user base”. Really. “Fix-it-later developers”… implies that agile developers are hackers who let bugs fester. And that somehow, agile development conflicts with a user base that values dependability.

Unbelievable. Really. Mr. Boehm (and coauthor): Poke your head up into the real world. Join an agile project. Don’t just read about it and regurgitate uninformed opinions.

In sum, I am disappointed, and amazed at the observations in this article, which seem to be informed mostly from uninformed, anti-agile pabulum.

MoSCoW Squared

2008-02-18T22:54:00.000-08:00

Agile business analysts are well aware of the MoSCoW framework. That is - the classification of requirements as "Must Have", "Should Have", "Could Have" and "Won't Have". The beauty of this classification is that it clearly defines the stories in understandable terms of importance - rather than 1, 2, 3, 4.

A colleague of mine - David Smith - recently pondered the importance of several stories across two dimensions. There were features that had high importance to one party but not the other, and there were stories that appealed to both constituencies. He plotted the requirements on a two-dimensional grid, assigning their importance across the two dimensions representing those constituencies. It was so informing and illuminating that I thought other agilists would benefit from the idea. Here's an anesthetized version:

Ultimately, the value of the story stems from its radial proximity to the root. In other terms, you could probably draw an arc reflective of the relative importance of each axis (or constituent).

I hope you find it useful. I know that, for us, it provided an "aha" moment.

Laser pointer token

2007-11-22T07:13:00.000-08:00

It is sometimes challenging in standups to associate the card to which the speaker is referring to the conversation - particularly for infrequent guests. A low tech solution that I recently implemented for my teams is to use a laser pointer as the token that gets passed around. As the speaker is referring to cards on the wall he/she is expected to point, using the laser, to the cards(s) in question.

An ancillary benefit to this approach is that it can be an early warning sign for scope creep when a team member has no card to reference. It can also be a warning that cards are languishing in the "in-play" section - if nobody is referring to those cards, they may not be getting the attention you desire.

They're pretty cheap too.... you can get a laser pointer for as little as $10.

Growing People

2007-10-18T18:56:00.000-07:00

I saw a great quote the other day referenced on a blog. I can't stop thinking about it. It's from the book "Powerful Project Leadership" and the quote is:

"Managers use people to accomplish work; leaders use work to grow people".

This quote captures a great deal of what I think about leadership. It's about really caring about people. You can try to fake it (ala "How to Win Friends and Influence People"), but folks can see through the ruse. True leadership requires, I think, a fundamental desire to develop people to their ultimate potential. It's sort of like the adage "Satisfy the customer; the profits will follow" with a twist: "Satisfy the fundamental needs of your employees to contribute and grow, and the profits will follow".

Agile Leadership and Typical Management Titles

2007-10-07T11:24:00.000-07:00

I worked at a very big company as a software engineer for 15 years. When I began out of college, my title was "junior programmer". The promotion path was well known. Perform at a level between barely satisfactory and outstanding and get promoted in a year to "associate programmer". Keep doing a satisfactory job, get promoted again two years later to "senior associate programmer". Two more years and it was "staff programmer" (and get your own office). Promotions after that were less structured/timed and based strictly on merit.

Well... OK... not just merit.

Of course there was also the management path at this company, but the gig was the same.... keep doing a good job, keep climbing that ladder.

I'm now an agile guy. I look back and can't believe I had to function in such a dysfunctional system. I left that far behind. Or so I thought.

As a consultant, I get to operate in many different environments. Sometimes I get to work with just my team - the enlightened, intelligent, cutting-edge consultants at Thoughtworks and we can build a sort of bubble of rationality - a pseudo meritocracy. More often, I have to manage within the constructs of the company in which I am consulting. Many of them look like my first company where employees are operating on the ladder path.... climbing away. So the question is: when you remove rungs off the ladder in the flattening exercise (whether explicitly or implicitly), what becomes of those who were on those rungs?

Different positions - whether higher (1) on the ladder, lateral, or even lower (1) require different skills and expertise. If you're a developer, you may get promoted to "development manager" because you write great software. The aptitude, skills and motivation to write great software are very different from the aptitude, knowledge, and motivation required to be a good manager or leader. Moving "down" the ladder - say, back to writing software - usually requires missing skills, since technology changes so quickly.

So what aptitude, skills, and motivation do agile leaders need? Here's my list (in no particular order):

Communication/Collaboration skills - "down" - in coaching and developing people within your organization
Communication/Collaboration skills - "across" - in collaborating with folks on peer projects, others within IT
Communication/Collaboration skills - "up" - in managing relationships with higher level IT management/leadership
Communication/Collaboration skills - "Business" - in managing relationships with the business
Technical skills - understanding the technology, architecture
Domain knowledge - understanding the business
Agile Project Management - from estimation and planning to iteration tracking
Ability to inspire
A fundamental philosophy that prefers frequent inspection and adaption to continuously improve

The key for the project, I think, is to ensure that these responsibilities are represented in the leadership team overall, not necessarily in one person.

How do these map to more traditional hierarchical positions?

development/QA/BA manager (managing a group of folks based on functional alignment)
lead developer/QA/BA (individual contributor who is annointed with the "lead" adjective).
architect (might be a member of an architecture team, or may just be a responsibility for someone holding a different title)
director of development (overseeing everything from requirements to release for a project)
C-level leader (person who holds the pursestrings, defines strategy, provides the context & constraints in which the project must operate)

Any of the folks in these positions can provide agile leadership. In general, the more of these leadership aspects that are exhibited by folks in leadership roles the better. For example, though the C-level leader is likely to have ability to inspire, having a development manager who can also inspire can be a great bonus for the project.

Stay tuned for more on each of the agile leadership opportunities I enumerated. In the meantime... tell me what I've missed.

(1) Higher and lower are expressed, for the purposes of this conversation, in terms of the typical hierarchical leadership. I'll save the servant leadership and inverted pyramid conversation for another time.

Myers-Briggs "Lifestyle" dimension meets Agile & Lean

2007-08-07T10:12:00.001-07:00

I was thinking this morning about how Myers Briggs Type Indicators (MBTI) play into our receptiveness and ability to thrive in agile environments and further, into lean approaches to software development.

I think much has been written about the classic programmer profile: INTJ: Introvert, iNtuitive, Thinking, Judging. The poster-child programmer is a loan wolf who uses his analytical skills in a controlled environment to produce excellent software.

From an agile perspective, introverts are, at least in theory, less likely to be amenable to or effective at pairing.I'm not sure this is a particularly apt conclusion, but for now, I'll shelve that thought.

This morning, I turned my thoughts to the last dimension, the so-called "Lifestyle" dimension. That is, Judging vs. Perceiving. From wikipedia:

People with a preference for Judging prefer matters to be decided; to start tasks in good time, well ahead of a deadline; to have clear plans that they prefer not to be distracted from; and they can sometimes seem inflexible in this regard. Those whose preference is Perceiving are happier to leave matters open, for further input; they may want to leave finishing a task until close to the deadline, and be energised by a late rush of information and ideas; and they are readier to change plans if new information comes along. They may sometimes seem
too flexible for their Judging peers.

So: Judging = Waterfall; Perceiving = Agile.

But wait. Isn't Agile just a shorter planning cycle to deal with? "matters to be decided" at the beginning of the iteration; "clear plans", "no distraction". These seem part and parcel of iteration-based development - scrum, for example.

It seems to me that "lean" approaches like not having iterations; just-in-time analysis; polyskilled, adaptable "resources" (aka people) are a "judging" person's worst nightmare. These judgers have already adapted to a shorter planning horizon; now you're asking for a transition from short planning horizon to flexibility - beyond their comfort level.

The challenge is to introduce lean approaches with an understanding of each participant's comfort level.

10 Attributes of Well-Run Meetings

2007-06-16T14:34:00.001-07:00

I love well-run meetings. The key here - well-run. What are the qualities of a well-run meeting?

1) Facilitated. Note the distinction between this property and "led" or "managed" or "controlled". The person running the meeting has good skills at eliciting input, tracking progress and action items, and keeping everyone engaged.

2) Non-laptop/PDA focused. I can't recount how many meetings I've attended where one or, usually more, attendees have laptops/PDA's open and are focused somewhere else. Yes, I understand multitasking and the demands on our time, and the usefulness of getting things done while sitting in a meeting. The cause and effect here is not always clear, but I submit that if the meeting was well-run, the attendees would be riveted to the discussion topic to the point where they'd forget they were carrying a PDA.

3) Accomplishment-bound instead of time-bound. Meetings fill the time they are allotted. If you have 26 minutes worth of productive discussion, don't keep the meeting going to fill the whole hour you reserved. Keep focused, accomplish your objective, and release folks early to go do their email.

4) Speaking of objectives.... HAVE ONE! In agile, we talk about having "acceptance criteria" for story completion. We should adopt the same approach to meeting management. An agenda would be nice too - for more formal meetings - but I don't think it's always necessary.

5) Take issues offline. This is easy for an effective facilitator to drive, but is not done nearly enough.

6) Determine if a meeting is the right approach to accomplishing your objective. I was a participant in a weekly meeting for a couple of months for which the only agenda item was to go through an action item list and report status. I stopped going. So did many others. Fortunately, the organizer(s) got the message and canceled it. We can easily update a wiki as needed to update status. If folks have questions, walk over to the other person's office and talk in person.

7) Find a good time for the meeting. I know that cross-oceanic teams sometimes necessitate bizarre meeting times (unfortunately, early morning for me - ugh). If you have to have an 8am (or 7am or....) meeting, at least bring bagels and coffee or something. And don't schedule lame meetings for that timeframe, because your attendance will suffer even more for the time schedule (in addition to the lameness factor). If I'm an attendee to that early morning meeting, and the alarm goes off, I have a choice.... hit the snooze, or wake up excited to attend the meeting. Unfortunately, my snooze-button is well-warn.

8) Cancel if the right people can't attend. Use those "optional" and "required" tags on your meeting invitations and mean it! If someone is required, and they reject your invitation, find out why and reschedule or address the issue.

9) Don't call all-day meetings unless you have a plan for how to spend the time.

10) Don't forget the remote attendees. I find this difficult; the conference phone is dialed to the conference line and the remote attendees are there, but often the facilitator forgets them, or doesn't include them in the discussion as often as possible. Also - make the communication bandwidth as rich as possible. Use Netmeeting or other conference alternatives to share the desktop with remote participants, and set up a webcam if you can. The more you can do to make the remote attendees feel a part of the meeting, the more valuable participation you'll gain from their attendance.

I could go on. What attributes do you find to be important in meeting effectiveness and efficiency?

Thoughtworks is hiring

2007-03-30T14:26:00.000-07:00

I work for Thoughtworks, a global IT consulting firm with offices in six countries (US, Canada, UK, Australia, India, China). We hire very good people to work on interesting/difficult problems.

We're hiring.

Most of our development is in Java, Ruby, and C# (with Ruby becoming more and more a staple of our most interesting gigs). We're looking for developers, testers, project managers, client principals, and probably sales folks.

Pluses of Thoughtworks:
- You'll probably not find a more competent/smart group of people in any other consulting company.
- We deliver working software using Agile software development approaches (pairing, TDD, etc.)
- Lots of travel (if you're single and want to see the world, we encourage travel to different countries)
- Amazing level of transparency in corporate activities and a flat organization.

Minuses:
- Lots of travel

If you would like more information, see www.thoughtworks.com, or respond in this blog with your email address and I will be happy to provide more insight.

For Dummies

2007-02-11T19:35:00.000-08:00

I've always despised the "For Dummies" book series. It's not the idea... the few I've browsed in the bookstore (with suitable disguise in place) seem to be well-written and humorous. It's the damn title. If I buy the "Sewing for Dummies" book, and interpret language literally, the purchase has nothing to do with my novice status as a seamstress (seamster?) but conveys that I'm actually a dummy.

I must admit I bought one once - but it was appropriate: "Golf for Dummies". My golf game is worthy of the term (nothwithstanding my strict grammatical interpretation argument above).

Saw an interesting title on the shelf at the library today: "Beginning Java for Dummies". This begged the question: where is the "Advanced Java for Dummies" book? And does one exist? Can you get to the advanced tier of "Java developer" and be a dummy? Perhaps the library just doesn't carry it. It was, however, a college library (OK, not exactly a top-tier university).

I checked Amazon. No, there's no "Advanaced Java for Dummies". But there is a POJFD book (OK... take off on POJO.... plain old "Java for Dummies"). There's also "Java Programming for Dummies". Not sure what the difference is. If you're not programming with Java, what exactly are you doing with it? Hmmm.... Perhaps the "Java for Dummies" book describes how to order at Starbucks.

Aside=> My favorite Starbucks order: Alok's: "double tall, two splenda, breve cappacino".... I used to pick up coffee for him and the barista would always eye me and say... "Ah, for Alok?". As if to make sure that I wasn't actually ordering Alok's "usual" for myself. Fortunately, at the time, I had no clue what I was ordering.... it could have come with pork rinds as a garnish for all I knew.

A search for the terms java and dummies on Amazon yielded 412 results. There were only 14 results for ruby and dummies. Hmmm.... guess I figured out where the smart people are hangin' out. To be fair though, not all responses were relevant to the specific technology. The Ruby results included a few "dummies" books whose authors included someone with the name "Ruby". And I'm pretty sure "Ballet for Dummies" has nothing to do with Ruby. Not quite sure how that got into the mix. Didn't have the time to peruse the 412 Java results to weed out the chafe.

Found "Management for Dummies"... hmmm, maybe there is an argument for the validity of this series. (Thinking about managers from previous companies of course.... really.... wonder if any of them are still on my Christmas list?)

Shoemaker's shoemaker

2007-02-10T10:42:00.000-08:00

Sometimes I feel like a shoemaker who walks around life in bare feet. I'm a software development professional... consultant even. I help companies create advanced software.

My colleagues are hot on IPods, Macs, PS2, XBox, fancy cell phones.

What's wrong with CD's? I've got a CD player... a bunch of CD's and I can cycle through them. I know, the IPod and other MP3 players allow you to consolidate. OK, good. I have sparse financial resources (4 kids!) and have to wisely allocate those resources. Do I need an IPod? Focus on the word "need". Do I really NEED it? Yes... I'd like one. (feel free to post a response and I'll give you my mailing address for your to send me a check.... or maybe I'll even figure out how to do PayPal, or whatever the cool version of it is now)

Macs.... I really don't understand this one. OK, it makes some cool things easier.... like creating movies, music, art, etc. I'm a left-brained guy. This is not as important to me. If you're a computer guy complaining to your management/IT department that you can't be effective with a PC.... but if they were to get you a MAC, boy, you'd be smokin'.... check your motivation. I mean, really... as an IT professional.... you can't figure out how to make your Windows experience efficient? Be honest with yourself.... you're after the cool factor. You couldn't get the chearleader in school, so now you're trying to be the "football player" of cool technology. Give it a rest. If you want a Mac, buy one yourself. And stop your bitchin.

Gaming machines.... really. Sounds cool. Why don't you try LIVING life instead of experiencing it vicariously through the imagination of some geeks who create virtual worlds? Reminds me of a guy ... good friend actually.... who claimed he couldn't make our volleyball match because he had to sit at home and watch a Giants game. What's with that. Do you live life, or are you a spectator?

Do you really need to check your email via the phone? Really? Are you that important? Ask yourself ... as you thumb through your emails in mid-conversation with a colleague or employee of yours.... is this more important than human contact? I had a manager once who thumbed through his blackberry as we had a "one-on-one" at a Taco Bell of all places. As I was conveying my career goals and such, he was thumbing through the blackberry and mumbling... "uh huh". Please.

Lastly... this "connectedness technology" does not exist for you ... it's for me. If you expect me to answer my cell phone when you call, you have severely mistaken my motivation for obtaining said cell phone. You see... I bought it to make it easier for ME to connect to others.... not for YOU to find me at all hours of the day and night.

Dope a rope

2006-12-20T07:16:00.000-08:00

So you're on a team using all of the agile techniques (please don't say methodology). You're pairing, using TDD, daily standups, etc. You have the maturity to understand (or you've been on the other end too many times) that micromanaging doesn't work, but you want to keep a close eye on one of your team members; the code she writes often ends up being less than healthy. In fact, it sometimes is beyond refactoring and needs to be rewritten. You'd rather she not spend a great deal of time going down ratholes. What do you do?

Rotate pairs often. This is a stealthy/healthy way to keep fresh eyes on the problem. It's the classic agile way of spreading the perspective around.

Dope a rope. This is a technique I use sometimes to be welcomed into another developer's sandbox. "Dope"... means I express ignorance (maybe too strong a word) about what he's doing and ask 3rd grader type questions. (Easy for me now - as I have no developer credentials on my current project and am acting as a project manager). I ask for explanations that lead the developer to "throw me a rope" and pull me into the code to show me.

What is the result? The developer sees that what he's doing matters (because I'm paying attention) and feels confidence (after all - he knows more than me). I get an opening to subtley convey suggestions for improvement. And I usually learn something.

Cram First

2006-10-21T13:48:00.000-07:00

CRAM First

CRAM is an acronym that represents a model for dealing with workplace performance. I first heard it in business school – in my Managing People and Organizations class. It resonated with me at the time and has endured the test of time: 7 years beyond graduation. How much do you remember that long after school finishes?

The natural reaction to underperformance of a team member is to blame it on motivation. “He’s lazy” or “She’s just not applying herself.” While this reaction may be accurate, there may be other more substantial issues that render the motivation issue irrelevant. This model can help to “peel the onion” to find more basic issues related to performance.

To the point: C = Constraints; R = Resources; A = Aptitude; M = Motivation. Think of these as cascading (or – like Maslow’s hierarchy of needs – a pyramid).

Constraints: I have been divorced twice. The first time I got separated, I was working at IBM on mainframe operating system development. I was on an elite team doing cutting edge development – writing software that translates service-level-agreement objectives into algorithms that adjust resource allocation within the system to achieve performance objectives. It was complex work and demanded a great deal of concentration.

When my personal life took a dive, I would – literally – sit in front of the computer screen and stare at it. I felt like a zombie. Though I knew that I was falling behind, I didn’t want to – no, that’s not right – I didn’t care about raising a flag to indicate that I was in trouble. I’m sure I experienced aspects of clinical depression. I finally spoke to my manager. He moved me onto a less complex part of the project, where I flourished. I was fortunate that my prior performance provided evidence of my capability, so my manager was able to understand the impact of my personal issues.
So ask me – was I motivated? I don’t know. I didn’t care. My issues were more foundational – my motivation was irrelevant. Ask a homeless person if they are working on self-actualization.

Resources: In this day and age, why doesn’t every developer have a big flat-screen monitor on which to work? Why don’t they have 2-gig systems (or more) with dual-core multiprocessors to speed their work? Understand that the more lag time there is between tasks, the more start/stop energy that gets expended by thrashing. If my build takes 4 minutes, and I start looking at cnn.com in the meantime, I’m losing my concentration. Nobody can be expected to maintain concentration over this time.

I run meetings where I need a projector. Management decides to purchase one projector to share among 50 people – to save money. Consider that I’m costing you $150 an hour… so every 10 minutes I spend hunting down, or reserving the projector costs you $25. Moreover, I’m losing concentration on the tasks I could have been performing.

Administrative assistants provide incredible leverage for productivity. I spent an hour recently reserving rooms for a recurring daily meeting using a terrible Lotus Notes conference room scheduling implementation. You can hire great administrative assistants to do this at a much lower cost. Think of me (and other high-tech workers) as expensive pieces of machinery in your manufacturing plant. To optimize your profit, you need to keep your expensive pieces of machinery at optimum capacity. Don’t eschew paying $50 an hour for a maintenance person who keeps a $1,000 per hour piece of machinery humming.

Aptitude: I had a good friend/colleague at IBM once who was extremely bright. He had (presumably still has) a quick wit, a great attitude, and could solve some complex problems with ease. He had a master’s degree in Mathematics. Unfortunately, he was working as a programmer. He wasn’t a great programmer. He was eventually managed out of the company. To this day, it bothers me. I was his team leader, but I was young and had no leadership sense. I was timid. I wanted to get along – climb the IBM corporate ladder – become CEO someday. My friend was not a poor employee; his best skills were simply not being leveraged. He would have been an outstanding software performance analyst. To this day, when faced with seemingly incompetent people, my experience tells me to look for where the aptitude lies. That person may not be shining in his current role, but may be brilliant in other areas. Let’s find the areas where we can all be brilliant.

Motivation: Some people are lazy, unmotivated – whatever. There are reams of books on motivating people – particularly in the sales arena. I’m sure some of these tactics work. But motivation is irrelevant when deeper issues exist. Don’t be lazy in managing these individuals. Figure out if there are more foundational issues to address before giving your next motivational speech. CRAM first; motivate later.

First Post

2006-10-21T13:27:00.000-07:00

My first post. This blog is my foray into blogging on tech topics related to (in no particular order)

Software development
C#/.NET
Agile Software Development/Scrum/XP Programming
Software development career paths
Human Resource Management in the software industry
Project management/Iteration Management/Scrum Mastery
People Management
Performance Measurement/Balanced Scorecard/Metrics