James Shore has a post on Informative Workspaces. He suggests using hand drawn charts and having everyone on the team update them where possible. Some of his ideas for charts include:

• A chart showing pairing time.
• A chart showing pairing combinations.
• A team calendar.
• A code coverage chart.
• A chart of tests executed per second.
• A chart of the lines of code in the system.
• A chart of the age of the oldest open support request.
• A chart of non-story work.
• A chart of unavailable customer guesses.
• A chart of customer and programer interactions.

We have yet to do any serious experimentation with pairing yet, so we haven’t used charts for that. We have used charts for the team calendar and code coverage. We’ve also used charts for number of unit tests and to track tasks. Reading this post gave me the idea that I need to try doing a hand-drawn chart of our code coverage. I tend to use a stock Clover print-out and I only occassionally change it. I really like the idea of the team owning the chart and updating as well. This does happen with the calendar and the task board, but I think it could be useful for some of these other charts.

Matt Raible recently posted on web frameworks via another post by Tim O’Brien. His points were:

• The Struts project has gotten confused with the split between Struts Shale and Struts Action (Webwork) which has hurt adoption.
• “JSF continues to be the most over-hyped under-used framework in Javaland.”
• He’s yet to “meet an unhappy WebWork fan.”
• The learning curve on Tapestry is too high and it doesn’t maintain backwards compatibility.
• Spring MVC is fine, but Matt has found “WebWork much more pleasurable to work with.”
• Given the options you should go with Struts Action 2 (aka Webwork).

I’d be happy if WebWorks became the defacto web Java web framework as a successor to Struts, but unfortunately for now it’s still a wait and see game. In the meantime after about 9 months with JSF we continue to struggle with the six phase lifecycle and reliance on tooling. At least Ruby on Rails has forced the java community to wake up and smell the coffee.

Continuous Integration is a good thing.

Hmmm, it works on my machine.

— Developer

I paired up with a developer yesterday to hook a new project into the build box and Cruisecontrol. We expected a few wrinkles since this is the first project we’re hooking up to maven instead of ant. Should be just a simple **** tag and a few parameters.

We got past the parameter settings faster than expected, maybe 5 minutes on syntax errors like using

instead of

and forgetting to checkout the project manually for the first run. So after five minutes it’s up and running, but it starts failing soon after getting started.

So next we try debugging by just running the maven goals in the checked out codebase. Over and over again it pulls down about 10 dependent jars and then bails on the 11th. It’s not the same jar each time so the error isn’t obvious. Current theory is maybe the build box is being throttled by the proxy server, but it was late so we’ll get back to it in the morning. The build of course works on the developers machines.

Without hooking up the continuos integration early in the project we would have missed what may be a fairly subtle bug.

Yesterday I went through an install of Crucible on our development server. It runs on top of their Fisheye product. I’ve actually been waiting a long time to check it out.

Install and configuration wasn’t bad, maybe an hour and mostly to have Fisheye index part of our CVS repository. Just for an experiment I grabbed one random file and started a review. The workflow has a minimal number of stages which is just fine.

create –> approve –> review –> summarize –> close

I setup the review and added about 5 comments. The other reviewer who had only seen a quick demo of Crucible months ago then added a response to the 4 comments, fixed one issue and checked it back in. I went back in and summarized the change and closed the review.

The impressive part was with no real explanation, the whole review took about 30 minutes asynchronously. Even though this is a pretty early beta it’s mature enough for us to start using for our reviews. And since it’s so lightweight we’ll probably end up doing more reviews. When I went over and talked to the developer on the review he mentioned we might not even have to have a formal review meeting.

Overall it appears to be a good fit for us, even if it took about 2 years from it’s initial announcement to get to this stage.

Dave Nicolette posted a relevant question to my short post on Deconstructing Manager One on Ones.

Ed, IMO PM and Scrum Master are really two roles and team members relate to the individuals in those roles differently. Even so, most companies today do not explicitly staff a Scrum Master position at all. Instead, the PM is expected to play that role in addition to the usual PM duties. There seems to be a natural tension between relating to a team member as his/her manager and relating to him/her as a process facilitator / agile mentor. What have you found most challenging in trying to function in both roles simultaneously for the same teams?

– Dave Nicolette

ScrumMaster is probably an actual position only at a handful of small companies and startups. My experience has been the ScrumMaster is often a repurposed project manager. That can work really well. Real project management involves closing the gaps for a team to give them the best chance of success. Unfortunately for PMs steeped in PMI, Scrum may be a difficult transition. Currently of our four semi-official ScrumMasters three of them are PMs and one of them is a functional manager.

None of our PMs are 100% dedicated ScrumMasters, but two of the former PMs are about 80% dedicated to their projects which is almost as good as 100% dedicated. I’m the ScrumMaster on one project and I’m about 20% dedicated which really isn’t enough to be fully effective. Still you have to adjust to circumstances.

So on my current Scrum project where I serve as ScrumMaster we’re tasked with putting together a content heavy Intranet portal. At the start of the project there were eight developers on the project and all but two of them reported to me. Currently there are five developers on the project and only one of them report to me.

As the functional manager I have a lot more control of resource allocation. This has resulted in rolling off the seven developers onto other projects. The developers were able to explain to me that they were frustrated by the lack of actual development tasks. As new projects appeared I took the opportunity to roll them off. Had I been a normal PM repurposed as a ScrumMaster that frustration would have likely continued as I would have been less likely to spin them off.

My biggest challenge is devoting enough time to the project. I’m certain the project suffers to some extent from my lack of attention. I take too long to remove impediments, because I spend 80% of my time on other things like one-on-ones, meetings on future projects, and fire fighting on production issues. Today I finally scheduled the Sprint Review meeting with about one week left in the Sprint.

Another challenge is that I can never be sure my team members are completely honest with me. If I’m failing as a ScrumMaster to remove impediments quickly, I think it’s really hard to tell your manager the brutal truth.

Sub-optomizing is par for the course, but I hope to eventually work through the issue by training up a few more dedicated ScrumMasters from QA, development, or even the remaining PMs.