Mike Benner

To follow up with my post on keeping your tools healthy, I want to talk about the downsides to them.  Automated Server builds are great, they make setting up servers a painless and mindless task.  But is that a good thing?  What if something goes wrong?  What if they are out of date?  Can you fix it manually?  More importantly can you fix the tool?

You should know the underpinnings of the tools you are using, especially ones built by your team/company and are key to your success.  Does this mean you need to know the complete ins and outs?  No.  But you need to know what is going on.  Take some time when you get a new script and look at the source.  Understand it, and if you can't ask the author or someone that can help.  Not only will you be better for it, you may be able to improve upon it.

Take some time and think about those automated scripts that you are using.  Open them up and review them.  Increase your knowledge and improve your tools.

One of the concepts in Agile Development is use automation tools.  These tools can run through a wide range of options, but typically you would have automated server builds, testing suites, deployment tools, etc.  These tools should be stable and reliable.  In the Rails world things change quickly and updates are pushed out a much faster intervals than other non open source environments.  This can cause your tools to become out of date and less than reliable rather quickly.

When this happens, you may find yourself, hacking together work arounds or just plain doing it manually because of your work load.  While this may seem like a good idea in the short term, the long term affects can become paralyzing and complete efficiency killers.  When you find this happening to you and your team, stop sawing.  Sawing with a dull blade will get you nowhere.  Not only that, but it can lead to bad habits.

Team members can become apathetic about the problems, can start to lose pride in their work and environment or worst yet, stop doing that extra step that makes them better because it "isn't worth the effort/time".  Visibility drops and the Agile process can start to break down.  If you find this happening, take the time to fix the problems.  Too busy sawing?  Work a second shift, come in on a Saturday, rally the team to do nothing but sharpen the tools.  A good team can get the process back on track rather quickly and the overall results will be seen almost immediately.

Estimating has always been a hot bed of contention everywhere I have worked, including my own business.  This has been a hot issue around the office over the last few weeks.  There has been talk of over estimating (aka padding), under estimating and incorrect baselines to name a few of the problems thrown around.  But more important than those "problems",  what is starting the dialogue?

To begin with developers get caught up with the "I burned through more points than you did" mentality.  Depending on how you do your baselines, you can't be competitive with someone on another project.  The least complex story (1 point) and the most complex story (13 points) can be drastically different between a simple online store and a full blown CMS.  So we need to set that competition aside and not worry that I was only able to keep a velocity of 18 points while my team member burned 38 points.

Another reason these discussions begin is caused by acceptance criteria.  The product owner starts adding criteria that makes that 3 point story seem like an 8 point story.  This is where dialogue between you and the Product Owner comes into play.  Remembering that an estimate is just an estimate and is based on the simplest possible solution, what can happen here is scope creep.  Product Owners will sometimes build other stories into their criteria and other times simplest possible is not what they want.  This is not the fault of the estimation, as a matter of fact, it isn't a fault of anything, it is why we adopt an Agile methodology.  The criteria, if large enough and justifiably, can be broken into multiple stories, then do that.  Have estimations done on the new stories and keep that dialogue going with the product owner.

Also, there is the problem of experience and knowledge level.  What may seem complex to you, may be simple for another team member.  But, if you are properly running as a team, that should also make it simple for you when you bring it up at your morning stand up session.  Set some time aside and time box a quick session with a team member to pair with and get that complexity down for you.  Learn how to use that plugin you have never heard of, learn a pattern you have never used or even try that obscure method that is buried in the framework.

Ultimately, remember an estimation is just an estimation and the reason for Agile is to adapt and iterate in quick sprints that will allow for changes, that yes, will sometimes make the original estimate seem off, but what matters is your daily dialogue with the product owner and holding to a true maintainable velocity, even if it is only 9 points a sprint.

At Integrum one of our policies is a very open accountability.  Whether it being calling some one out on being late to stand up, not running tests in their project or just calling bullshit on an excuse, anything goes.  At first I was kind of blown away at this method, conversations I felt should be handled one on one and in private, were happening in front of the team and it was quite a shock to the system.  Then I witnessed a gigantic burn down chart for the day, placed in the center of the room and a developer sitting in front of it updating over its 6 hour range.  Yes, this was an extreme example and all done in fun, but you know what, it worked.

But it doesn't always work.  Some people will let it just roll off their backs and repeat the same behavior day after day, while others immediately get defensive and are too busy thinking of how to respond, deflect and excuse the problem to actually learn and adjust.  The latter of the group, don't realize they are not "getting in trouble", but are being helped and by it being an open forum everyone can typically glean some knowledge from the discussion.

For me personally, nothing beats the open accountability method.  Call me out, make me aware of something I may not even be aware I am doing.  However, with the wrong team members, typically people that aren't self motivated and don't strive to be better, this system only breaks down into public arguments and can actually make for an uncomfortable work environment and limit productivity.  

While I highly recommend this method, make sure you are staffed with the right group of people.  People that want to be better.  People that want to make their team members better.  Odds are if you have assembled a team that contains these like minded individuals, they will have already started this methodology and will embrace your companies official shift to Open Accountability.  When things start clicking prepare to see individual growth increase and team growth explode.

A few weeks ago I won a copy of RubyMine 2.0 from the Phoenix Rails Group Meeting.  I had played with it before (RubyMine 1.0 on Leopard) and was sorely disappointed in its performance.  I had been wanting to play with the new version especially after the Snow Leopard upgrade.

I spent the Thanksgiving weekend playing and configuring the environment.  There was a significant difference this time around, no beach balls.  Yup, the performance was much better.  Having been bred on IDEs since my days of building COM+ objects in VB, I like having my environment do most of the lifting (heavy or light) for me.  Heck, I even had TextMate configured for not only Git but to deploy on command as well.  Which brings me to the point of this post, how to use git and run your deploy script from within RubyMine. With Git integrated out of the box I looked for a way to deploy.

So I found this great little post on Not a Ninja that handles it doing the following:

My excitement of a quick and easy solution was overcome by the errors that continued to arise every time I tried to commit, push and deploy.  The errors were self explanatory, but confused me.  RubyMine was reporting that Git was not installed on my machine.  So I jumped to the shell and it worked, then flipped over to TextMate and it also worked so what was the problem?  I went into the RubyMine preferences and checked out the configuration on Git and the executable was listed as just 'git'.  Trying several options here all with no luck, I began the Google shuffle.

What I discovered was that because .bash and .bash_profile only work with the Terminal App, that RubyMine has no visibility on the PATH variable I have set in there.  OK, so that explains why RubyMine has no idea where Git is installed, but how do I get around it?  Apple recommends using the environment.plist so I head down that road (the path pun was to easy).  After a few tries and some reboots, I still have no success.  So now what is going on?

After some searching, I discover that if you use Spotlight to launch your app the environment doesn't get loaded.  Seriously?  More searching and I find another solution.

Pivotal Labs had the answer (and apparently wasted as much time looking for the answer as I did).  You have to set your environment variables in /etc/launchd.conf.  To do this open your terminal and enter the following:

1. which git
2. No copy your results
3. sudo nano /etc/launchd.conf
4. setenv PATH /usr/local/git/bin/git (or whatever you which git result in)
5. Save and Reboot