Iterate, POFL & Ragu: How to move fast and leave no idea behind
Starting a new series of articles on Guevara’s approach, culture and the challenges we face, engineering maestro Laurence Holmes describes how to work methodically at speed.
Guevara is a startup. As an engineering team we move quickly to respond to people’s feedback, navigate technical debt, and build a product people love.
We’re lucky to have a team with creative, engaged minds. Those minds are always thinking up new ideas, be it adopting new technology, implementing new design, or restructuring our products. It’s a nice problem to have, but we’re also crushed for time. So how do we plan, prioritise and track the ideas we have? And what do we do with those which we simply don’t have time to implement?
Our team have various experience with an array of project management tools including JIRA and Kanban. We tried adopting some of these tools, and Pivotal Tracker was the closest to satisfying our needs. We loved the theory of days and weeks being automatically filled, and it seemed to fit in nicely with our agile approach. But Pivotal just couldn’t keep up. As the needs of the business changed and we gathered more information from the customer, our long term plan was constantly being adjusted. With an unpredictable future it would take too much time to keep Pivotal up to date. We needed a new solution.
Looking at our available options, the tradeoff was the classic bespoke versus off-the-shelf question: adoption cost and the restrictions inherent in any fixed framework against the upside of reduced manual effort. An enterprise solution didn’t seem appropriate for a startup, and we were confident we could create a bespoke tool in a light manner. So that’s what we did. We called it the Product Iteration Plan (PIP!).
Our Product Iteration Plan is a dynamic way to monitor tasks, resources, and progress (it can be used for product development, but works equally well at improving your ragu recipe).
At the start of each month, we spec out the large pieces of development activity which are high priorities for the coming month. These typically include new greenfield product pieces, bug fix cycles, research and technical debt resolution, in varying quantities. What’s crucial is that this is a cross-functional meeting, with input from all parties in the company, helping us maximise collaboration. We’ll typically have 6–8 of these projects. After the meeting, the projects go on the wall so everyone can keep track of where we’re heading with our product.
So what to do when a task turns out to be deceptively complicated? Or a new critical requirement emerges which requires an agile repurposing?
POFL (Put Off For Later — rhymes with ‘waffle’), in concrete terms is a listing of ideas, classified by type, with descriptions, notes around impact, priorities and team member(s) associated.
However, this is not a product backlog. It exists outside the normal agile process we engage in as a technology company. This allows us to focus on the key critical goals for the business — developing MVP in an agile way — without negating the need to monitor technical debt, new tools and new ideas.
No ideas are left by the wayside.
What happens once an idea is POFL’d? Depending on type, the individual items (e.g. bugs related to a component) may be bundled into a project, when priority becomes high. We can then update our current month’s plan with this new project, or schedule it for the next month, as we see necessary. This maximises efficiency too — one team member can fix four related bugs quicker than four in isolation via a drip-feed. Sometimes a POFL may be dropped completely due to a superseding idea, subsequent learnings, or often in the case of a bug related to a component we remove entirely.
We arrived at this solution organically, and we’ve found it’s gelled exceptionally well with our company’s culture and goals. It’s MVP, like our approach to product. We learn it’s shortcomings, and adapt as necessary, without being bound to a heavyweight third-party implementation. We simply don’t have the time to wait weeks for a change request to get approved — we need tools that work now.
JP (our Head of Product) sums it up best:
We encourage you to try out these concepts, and feedback your learnings. We’re iterating, tweaking and improving all the time, and we’d like to share that with you. Next, we’d like to incorporate velocity tracking to improve our estimations and performance monitoring. We’re also road-testing detailed definition of desired outcomes and measurable KPIs at the planning stage, to better track the value everything we build adds for our users.
We also expect the perfect ragu recipe to be completed by October 2015. Our modelling suggests this will be too valuable to share openly, but we may invite you round to try some if you ask nicely.
Laurence Holmes — Product Team