I’m off to my first open space conference later this month at Open Agile California. Should be a great chance to recharge some batteries and talk about issues with sustaining agile. I know after three years of Agile and two years of our official effort that we no longer do a lot of questioning and looking outward for new ideas. I’m focused on how you re-energize an organization at this phase, especially when many of the original high level sponsors of the effort have moved on.

As the consequence of a reorganization I have a lengthy new title at work:

Manager of Enterprise Architecture and Governance

I’m no longer a software development manager building up a team and delivering projects. In the near term I need to develop a charter, hire at least one new architect, and get started on some basic foundational work such as coming up with as-is and to-be models of our architecture.

I have some plans for how to be an effective enterprise architect team:

• Concentrate on people. Mentoring, training, and guiding people will help you implement the right architecture.
• Plan big, small steps every day. Incremental is the way to get there.
• Governance disagreements should be rare.
• The business needs to trust you. Confidence building takes gobs of time, but if you can’t keep convince your business customers, you can’t make the big changes.
• Architects must code. No one gets to step back and just spend all their time in UML and Powerpoint. Everyone has to spend some time on real projects implementing their ideas and getting direct feedback on how well things work.

Nothing like defining a new role from scratch to get me out of bed in the morning.

Glancing at a Hudson dashboard in the morning I crack a little smile. 9-10 project statuses are right there in front of me.

</p>

Great T-shirt on an audience member. </div>

I gave a two hour presentation on Hudson this week at our local Sacramento JUG on “Happy Builds with Hudson”. About 20-25 people showed and I got plenty of good questions from the audience. I did ask one audience question. By a show of hands how many people already have a continuous build. About 50% of the room raised their hands. The adoption rate is pretty good, but continuous integration is probably the easiest XP/Agile practice to adopt and half the room still hasn’t tried it out yet.

I covered Hudson fairly deeply including:

• Dashboard weather icons. Now you can see the recent status of your project at a glance, not just the last build.
• Static analysis plugins. They’ve added plugins to merge findbugs, checkstyle, PMD, and todo tasks into graphics with trend lines.
• Master-slave builds. Still haven’t tried this out or really needed to, but nice to know it’s there.
• Matrix builds. You can setup a single project, but define different JDKs, different OSes, etc and Hudson will automatically create builds for all of the possible options.

If you haven’t taken a look at Hudson and you’re not 100% happy with your current build tool there are just three steps:

1. Download hudson.war
2. Run:

   1	java -jar hudson.war

3. Open a web browser to http://localhost:8080

Lesson learned a few years ago:

Don’t bring your laptop to the meeting.

As an early wifi adopter I relished bringing my laptop to every meeting. Better efficiency, better note-taking, and instant gratification if you needed to Google something at the meeting. And just wrong.

The whole point of meeting is to make some decisions in a group setting. The laptop is a distraction. If you a scribe for the meeting you might be able to justify typing in everything almost verbatim, but for anyone else you just need to log the action items that come out of the meeting and maybe a few noteworthy discussions.

I had good intentions when I used to bring a laptop to all my meetings:

• Typing up notes right in the meeting saved transcription time.
• Heh, I’ve got that defect right here and it says it was closed an hour ago.
• Hold, on let me IM Sandra and see if she how many hours she has left on the redesign.
• Great action item, I’ll just compose an email and delegate it off right here.
• No, the server is up right now, I just pulled up the login page.

With a laptop at the meeting you’re constantly reminded that this person might have a point, but you could cycle through a few emails and really not miss out on anything. I’m sure they won’t notice a little bit of typing.

If you really could get more done just working on your computer, maybe this badly run meeting isn’t the place to be. What you really need to do is re-examine your need to be at the meeting.

Perhaps every few weeks I bring a laptop to a meeting. Two possible reasons:

• I’m actually giving a presentation with it.
• It might be useful to quickly check some online reference information like our bug tracking database or log files from a server outage. (It stays closed unless the need actually arises.)

Always use caution with email. Even an innocent signature line communicating the fastest way to reach you can be misconstrued.

I read Tim Ferris’s book a few months ago. Many different ideas on how to be more effective using less time. I tested out the idea of batching email and only checking it twice per day. Checking email at only 12:00 and 4:00 and batch processing saves at least 30 minutes per day. Successful experiment!

I had a simple addition to my signature line to explain this.

Due to increased workload I’m checking email twice per day at 12:00 and 4:00. Please call me on my cell at 555.555.55555 if you need to reach me sooner.

I got a bit of helpful feedback from another manager a few days ago. The suggestion was to maybe reword the signature line as some people might have construed it in a negative light. Email is dangerous that way, lack of context can lead people to the wrong conclusions.

The email explanation signature is gone now. The real gift was another manager comfortable enough to give feedback.