Diary of a Software Manager

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

Lots of times, I get a requests from sales like:

Customer X wants a report that lists each external link a user clicks on

Seems pretty clear. I had this exact request recently and we started developing BEFORE talking to the customer. I said it would take a couple days of development time and since it was an important customer, we started developing right away.  When we sent an example report over, and the customer replied:

We said we wanted a report of advertisements each user clicks on and how long they spend watching videos

The first thing to recognize is that sales does not understand the technical details, nor should they take the time to do so. Their job is to sell, your job is to gather requirements and schedule the work, the developers job is to develop. You’re playing telephone here. We know this request has been relayed at least once from the customer to sales to you.

Even if it seems like a small task:

• get the client on the phone
• make sure the appropriate technical people are involved
• agree on the requirements
• send out an email detailing the requirements so everyone has them

We recently signed up for 37Signals Basecamp for managing projects. After about a month of use, here’s my thoughts:

Overall, it’s a great product. It’s certainly better than what we were doing before, which was throwing files in semi-random locations on our filesystem and attached to email threads. There’s no better way to lose requirements and miss functionality than to manage them in random email threads. It’s a great way to organize data, light and efficient.

Milestones – outstanding feature, everyone can see schedules and when things are going to be delivered. Keeps sales off my back.

Messages – again, you can track discussions and go back to them. You can even see them if you were not included on the original thread. Winner.

Files – versioned files are great for mockups, wireframes, design and others. Another winner.

Writeboards – At first, I hated these. No WYSIWYG editor kind of killed it for me. What they need is a link to the full textile markup to make it useful. Use this one and you’ll be a fan shortly. Requirements and functional design docs are best handled here. They are also versioned and it’s easy to see the changes.

TODO – Don’t confuse this with any sort of bug tracking or ticket management system. I’ve found it useful for posting modifications to wireframes, and action items from meetings.

What’s missing? Gantt charts. I’m still having trouble living without them but I’m trying. You can always attach them as a file but moving to Agile, you seem to not have these types of utilities.

I read this the other day and it hit a little too close to home. I distinctly remember passing through at least 3 levels (though I refuse to name them).

http://coderoom.wordpress.com/2010/03/19/5-stages-of-programmer-incompetence/

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



Graphic design has been on my mind lately, bear with me.

The absolute worst thing about being a designer has to be the constant feedback from clients who know very little about usability. Everyone thinks they know what good design is and very few understand the subtleties of HCI. Defending your opinions is very difficult in this case because UI design is something everyone can relate to.

I’m a big data guy. I love to see data instead of making assumptions about how much a certain feature is used or if a perceived fringe case is really a fringe case. Since everyone can relate to, and believe they know what a good UI is, it’s far more important for UI experts to have data to back up their opinions.

Imagine this:

Customer: I hate the stupid signup form, it feels like I’m in the third grade

Designer: This style of signup form increases conversion rates 25%-40%

That conversation ends quickly. If you are in UI design (freelance especially) you should become quite familiar with gathering statistics (and following blogs that publish them). Check out Luke W’s “Data Monday” posts for some examples:

• Data Monday: Social’s Growth on Mobile
• Data Monday: Usage of Mobile Devices
• Data Monday: How do People Share Content?
• Data Monday: Online Video Characteristics

I’ve already written about the dangers of retarding the graphic process by thinking about implementation. Another issue that I’ve become acutely aware of is how difficult this process can be if you don’t adhere to the 80% solution:

From Apple’s Human Interface Guidelines:

designing your software to meet the needs of at least 80 percent of your users. This type of design typically favors simpler, more elegant approaches to problems.

If your product is at all complicated, don’t get caught up in designing for the fringe cases. There should be a few people in the room during the initial design phase so you don’t get too caught up in the details, and you should remind everyone in the room about the 80% rule every time you get into the 20%.

Similarly, think about what Gall’s Law:

A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.

In part I, I spoke about some of the troubles of both too much and too little process. I’ve been in both environments and I’m sure there is a happy medium somewhere. I believe that happy medium depends on your organization. The organizational factors include size, personnel and what your current strengths and weaknesses.

I think for every organization, regardless of size, it’s true that you want a process that is as light as possible. There’s tons of waste with both heavy and light processes. At the base level, as you move along the scale from light to heavy process you see gains in quality and losses in development speed. From heavy to light, you sacrifice quality for speed of development.

No methodology is perfect, but I’ve found Agile/SCRUM to be the closest thing to it. As I said before, I think it’s important to  adjust your preferred methodology to suit your strengths and address your weaknesses. For instance, we have a brilliant software architect on staff. She’s the best engineer I’ve ever worked with  and I want her involved in the planning process for every single product we have. We typically have lots of different products being developed at the same time. Typically, you would invite the project development team to the story creation meetings, spring planning & review, daily standups, etc. Our process documentation mentions that she should be invited to the story creation and sprint planning meetings even if she’s not going to be developing on the project. Another adaptation we made was to hold a single daily standup meeting for all projects. It gives everyone in the organization a chance to hear about and give their insights to other projects.

Methodologies are used for a reason. They’ve been refined and re-refined over time to get the best possible output. Keep in mind though that during the refinement of these methodologies, generalizations are made about management, developers, stakeholders, etc. Pick a methodology, but adjust where you need to so you can take full advantage of your strengths.

Process is one of those words that many developers fear. I’ve developed in small and large environments with varying amounts of process.

I spent my first 7 years as a developer in one of the most process heavy environments imaginable. During an orientation session for our department (we were required to attend one annually along with ethics classes, Six Sigma training, varying other required training programs along with 40 hours classes on our own time), after the instructor went through the entire development cycle over the 8 hours of class time, a new developer asked “So when do we actually write code?” I wish it was as dumb a question as it sounded. The actual development of the code wasn’t really covered. What was covered in great detail were the various checkpoints along the way that were deemed necessary to produce quality software. In practice, 80% of your day was spent filling out forms and writing documents and scheduling meetings with stakeholders. The QA department never actually did any testing, they just sat with you during acceptance tests to make sure you had checked the various boxes deemed necessary.

When it came to actually developing code, most developers just completely ignored the UML diagrams developed in the preliminary and detailed design phases. Just having UML diagrams was enough for QA and they couldn’t really determine if they were actually used in the design at all because they were not technical at all. QA was just there to make sure all the boxes were checked and having a couple boxes with lines between them served as proof that those bits of the process were followed. There are few things more frustrating for an engineer than to watch such a large amount of inefficiency and waste run rampant in an organization. You either fooled yourself into thinking it was necessary or quit and found someplace to work. The more that I started to understand about software development, the more this drove me nuts and I eventually left.

When I left I moved to a far, far smaller company that had very little process. A QA department had just been introduced and in my first week I wrote as much code as I would in a month at my previous job. Of course, these changes were released without anyone testing them and rendered useless the product I was developing for. Most arguments I heard from management against introducing any process were of the “it will only slow us down” nature. I heard “I’m not interested in having a bug-free product, I’m interested in having a product I can demo and sell” more than once. Over the course of a year we slowly introduced a small amount of process that we called “agile” though we were only really doing the daily standup bits, not any of the other practices. What inevitably happened is we were introducing products really quickly which excited sales. We then spent the next 6 months trying to get them stable in the live environment that frustrated our customers and rendered new development efforts completely ineffective.

The right amount of process is different for every organization. I’ve heard arguments for jumping into development methodologies full-bore. Depending on your organization, you may be able to do that. For me, it seemed like a more gradual switch to the Agile methodology was the way to go. I don’t think any methodology is perfect and you should make an effort to notice what your organizational strengths are and play to them. The important thing is to do when introducing a process is to:

• Decide what things you are currently doing that are successful
• Define the current nagging problems you have that are hampering your development efforts
• Pick a methodology and move towards it in a way that allows you to use your current strengths (we chose Agile/SCRUM)

I’ll post a Part II soon that details how our organization moved toward a development process

I never recognized this as a problem until I got to management. You get a set of requirements, you write the code, you release it. One of my first tasks as a manager was to replace a solid UI developer. Since we had a fair amount of graphic design work and no graphic designers on staff I thought I could kill 2 birds with one stone and find someone with a solid javascript/jQuery/CSS background as well as some HCI and Photoshop skills. After 40 or so resumes I realized that this person does not exist. There’s a good reason for this – graphic designers should not have to worry about implementation. The best way to get an innovative UI is to work with a graphic designer andtake a ‘top-down’ approach to building your application, then hand it off to developers to code.

I learned this lesson the hard way when Apple announced the iPad. It was decided by our COO that we would push to get an app out on the iPad at launch, which gave us 60 days from the announcement. It was to be a revised version of our current iPhone applications with some added functionality. Because of the tight timeline, I hired a graphic design contractor and sat locked in a room with him for several days banging out a design. I was constantly tying his hands due to the tight development timeline and we eventually designed something that was slightly more styled than our current app, styled for the larger screen and used lots of new functionality provided by the iPad SDK. With two weeks to go I really felt like we could get this thing banged out for the iPad launch and as a semi-new manager, I felt that I could assert myself as someone who gets things done on a tight timeline.

My excitement however was dampened after we shared our mockups with upper management. It was deemed “Slightly more than a straight port of our current iPhone app that could be misconstrued as our best effort on an innovative iPad experience.” The decision was made to take a step back and do more graphic design work up front, sliding the schedule out by a month. This was hugely disappointing as I went from a guy who “gets things done” to a guy who creates bad UIs.

Here’s what I missed:

Share the designs early and often – I truly believe in the top-down approach, but missed this key factor. You need to get feedback quickly before you go off implementing something that everyone hates. In this case, I was so focused on what we *could* do with the tight timeline, I missed what we wanted to do. UI design is one of those things everyone has an opinion about and most of these opinions are terrible. I’ve found some ways to share design and get feedback that are more effective than others, but I’ll save that for another post.

Every project needs an owner – This owner should (most of the time) not be somebody in technology. Developers are constrained by what is possible and most elegant. I’m still constantly thinking about how a particular screen would be developed instead of the product vision. What I’ve learned to do is sit down with the project owner and UI designer during the creative process and keep my mouth shut about length of development and technical challenges unless it’s absolutely necessary.  If you’re interested in being creative and innovative, you need someone who is unrestrained by the technical challenges. My part is to keep them within a reasonable bound.

We follow the Agile (SCRUM) process and I’ve found that writing our user stories gets you the best blend of innovative UIs and fast development. There may be a few EPIC stories that can cause missed deadlines due to the less restricted creative process and it’s up to the product owner to decide whether to revisit those designs or push the schedule right.