The RGS Product Development System

Assumptions

• Team Composition: One full stack developer, one PM
• PM = Role is primarily ops, management, QA - servant mindset. Someone who has time & doesn’t hate the nitty gritty work or see it as above them.

Structure

• Engineering: Broken down into one-week sprints, generally consisting of at least one Boulder and one day of Rocks and Pebbles (usually Friday). See Ticket Categories
• Rollout & Handover: Every second Monday: Large changes go live, release notes get circulated, documentation gets published, zoom meeting or async loom with client to explain the changes.
• Schedule

• The best time to start writing the following week’s tickets is half way through the previous week.
• If the developer is shipping 2 boulders and 2 sets of smaller changes in a 2 week period, there will generally be quite a lot of changes. We can ship each ticket as it’s completed, but it’s usually more efficient to batch them together - it’s also easier to hand off a batch of changes to a client than to do them one by one.
• The goal should be to have everything ready to go on Friday evening, but not to deploy it until Monday morning.
• In cases where there is a senior/staff engineer involved, it’s also a good idea to check in with them on the thursday or friday before shipping - are there any large changes being made that need additional attention/review/testing?
• The The Live Development Environment means the PM can (and should) be staying abreast of all the work as it’s happening, and creating new tickets as they spot things that need attention.

Principles

• Fix schedule, flex scope
• “Work expands to fill the available time”, so start with the time period, not the work
• “Momentum, momentum, momentum”
• Ruthlessly remove blockers. “I’m waiting on X” should be very rare.
• The final 30% of the work can often take just as long as the first 70%. Different approaches should be applied at different phases. Get the first 70% out fast and don’t sweat the details, but don’t neglect the polish on the final 30%.
• Devs: Write the code you can write. If you’re waiting on database access, build the view layer and wire it up later. If you’re waiting on the copy, use filler until it comes through.

PM’s responsibilities

• Ensuring this system is followed.
• Collecting all of the relevant information (designs, specs, etc) from the client.
• Breaking the high level requirements down into smaller tickets, ensuring tickets contain enough information for the developer to complete them.
• Staying ahead of the development pace (having the following week’s work ready ahead of time).
• Ensuring all work has been tested, works, and is of a high standard, pre and post deployment
• Writing and sending release updates. See Update Driven Project Management