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.

Rails is just darn nice for making easy to test. I finally got around to trying out the autotest package (via a mention byLuke Melia) and now I’m just churning away TDD style while the tests run in a terminal window, without stopping to do any invocation or even a keystroke.