I have an article up on PM Boulevard: Choosing the Strategically Important Work. Enjoy! (I think  you need to register for this site too. Free.) Tweet This Post

I have an article up on Gantthead.com, No Planning Needed? (Free registration required, I think). Tweet This Post

I’ve had a rough month. When I returned from Agile 2009, my right ear didn’t unblock from the plane. I couldn’t hear out of it, and it was blocked. I didn’t think much of it–I went to the doctor who said, “yup, you’ve got fluid. Take decongestants.” I did, and the vertigo got worse. Finally, [...]

I'm starting to gather my thoughts for the October issues of CM Crossroads which has a theme of "Overcoming Resistance to Change." Some of my favorite books on the topic of enabling change are:

• Fearless Change: Patterns for Introducing New Ideas
  by Linda Rising and Mary Lynn Manns
• Becoming a Technical Leader: An Organic Problem-Solving Approach by Jerry Weinberg
  
• Quality Software Management: Anticipating Change (and other books in the QSM Series) b Jerry Weinberg
  

While I can't possibly cover all of the ground that these books do, I can share some observations I've made while trying to help teams to do things differently, such as adopting Scrum or developing a more agile release management approach.

A common reason people resist change is because they follow "rules" that they don't understand no longer apply. When these "rules" are embedded in the culture of an organization the challend to change is greater, since its often more pardonable to fail when you've followed the established practices, than failing when trying something new. This is a big challenge to overcome, and there is no easy answer to addressing this challenge, other than to be aware that this behavior may be happening. But there are a couple of things that help make enable change:

• Leading by example. Often others just don't understand that other ways are possible.
• Gather (visible) data. Often others ignore uncomfortable facts.

As an example of the first point, I've been on teams where unit testing was dismissed as simply too hard to do, or a waste of time. By a small group adopting the practice in small cases (and refactoring the more difficult code to enable unit testing), they can demonstrate how the presence of the tests helps improve quality and speed of delivery. In this way a small group of enthusiasts can lead the way for the more timid. (Really Dumb Tests discusses a similar point.)

In other cases, the team isn't aware of a problem. A colleague of mine recently said "you can't change what you can't measure," and gathering data is essential to making a team aware of a need to change. Once you have the data, you then have the ability to make decisions, and then measure whether those decisions have the desired effect.

To make this concrete, imagine a team that is estimating tasks based on a 7 hour ideal day (and an 88hour work day). At the end of each 2 week sprint the team either isn't meeting its goals or is feeling overworked, yet none of the tasks seemed more complicated than expected. One possibly is that that the teams days aren't really 7-hours. To measure this you could keep a chart on the wall, measuring team and organization meetings, adding marks to a bar chart after each activity that seems unrelated to coding. If at the end of a two week sprint this number is much higher than 10 hours (10 days*(8hours@work-7hours-coding)), then you have some options to consider:

• Run meetings more effectively
• Decide if all of the meetings add value
• Decide to estimate based on a shorter ideal day
• Decide that the work day needs to be longer than 8 hours.
• (etc)

It's important that:

• The data collection be lightweight and that everyone understand that the data need not be entirely scientific to be useful. Too much effort to gather data can derail a change effort because of perceived cost.
• The data be visible and incremental. A hand drawn chart on a wall can be more effective than spreadsheet data that lives on someone's laptop. (But electronic data can also be made visible in the right context)
  
• The team evaluates the data with a goal of improving, not blaming. Maybe the extra time was spent in meetings was well-intentioned, or even necessary.
  
• The team consider a number of options to change the situation. (See Finding and Evaluating Options for more on evaluating options.)
  

What's useful about data is that it avoids arguments about who has the most accurate memory. Collecting data may not solve the problem; the data may leave you with more questions than answers, but without data you'll have no good way to decide what to try changing, and if the change had the desired effect.

Change is hard often because people often don't understand the need for change, or the possible changes. By demonstrating the alternatives and their value, and by gathering data to evaluate current practices, you can start the process.

I wrote an article for the September/October issue of Better Software Magazine: IDEs and Build Scripts in Harmony where I discuss how to use build tools, and IDEs while minimizing duplicate work and getting the benefits of both tools.

As usual, the editors did a great job selecting metaphorically appropriate art work, and there is lots of other good content in the issue, including an interesting commentary by Lee Copeland on testing, Scrum, and "testing sprints."

I won't repeat anything I say in the article (since I already said it), but I want to add some philosophical comments. The question of working in environments that use IDEs for development and integration builds that are driven by other tools is one that I care about because it involves some of the issues that often cause a lot of angst and discussion on development teams:

• Standardization and the effects of tools on individual and team productivity, and
• Repetition: having the same information in two places.

Many of these problems can be solved by tools that separate information appropriately. For example, dependency information in build scripts, formatting information in IDE settings, so you don't need to have duplicate configurations checked in. Or even having some sort of canonical way to describe formatting rules which you keep with the build scripts in a form that IDEs can leverage. This frees developers to use the tool that they are most accustomed to (and productive in), while maintaining the amount of standardization that helps teams be more productive.

I hope that you find the article interesting and thought-provoking.

---

Note: There was a production error that caused an old bio to show up in the print edition. I work at Humedica, not where the bio says .

I’ve been working and speaking with whole bunch of people who want to “go agile.” They are not set up for agile. They have gates for approval. They don’t have teams that projects flow through; they assign people to whatever project whenever. (growl. People are not fungible. growl) They have geographically distributed team bits (I [...]

I recently wrote an article on how to say No, and a twitter follower wanted to know what to do when your manager can’t hear no. First, understand why your manager can’t hear no. Is it because the business pressures are so great that the cost of saying no seems insurmountable? Managers are people too, and [...]

I’m yak shaving this week. When I returned from the Agile conference, my right ear didn’t clear. It’s all clogged now, and the left one isn’t totally clear either. I have vertigo. I’m moving slowly and look drunk when I walk. In the meantime, I have articles to write, proposals to finish, work to do. I [...]

This past week 97 Things Every Programmer Should Know was made available to the public. This project was driven by Kevlin Henney, who I know from the early Pattern Languages of Programming conferences, . The list of contributors contains many familiar names, and I'm honored to be among them.

My contributions are about the agility, deployment, and their intersection. They include:

• Own (and Refactor) the Build
• Deploy Early and Often
• Understand the Principles behind Practices, and
• Acknowledge (and Learn From) Failures
  

This project has contributions from many really interesting and insightful people. Maybe you already know everything on the lists, but you might get a fresh perspective by reading the contributions. You are very likely to start thinking.

On a related note, this past week, there was a conversation in my office between one of my colleagues who is a parent of a toddler, and one who isn't about why one works so hard to sound excited when talking to children about tasks.

You might say in an excited tone:

Being the proud (some who know me IRL might say too proud) parent of a 2-year, 9-month old boy, this got me thinking about why parents do this, and why it works so well. I suspect that the reasons are two-fold:

• Toddlers don't (yet) get the idea of consequences, but they get the idea of "fun" so framing something as fun and exciting is just the path of least resistance.
• Toddlers are wired to explore and learn, and every new thing is fun!

I'm realizing that, while as professionals, we need to do things for purely practical reasons learning about how to work better can (and perhaps should) be fun too. Seeing how toddlers learn makes me wonder how much of that joy of discovery we give up as we grow, and whether we need to lose it.

So as you read through the contributions in 97 Things, try to find something new and learn about it not just because it's something you should know, but because you enjoy programming, and because learning new things is fun!

See Claude Emond’s review of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects. You have to register (free), and you can say “don’t email me anything” Thanks, Claude! Tweet This Post

Last week was the Agile 2009 Conference. It was great. The stage producers and their teams had selected a phenomenal program, Elastic Communications outdid themselves as the event planners, and the volunteers helped everything proceed smoothly. Alistair Cockburn and Jared Spo0l delivered fabulous keynotes. Here’s my personal retrospective: What stood out for me: the sheer quantity [...]

It’s a big week for me: Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects is shipping. In the approximately 24 hours I was home, I got to touch the first books. When I proposed this book, I wanted it to be 175 pages: long enough to be useful, but not so long that [...]

Agile 2009 starts today. I am so excited. (I know, I’ve been saying that a lot. Well, I am The event planners, Elastic Communications have been on top of everything and are making the whole conference come together. Open Jam looks great, with small tables and some comfy couches all over. The rooms get [...]