Rixiform Inc.

Development Practices

June 14th 2012

Here is an overview of my current default practices that I adapt to specific situations. I have tested each of them and found them to be more effective than alternative methods of organizing. The benefits of these practices take into account increased communication challenges (which grow at a rate of roughly the square of the number of team members). These practices are effective to a team size of 8 or 10, after which code base and team partitioning should be considered.

Simply stated, my goals are:

  • Create a predictable code generating organization
  • Establish effective lines of communication to other company departments
  • Continually reduce waste and improve efficiency
  • Retain good developers with a sustainable culture of excellence

Product Release Cycle

My weekly cadence of choice is this:

  • Weekly meeting with Product Manager, VP Engineering, and executives to plan main high level features to work on from the executive product road map. These high level features are then decomposed into stories in the backlog by the product manager. The backlog is then ordered.
  • Designs for stories in the backlog are gathered.
  • Weekly story estimation with the whole team for prioritized stories with designs. Missing or stories are created and improperly specified stories are modified. Some reprioritization may come out of this meeting. The next 2-3 weeks of stories should be estimated and have designs associated.
  • Daily development team stand up meeting at specific time at 9:10am. These keep everyone current on the state of the code, who to pair with, and what needs unblocking. This shouldn’t be a planning meeting. The backlog should already be organized. It’s crucial that by the time the features are worked on by the development team that they have designs and they are of small size (about a pair day or less). Not having designs or clearly specified small stories is one of the primary areas of developer waste.
  • Weekly retrospectives. Uncover key problems, reveal design issues, and create timely action items. Regularity is key to keep these short and relevant. The developers, product manager, and designer should be in these meetings.
  • New features are released when they are done or in scheduled release windows. Releases should always occur every 2 weeks or less. Stealth features are ideally included in releases with feature toggles for production to avoid integration costs and release blocks.

Executive Product Planning

I typically use Pivotal Tracker for tracking stories, chores, and features. Although Pivotal Tracker is pretty good for managing developer backlog, it isn’t great for road map, quarterly and monthly strategic planning. Strategic planning can be managed primarily outside of Tracker to avoid noise for developers or can be managed with giant placeholder stories (e.g. 50 points).

My latest preference is to use kanban swim lanes to track features of about 2-4 weeks in size:

  • Features progress through these phases: unstarted, design, development, validation, and done.
  • It’s useful to put limits on each swim lane’s queue size to increase focus and reveal blockage at stages in the flow to completion.
  • Validation criteria for these strategic features should be set before they are started to have a clear idea of why they are being built and if they satisfied their business value promise.

Releases are ideally as near term as possible to improve estimates, deliver business value quickly, and for improved decision making from feedback. But, I handle long term estimates that are greater than about a month in this way:

  • If a fixed deadlines is required (e.g. for for coordinating with large scale marketing campaigns or other company efforts), the release date is set by significantly padding the known scope. Tracker point estimates are very good at estimating the speed that the team works through known estimated problems. But, Tracker estimates never include inevitable feature and complexity discovery. For this reason release markers are frequently inaccurate and should be padded if a fixed release date is needed.
  • A great way of deciding the padding amount is to look at the historical scope expansion over time (both scope creep and feature discovery) and use this as the padding. Calculating scope velocity currently requires some work – second best is to use a fixed percentage.
  • Fixed date estimates should have designs before estimation. Having designs in advance of estimates reduces scope creep dramatically.


Different kinds of communication have their own places in the weekly iteration cadence:

  • Deciding which features to build should be discussed in strategy meetings with executives, the product manager, and the VP of Engineering.
  • Scope discovery and observations about cost should be discussed in the project planning meeting.
  • Daily stand ups should be focused on the days work and how to do it effectively.
  • Deep but actionable software design conversations should have their own focused meetings scoped to 1 hour with just developers in attendance. These meeting should be focused on specific implementation details and avoid unreconcilable debate caused by philosophical abstraction.
  • Questions about general development practices, process improvements, and group dynamics should be taken up in the retrospective; it’s important the developers, product manager, and designers should attend the retro. The concrete output of the retro typically includes chores, technical standard items, process improvements, and discovered scope for the product manager.
  • At times other than these, developers should focus on writing software. Communication about writing code for specific stories occurs primarily in pairs. If there’s not enough knowledge in the pair, a new developer should be swapped into the pair or a short group conversation occurs. If a longer conversation starts outside of its appropriate time then everyone is empowered to say “let’s talk about this in the retro” or “bring up the change in cost in the planning and estimation meeting”, etc.

Core Practices

Here are the core practices I advocate for productively writing high quality software:

  • The team consists of the following members: developers, a product manager, and a designer. These roles create clear product priorities and UX design for efficient development. Not having any of these roles creates significant waste through blocks, sub-optimal cost estimates, or rework. These should be dedicated roles. For maximum efficiency, a CEO should not be tasked as product manager, developers should not proxy as the designer, etc.
  • Collocated work force. Blocks are removed in minutes instead of hours or days. Everyone should be on site unless they are sick in which case they work from home to keep from getting others sick.
  • Write quality code for faster extensibility, higher moral, better user experience, and improved development predictability.
  • Test driven development. Benefits: high code quality, minimal manual testing, clearly thought out solutions, refactorable, extensible, maintainable, self documenting.
  • Continuous integration server with a green build. This is the replacement for a large testing team. It should give feedback on which tests are broken ideally within 10 minutes. A reasonable heuristic of code health is how long the build is red for. Intermittent spurious test failures should be stabilized or removed from the CI build.
  • Pair programming as the default. It is better to make the discipline of pairing the required default because this practice can easily drift into soloing on undisciplined teams. Occasional soloing due to having an odd number of programmers is OK. Reading lots of documentation is better done alone or maybe even in the evening. CSS and HTML seem to some to be ‘simple’ things better for soloing. Actually, it is good to pair on these because CSS quickly turns to a ball of non reusable mud without proper factoring into a style guide; similarly, an html page is a complex data structure that requires thought when used by Javascript. The benefits of pairing include:

    • removing knowledge related blocks quickly
    • knowledge sharing on an ever changing code base
    • improving developer skills
    • high quality code
    • mutual enforcement of coding conventions
    • continuous review
    • easy transfer of knowledge for joining and leaving team members
    • focusing effort on the story
    • last but not least developers who pair aren’t surfing the web.
  • Fixed schedule 9:00 – 6:00pm with a one hour lunch from 12:30 – 1:30. Having a cadence means everyone is at meetings, pair programming is synchronized, blocks are removed quickly, and everyone knows when they need to be at their best and when they can rest. The trade off is discipline in exchange for a predictable schedule for time off. This schedule leads to an energized work force that solves problems well, has an elevated moral, and good developer retention. I advocate not having developers work overtime. Their code is usually worse because it is written without a pair when tired; this code is frequently rewritten quickly or becomes technical debt.