Diary of a Software Manager

I work for a company who provides software products and services, but is not a software company. Historically, the methodology we follow is based on sales selling whatever they possibly can and development rapidly developing whatever “it” is. There is typically no thought given to what we should be focusing on. One of the fundamentals of the agile methodology is the idea of a constantly prioritized backlog. This idea is easy to lose sight of in small companies. Profits might be thin and it’s tempting to build whatever a customer will pay for.

When I took over the group I manage, every person in the company was welcome to visit any developer on the team and request that their top priority were completed. To help alleviate constant interruptions developers had to deal with, I started handling all requests. At some point, it occurred to me that I might not be the best person to set the priorities of the company. I’d like to have a say, but not the whole say. The more I read about agile, the more it made sense to have a product owner.

Ideally, the backlog would constantly be prioritized and before every sprint, we’d just grab the first N number of items off the stack to work on. This is a simple and brilliant concept. It keeps developers developing without constant interruption and ensures the most important features are always worked on.

I’m still struggling with changing the culture to mirror that of a software company instead of a machine shop where we can just flip a switch and have our developer machines output a different widget. Hopefully we get there and we get to see the results of implementing such a noble goal as to institute an ordered backlog.

Good read from Luke Wroblewski (as always) about 37signals design process. I already talked about how enamored I am with Rework. The thing that strikes me about Luke’s post, is how feedback is handled. Sorting through feedback is one of my most important jobs as a manager. You get lots of ideas about how cool “this feature” might be. It’s the manager or designers job to figure out where users are having problems and fix them, not to implement every single feature that is requested.

One thing I haven’t been able to wrap my head around since going Agile is how to give estimates when asked. And you will be asked. Sales likely isn’t going to care about your development methodology or it’s principles. They are under pressure from existing or potential customers who want a date attached to projects.

But doesn’t the whole Agile thing teach us that you can’t estimate with any accuracy until you break down all the work into stories and TODOs? You obviously can’t waste your teams time breaking down every single request you get. They would never develop anything. So what do you say to the sales folks? We don’t estimate until much later in the process? See how far that gets you.

I read an interesting post about this topic recently. The argument here is that since your estimates get more accurate as you break the work down into stories and tasks, you need a  scale for estimates. The suggested scale looks like so (Certainty level – Estimate Technique):

1. Agile Task – Hours
2. Agile Story – Story Points
3. Agile Epic/Theme – T-Shirt Sizes

So for those roadmap items you’re forced to give estimates for, use the T-Shirt scale (or a similar one). The explanation I attached was:

• S = hours
• M = days
• L = weeks
• XL = months

My company has been using JIRA for quite some time to track bugs and plan features. As we embrace Agile/SCRUM, it’s become a lot of work to fit such a light process into a heavy product like JIRA. I initially attempted to trim down the required fields for a lot of the issue types but that proved futile as it still took around 45 seconds to enter a simple TODO subtask for a user story. In order to make this effective while we created and estimated stories in a meeting, I figured I needed something on the order of 5 seconds. Thus stared the quest for a new tracking system. Haven’t made the choice yet but I thought I’d share my notes.

Requirements

• Agile “Board” like mechanism for visualizing sprints, sprint backlog, product backlog, etc (or something similarly trivial)
• Electronic – we’re working with contractors and other off-siters and web cams don’t seem like a great idea
• User stories with one-line “TODO” lists attached
• Ability to add or attach test cases to stories
• Ties into or allows export from JIRA (not sure if this is a requirement or not)
• Burndown charts
• Velocity tracking

Potential pitfalls

• We currently have more of a use for JIRA than just development projects, don’t want to pay for two products that do similar things
• We have a huge backlog of tickets in JIRA already and moving them to a new system is likely to suck

Pivotal Tracker

Pros

• Easy to use after you understand it (slight learning curve)
• Really fast & all logged in users see updates immediately
• Hits all of our requirements and lets you export from JIRA or tie into it via APIs
• Free (unlimited users/projects)
• Tracks velocity, can use Fibonacci numbers as we do now

Cons

• Wants to do a lot of things for you like manage iterations based on velocity. You can manually manage the current sprint but the backlog is always auto-managed (more of an annoyance than a huge problem)
• Would have to manage test cases via attachments (unless I’m missing something)
• Not very customizable, TODOs always display near the bottom of a story

Overall Impression
Best option after surveying a few free alternatives. Not perfect but a lot easier than what we’re doing currently.

Greenhopper

Pros

• Plugin for JIRA, don’t have to move tickets
• Agile board mechanism
• Easy to create TODOs and move cards between columns during a sprint, and drag and drop to a release during planning is easy
• Super customizable
• Tracks velocity & burndown

Cons

• Requires a bit more configuration up front than I’d care to do
• Really customizable, but also somewhat confusing (welcome to JIRA)

Overall Impression
Solid product, feels a bit heavy but probably not bad once the initial setup is done

Rally

Pros

• Can potentially handle all phases of the product lifecycle

Cons

• Cost prohibitive & perhaps too big for our needs

Overall Impression
Never got a demo as the cost was prohibitive

Scrumy

Pros

• Trivial to use, board is laid out in an obvious manner (no learning curve)
• Super lightweight
• Really inexpensive ($7 per month)

Cons

• Burndown charts based on time not story points
• No velocity tracking
• No JIRA integration or import

Overall Impression
Nice product, lack of required features makes it unusable

Also Ran

SkinnyBoard
Banana Scrum
Scrum Pad
Acunote
Target Process
Ice Scrum