Building Software is Amazing

For the past 6 months I’ve had the opportunity to work on one of the best projects of my career.  This thing has all the buzzwords: big data, social media monitoring, semantic analysis, kanban, ruby on rails, github, distributed teams, expertsourcing, skype video, lean, pragmatic, platform, you name it.  The team is brilliant and highly skilled in their areas of expertise (rails programming, UI/UX development, architecture).  Each member cares deeply about their craft and is highly passionate about our project.  We argue, we collaborate on great ideas, and all stress the difference between opinions and facts.

This quick reflection just reminds me that building software is amazing.  It’s not writing up exhausting requirements that no one cares about, it’s not outsourcing all of your technology to a vendor, it’s not making stupid decisions that leads to wasting money and not shipping product.  Building software is about being creative, respecting the craft and the team and adapting quickly to a changing environment while relying on tried and true principles.  I can’t wait to see what shows up in the next “git pull”.

Creating Project Rhythm by following TechStars and Y Combinator’s lead

I admire TechStars (wearing my TechStars t-shirt proudly) and have been a reader of Paul Graham’s blog for years.  Both programs have created a vibe and atmosphere that churn out great work and provide endless motivation and contributions to their surrounding tech communities.

Reading the latest post from Paul Graham titled “What happens at Y Combinator” highlighted the relationship between schedule and rhythm and the role this plays in projects.  Both the Y Combinator and TechStars programs are roughly 3 months long, similar to the quarterly Agile Release schedule that we use.  The rigid schedule both programs use inspires and creates massive pressure for teams to work hard and deliver.

Because teams in TechStars and Y Combinator live and breathe their projects they are able to devote almost all of their time to it.  The rhythm these programs develop include dinners, hackathons, presenting at local tech meetups and renting out conference spaces to host big demos.  While a typical team can’t take things to that level, there are lessons to be learned.

Here’s the schedule I am using for our new project:

Product Summit – beginning of Quarter
A 2-3 day onsite working session full of multiple topics (business and technical) with a tight agenda and after work dinners.  The goal of this effort is to have a general gameplan for the upcoming quarter for the whole project, not just development.  In a distributed team like ours, it’s a rare chance for the entire team to spend time together.

9 Weeks

Monday
9a – Project Management conference call – a weekly update of anything to do with the project including budgets, contracts, etc
9:30a – Daily Standup

Tuesday
9:30a – Daily Standup
10a – Weekly dev team meeting – a weekly meeting to discuss technical details of upcoming work, review Kanban Board and Release Burndown

Wednesday
9:30a – Daily Standup

Thursday
9:30a – Daily Standup
Noon – Weekly demo to Stakeholders
1p – Weekly call with a Customer

Release retrospective – end of Quarter
A 2 hour retrospective answering questions like “What did we accomplish?”, “What was our Velocity” and “What can we change in the next Release?”

Summary
The rhythm I am trying to build for this project begins with a big kick off because lots of things need to be figured out up front and agreed on, then a strict weekly schedule to pull everyone along when things start to fall off the rails, then a decompression and review to let the dust settle. The schedule I have designed is nowhere near as cool as TechStars or Y Combinator but it’s a step in the right direction (I hope).

Related Articles:

The Rhythms of Life on Feld.com

Being more Productive on ktinboulder.com

TechStars

Operational Processes

Joel on Software writes a great article about Starbucks and how they have developed customer services “systems” and “procedures” that are failing.

If you’re planning to expand your business to a certain scale, you must first establish procedures and build systems to get predictable outcomes so that your employees can produce decent results even when they’re not having a great day.”

This is extremely applicable to my current role.  The nature of working with Clients as your customers mixes different personalities and can create frustration somedays.  It is so important to have good work processes in place so you can turn off your email, let the frustrations go and continue to crank on the work that needs to be accomplished.  Getting Things Done is the easiest way to satisfy a Client as a customer.