At some point you have to deliver that last 20%

I think the hardest question here is managing delivery dates, and the simple answer to that is to have enough passionate people within your dev community that whatever comes up someone will be interested enough to deliver it ASAP.

We have rarely encountered a problematic situation like this in the past few years of the project, but before we had that critical mass, it was very very difficult.

• One fairly well focused project only
• Are working on pairs or communicating regularly
• Are producing something that is very techy oriented (I still haven’t been able to ‘deploy’ GitHub into my environment (even though I want to badly do it) so they are failing somewhere
• Their productivity (overall) might be pretty poor – while they might feel like they are doing loads, but in fact GitHub is not known for churning out significant innovations non-stop
• Their team is likely to be (very) small, so ah-hoc communication will do just fine

In short, when you add it all up, Github has an amazing developer-centric profile that is literally one in a million as far as real-world profitable businesses are concerned. It might make us feel good to enumerate the things that are holding our companies back from this kind of process, but I think it’s more productive to ask what we can learn from that process, and how can we utilize our individual company cultures to implement processes that are more agile than the “Agile” processes which have been developed, refined and packaged by consultants whose proven skillset by definition has been marketing their ideas rather than any provable development talent.

http://cdent.tumblr.com/post/404793442/choosing-to-know-implicit-goals

Release management? We don’t have “releases” in the traditional sense. When something is ready, it gets deployed. We might try to deploy a few things at once, but we don’t have some number with a deadline that says “on this date we’re releasing this version with features X, Y and Z.” I guess that’s “continuous deployment,” if you want to label it.

The funny thing is, as support, I’m on the opposite side of things here. I’ve come to accept that my primary job is two-fold. First, of course, I have to keep the customers happy. The things I can’t fix quickly, I have to track someone down to fix. That makes my secondary job harassing everyone to fix things they don’t want to deal with. When all else fails, I dive into the code and fix it myself. Having the freedom to take an afternoon to program is wonderful, and it really helps me not get burned out on the customer relations side of things.

The business must not have customers who are promised certain features by a certain date. Customers of every software company I’ve ever worked for have requested features that no developer wants to work on, but they pay the bills, so we worked on them anyway.

Honestly, I question the need need for such promises. We never ever give dates or timelines beyond “soon” to customers. There are things we honestly want to implement, or bugs that we are still tracking down, but we don’t know when those will be done. I believe that giving the customer a date is harmful in two ways here. First off, we don’t know if the date is even realistic, so there’s a good chance we’re lying to the customer. Telling them “yea I pulled that date out of my ass” only makes it worse. Second, imposing a deadline just adds stress to the developer for no good reason. The developer rushes to meet the deadline, bad code is made, things don’t go according to plan, deadlines are often missed. You’re only setting yourself and the user up for disappointment. We have never had a user upset because we wouldn’t give a timeframe yet, and I hope we never do.

Sure, some deadlines are unavoidable, but I think that keeping the deadlines restricted to bare necessity is a great thing. When you’re not spending times planning where things will go, you spend more time going there. In the end you’re going to reach the same place, but the trip is going to be much more enjoyable.