Some tips for dealing with dpp May 29, 2013

Some reminders

Lots of weird people coming out of the woodwork this week.

I'm writing this post generically, but also as something to send to people who think that because I do stuff, I'm going to do stuff for them if they pester me about it.

So…

Please don't send me private email about Lift or Lift-related bugs or Lift support or Lift scheduling or anything like that. I'm not Lift.

There's a Lift community page that tells you how to get Lift-related support. Got a question? Ask it on the mailing list. Yes, if you've got a production web site using Lift and there's a bug that's making deployment difficult, I will prioritize that up (I read almost every post on the Lift list)… but it's up to you to discuss the issue on the Lift mailing list.

The above also goes for Twitter. I'm not here to answer your questions on Twitter… of via IM… or via other mechanisms.

Just like I don't ask you to come walk Archer, please don't ask me privately to do stuff for you.

Yes… there are exceptions. If there's a security vulnerability in Lift, you can contact me directly.

If we know each other (as in, we've had meals together, we regularly exchange email, we met at Monktoberfest, etc.) then, yes, ping me. But if you don't think I'd buy you a beer, please don't think I'll answer your Lift related question if you ask it outside the Lift mailing list.

Also, nagging me about stuff generally makes me ignore you more. Bumping questions will get me to permanently ignore them. You know… we're all adults here and acting like a 5 year old and being loud to get attention generally provokes the opposite with me.

Working Together

If we're working together on something (paid or unpaid)… then let's show respect for each other.

Tickets & Mailing Lists

Let's discuss stuff in public (for the project) forums.

Let's use ticketing systems to track issues… that way we can all track the progress of things.

Tickets are a discussion and the discussion should start out with a statement that is some variant of "when I do X, the system responds with Y, but I expect it to respond with Z." That way we can discuss the system's behavior and whether there's a problem or if it's expected (maybe not desired behavior.)

Tickets should include enough information to reproduce the issue including browser types, URLs, etc. Even if the information is a repeat of what's been entered in 5 other tickets, capturing the information is helpful to the person working on the ticket and super-valuable to folks looking at the history of the project or coming up to speed on the project.

Deadlines & Commitments

If you've got a deadline or a commitment, put it on the table. Working toward the deadline is something we can do together. We can do ticket prioritization. We can have a few extra check-in sessions in the weeks leading up to the deadline. I can make sure I have some extra hours around the deadline in case there's a final push.

But not every day is a deadline. Not every issue is a make or break.

In fact, for the most part, keeping a nice, sustainable cadence will lead to better results than a series of frantic pushes. Keep the pace moderate. Keep the team well rested and humming along. You'll be able to measure the results by looking at the ticket velocity and make reasonable predictions of what the project will look like 2 weeks, 4 weeks, 8 weeks out. And if we're using a ticketing system like GitHub's, we can all see how fast stuff gets closed and how well the team is doing.

Give an overview

Agile is great, but we also need to see where we are going. Having a 2 page project overview and a set of key user stories/epics help everyone on the team understand where the project is going and ultimately what success means.

We're skilled professionals. Having a shared understanding of what success means is important. Even as a hired gun, I want to come away from a project feeling that it was a success. Yes, I do stuff for money… but more importantly, I do stuff so that everyone succeeds. Understanding what success means makes it more exciting for me to hit the keyboard and crank excellent stuff out.

Bouncing around from micro-issue to micro-issue doesn't help anyone… and the micro-issue driven systems tend to be fragile and brittle. Issues/tickets should generally be user-focused and understandable in the context of the overview.

That is not to say things don't change. They do. And when they do, give everyone on the team a heads up of what changed and why.

Communication

It's all about the constant, searchable, low cost communication. That's what drives open source projects. It's what drives GitHub. It is super-helpful to have it drive your project. Keep it short. Keep it regular. Keep it (mostly) in searchable places. Keep it respectful (we are all pulling for the same goal.)

Not all Whine… lots of Roses

I've got two paying projects going right now that are particularly awesome.

One is a solo project. The client communicates well. The code flows. The feedback flows. It's generally unremarkable… which makes me happy. I get paid to write code that folks find useful. What could be better?

What could be better is having a team that's awesome.

Another one of my paying projects is with a geographically distributed team (San Francisco, New York, UK, and Sydney). The team communicates really well. We all know what's up with each other. The project is driving by a couple of simple prioritized user story documents (they are written in Markdown and the non-technical folks on the team edit the Markdown via the GitHub interface.) The tasks are driving by GitHub tickets and the discussion about the tickets is visible to everyone on the project. There are weekly check-in calls with the client, but most of the project is done via tickets and check-ins.

It's amazing how much can be done with such a simple workflow. But when the client is oriented to getting stuff done, and we can demonstrate that stuff gets done when the client files tickets, the incentives are all aligned.

These two projects as well at Lift and a bunch of stuff that's more open reinforces that it's easy when it's done right and simple.

That is all

###