A few weeks ago I gave my opinions on James Shore’s idea of manual continuous integration.

Today the continuous build for one of our projects has three steps:

1. Check in code to CVS repository.
2. Log into the build box and manually run a <div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">

   1	cvs update

   </div>
   

.</li> 

  * Wait for cruisecontrol to run a build and send out email notifications.</ol> 

Our other projects have a two step build:

  1. Check in code to CVS repository.
  2. Wait for cruisecontrol to run a build and send out email notifications.

The reason for the three step process is simple pragmatism. After you spend 40+ hours between yourself and a developer trying to get it to run you should look for something that works. The problems we ran into were numerous:

  * Turned out figuring out how to run maven2 from cruisecontrol was a bit annoying. We ended up having to use the mvnscript command instead of mvnhome. The note in cruisecontrol&#8217;s documentation was a hint at the problems we&#8217;d see:
> Due to the current status of Maven (in heavy development) only the &#8220;script&#8221; start mode is supported.

  * Then for some reason we still haven&#8217;t been able to figure out the <div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">
      <table cellspacing="0" cellpadding="0">
        <tr>
          <td class="line-numbers">
            <div>
              1<br />
            </div>
          </td>
          
          <td>
            <div class="text codecolorer">
              scm
            </div>
          </td>
        </tr>
      </table>
    </div>
    
    plugin in maven just didn&#8217;t work for updating from CVS from cruisecontrol. It would just bomb on the pserver password over and over despite the fact that the user it was launched under already had a valid
    
    <div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">
      <table cellspacing="0" cellpadding="0">
        <tr>
          <td class="line-numbers">
            <div>
              1<br />
            </div>
          </td>
          
          <td>
            <div class="text codecolorer">
              cvs login
            </div>
          </td>
        </tr>
      </table>
    </div>
    
    performed.</li> 
    
      * Next we tried just adding an extra ant target to do the CVS checkout. That didn&#8217;t work because cruisecontrol would checkout the project from the first ant command, and then return success and complete. It turns out you can&#8217;t run an ant and maven task within the same project.
      * Then I tried setting up two project, one to just do the checkout, but I couldn&#8217;t get the dependencies to work in cruisecontrol.
      * Then I tried luntbuild which was a bit of pain to setup, but finally looked like it was going to work. Only as soon as it starts to run maven2 it fails and exits with an unsuccessful build.
      * Then I tried to look for an ant task to run maven from ant. Turns out you can run ant from maven, but the [tasks](http://maven.apache.org/ant-tasks.html) are only for utilizing Maven&#8217;s artifact handling features.</ul> 
    
    The worst part is that in the past 30 day Sprint we&#8217;ve missed important build failures including several checked in unit tests that were failing and lately even some missing files that were causing the compiler to fail.
    
    So we&#8217;re back to manual continuous integration instead of investing more time in the tools.

As a manager you’re often privy to information that isn’t necessarily passed down the chain or broadcast to line employees. Many managers horde much of this information and unwittingly lose out on a lot of good information.

If you regularly hold back information from employees they will soon learn that sharing rumors and news with you is a one way street. Their answer is simply to stop sharing. And often times your employees have quite a few bits of info you’re not privy to because they have their own networks within the company.

The fear of sharing information with your employees probably stems from the idea that information is power or that sharing information with employees will just cause them unnecessary worry. The truth is not sharing with employees will certainly cause them more worry and damage their trust in their manager.

I regularly speak to my team and individuals on my team about almost anything. Some items that are worth sharing include:

• Explaining budget cuts or last months financial numbers.
• Giving at least my opinion on why a particular executive might have left the company.
• Passing along any information gleaned about a corporate headquarters move or a possible merger.
• Explaining proposed changes in technologies that will mean developers have to ramp up on something new.

The best payback is that I get back just as much information from my employees and everyone can act more rationally and spend less time worrying. And that means a more productive team.

Just held the review today for the end of Sprint #6 on an intranet portal project. We’re pretty much down to Sprint #7 and then we can finally release it on the employees. Along the way we’ve learned the following things:

• Websphere Portal 5.1.0.3 and especially it’s content management features (WCM) are fairly primitive and not that well integrated for maintaining a content site with 40+ contributers.
• Having 4 different product owners over the life of the project makes it difficult to stay headed in a single direction. Luckily the last remaining product owner has been working directly on the team for the last three or four sprints.
• Estimating and tracking many of the work items are difficult. How do you estimate how many training classes you need, and how do you know when you’re done? How many items are just pure timeboxed research into possible intranet features? And at the review meeting how do you demonstrate new functionality when say 60% of the Sprint was setting up and running training classes.
• Intranet projects are inherently political beasts. Everyone has a vested interest or even lack of interest in how their division’s content is organized. You will end up in some huge conflicts despite all possible precautions.
• Many normal Agile related practices are non-existent. TDD, continuous builds, refactoring just don’t apply.

My brother and a very good friend recently launched a little web 2.0 site around ranking webcomics, KungFuGRIP. It rips on the Digg/Reddit model, but specializes in a narrow vertical. The cool thing is it got created and launched with nothing but some time investment:

With the Web of today you can put something up with little heavy lifting. An engineer friend and I built the majority of my last project, KungFuGRIP, in a Sunday afternoon using Drupal. Once live we started making tweaks based on user feedback.

The lack of multiple planning/coordination meetings in Scrum is a key appeal for developers. The message is very clear. Spend one day planning and then Sprint for the next 30 days. Check in every day for 15 minutes and then let the team decide if they need other meetings.

Simple enough, unless you’re transitioning from a normal project management environment with command and control. Meetings suddenly appear on everyone’s schedule. The concept of just letting the team decide these things is lost and you have a lot of unhappy developers in meetings wondering how they’re going to meet their coding commitments.

The story is very different if the team decides to have a meeting to say review a rough draft of the likely use cases for the next Sprint, or talk about how to resolve an issue with how long it takes to migrate code to the QA environment. There the team members have committed to each other to attend and help out. That personal commitment is really the point. And often these can be informal meetings in a cube or an empty conference room rather than a scheduled two hour session in the middle of the afternoon.

It’s hard to evolve out of traditional meeting hell.