Being on the inside

Working with a passionate team and being on a journey of incremental and occasional radical improvement on a relevant product is a Big Thing in the list of reasons why I love working at SynthaSite.

While I'm not (yet?) a developer on anything visible to the end-user, I am the first people outside of the development group to see what's been developed.

My responsibilities kick off directly after they've committed the code to the repository - I babysit the process of making clean builds and shepherding them onto local and remote staging servers, and finally onto live.  I obviously need to kick the tires on the build after deploying to make sure everything is fine before passing it on to QA and while doing that I get to see the new features.

Of course, there's little by way of surprise - everyone in the company hears about what the rest of the company is doing for the three weeks that make up our iterations.  But there's a difference between hearing about how cool it would be if we had widget toolbars and seeing how it makes the whole process much easier.

There's been some very exciting stuff happening in informal and formal meetings once or twice a week for the past month or so that I think will make the whole process of using SynthaSite more intuitive and effective.  We've just had a formal meeting where some mockups were debuted to most of the company, and it will head off to the design people, then the front-end developers, and then I'll be the first person outside that team to see it again, as we deploy it to staging for further comment.

One problem we're trying to solve is making this process more open - being able to tell people outside of the team - the whole company, our close friends, our business partners, and the general public - what we're working on, and get feedback.  There are obviously a number of factors to be considered when you do this.

One huge advantage of an agile development process is that one can be pretty ruthless about dropping things that can't be done well in time, or that turned out to be a lot more problematic than it is worth.  Saying we're doing X and then not ending up doing X is likely to be worse than never saying you're going to do X.  And it's really not worth losing the gains of the agile development process - nobody wants to be forced to do work rushed and after hours because someone announced something that can't reasonably be achieved.

On the other hand, talking about X has the potential for comments from the userbase and from opinionated other people, which may mean the difference between a somewhat nice feature and a great one.  It may spark interest from third parties via blog posts or getting on a social aggregator.

It's not a simple problem to solve, but hopefully we can find a way to mitigate most of the risk of being open.  Suggestions are, of course, very welcome.