Making Things Fun Again

Every so often, work just seems like, well just work. At that point motivation goes down the tubes and you’re just slogging through. Drawn out architecture discussions on the benefits of paranoid security got me to a very un-fun state. Bad enough when you’re a solo developer, but even worse if you’re a software development manager and your mood is likely to rub off on the whole team.

Maybe it’s time to inject some fun courtesy of some Cruisecontrol powered lava lamps.

Ruby Coding Styles

I’ve been absorbing standard Ruby style by osmosis, but I did finally stumble across an actual style guide including one specific to Rails. We use The Elements of Java Style for our java code at the office and it works pretty well. I like the comment:

There is no place in Ruby where lowerCamelCase is ever used.

I’m guessing that was specifically for us Java guys. Of course it’s a wiki page so that comment may not survive forever.

Agile Methodology Context

In a response to my post on Adopting Agile as the Default Methodology Lidor Wyssocky makes the point that:

The methodology wars are 90% psychological. If we would just stop using the names of one methodology or another in our discussions, most of our disagreements will disappear. At the end of the day, it all comes down to common sense.

It’s a relevant point and one I tend to get caught up in. The point is really to adjust the process to fit the needs of the team and the context while making forward progress.

I suppose my passion for arguing hard for the word Agile or Scrum at my current company is that I fear returning to our old painfully familiar waterfall process that fit very few projects. It may be a bit irrational, but I just dread doing piles of needless and nearly worthless documentation. I dread even more the huge lags between waiting for a requirements document and actually being allowed to move forward. I’ve been stopped multiple times in the past for merely moving forward with the project and not following “the process.”

Anyway on the current critical project with a two month timeline things have evolved. I think the product owners and the project managers assume we’re still doing waterfall, but an enterprising tester on the project felt the need to step up and get the project moving. So today he held a meeting with everyone but the product owners and the PM to go through what we know about the requirements so we can:

  • Modify our regression tests.
  • Get started on the coding which is already underway.
  • Get a list of questions together for the business to answer.

This is really one of the best possible outcomes since a regular team member was willing to lead the way instead of waiting to go over the waterfall in a barrel.

People will often succeed in spite of the process.

Adopting Agile as the Default Methodology

Having been officially adopting Agile from the top down approach for about 8 months now I was really surprised by a recent project kickoff meeting.

I just assumed that we’d be using our official Agile methodology on this high profile project. Some assumptions I made were:

  • The two product owners, business analyst, project manager (ScrumMaster), developers, and QA tester all have prior experience on an Agile project.
  • We have two months to deliver on the project with no wiggle room because it’s a regulatory project, so if we fall back to our old waterfall style we’ll likely fail.
  • All of our official piloted agile projects have been successful ventures so far and viewed that way by their product owners.

I turned out to be on a different page then the rest of the room. There idea appeared to be that we would run this as a traditional project. Traditional for us means a sort of strange version of waterfall, but waterfall none-the-less. The problem is we could easily be weeks just getting the requirements in place in lengthy documents no one wants to read. (The system shall …)

I thought there was no way we’d allow for this, but it appears to be exactly what we’re going to do by default. So the question is how to fight this perception that Agile isn’t our default.

I fear that despite the pilot projects, many of the participants haven’t understood how powerful Agile is for just this sort of high profile, short deadline project. We’ve adopted pretty much vanilla Scrum up to this point so maybe they thought with 30 day iterations Scrum just couldn’t work. Given the timeframe I’d say we should be using maybe 1 or 2 week iterations. A truly lightweight process might be just a product backlog, a short planning meeting every week, daily standups and a short 30 minute review of the progress at the end of the week.

I’m not giving up though, maybe I can convince the players to hold an impromptu planning meeting tomorrow.

Forced Context Switching

Sometimes, despite your best efforts you get forced to stretch a developer across more than one project. Johanna Rothman posted on this recently arguing that many managers just don’t get the difficulties of asking their people to multi-task. Sometime, I don’t really get a choice.

I’m very familiar with the pains of context switching since as a manager it’s often a part of my world. My day continuously involves getting pulled in to help review a prototype for a developer or talk a system admin giving us read access to log files. Since my job is to make my people more effective I can’t complain too much when I get interrupted.

Still things come up. Business owners request certain resources they emotionally feel are the only safe choice for a high profile project. As a development manager part of your responsibility is to work with your customers. If they are so attached to this opinion that you are unable to sway them, you’re forced to give them the resource they ask for even if it’s just to appear at meetings and help a bit with the coding.

Long term the customer should be convinced that the other developer who’s doing the bulk of the coding is perfectly capable of handling their high profile projects. Still in the short term you’re forced to split one of your developers across contexts and damage their own productivity. I haven’t found a better way to handle it, and in many ways I doubt I ever will.