Articles

Break the Email Chain

One of the problems in a geographically distributed team is the dreaded email chain. Someone has a problem and sends an email. Probably late in the day, when he or she is frustrated after pounding on the problem all day, getting nowhere–except more frustrated.

On Beauty, Quality, and Relativity

The saying “beauty is in the eye of the beholder” rings true whether you’re staring at a centuries-old painting, listening to a busker’s music reflect off the tiles in a subway station, or testing software. It’s one thing to evaluate quality, but how do we evaluate how we evaluate quality?

Paper v Electronic Dashboards: Goals and Values

It's almost a matter of dogma that, for agile teams, low tech project tracking tools and artifacts are superior to electronic ones. The usual reason you might hear for preferring a physical task board to an electronic issue system are are that a physical task board is more visible and encourages communication and collaboration. I appreciate this, and have seen it, but I've also seen teams do well with issue tracking systems. From time to time I see a discussion of this "physical v electronic tracking" issue and I find myself frustrated by it, but not sure why.

Question Your Project Customer

When leading technical projects, project managers and their teams know the task ahead can be a daunting one. So, when the customer comes with a desired solution mapped out and detailed requirements in hand, the first thing you want to do is move forward. That's your cue to start asking questions.

Agile Code for Agile Teams

What makes a team agile? Is it in the way it plans projects or how it engineers its products? In this article, Steve Berczuk explains how agile code and technical practices can help a team stay agile across the product lifecycle.

We're Not "Special"

Often, when I comment on someone's blog post or respond to a tweet with a story about how my team succeeded with some practice, someone replies, "Yeah, but your team is special." I interpret this as meaning, "You're a presenter and book author. You must be an expert, so of course your team can do anything." This frustrates the heck out of me.

Management Myth #2: Only ‘The Expert’ Can Perform This Work

How many times have you seen this in your projects: You need something specific done such as a new database, or a specific user interface designed, or you need a release engineer, or a user interface designer, or a part of the system tested and the normal person who does that work is not available? What happens on your project? Does it wait until The Expert is available?

An Obvious Bug or a Deliberate Strategy?

What first may appear to be an obvious bug, may not be after all. Closely looking at a recent experience shopping online revealed what first seemed like a bug, but could also have very well been a cleverly placed, well-executed sales strategy.

Growing Your Processes

You can’t force a garden to grow, and you can’t force new processes to work. However, like the gardener who prepares and maintains a garden for optimal plant growth, you can use a planned, organic approach to lead your processes more successfully.

Pragmatic Managers Posted for Your Reading Pleasure

I have posted 2012′s Pragmatic Manager emails. I have been writing in themes this year:

I am writing about geographically distributed teams in preparation for my Geographically Distributed Teams Workshop with Shane in April: