On a day to day basis when building a product it’s really helpful to be working towards some kind of objective or goal, to stay focused. How you think about these goals can make a big difference though. 

For us, a goal is a short-term focus on an incremental improvement, that can be reached from where we are now. A goal may or may not extend the capabilities of the system, i.e. it might add to the features available to the end user in achieving their goals, but also it might add value indirectly. Adding a capability makes a good goal, but sometimes there might be prerequisites or preparation that is needed before doing this – so that can also be a goal. It might be that a goal is completely non-technical, but improves the overall position in some other way, and that’s absolutely fine. If it moves you forwards, and you’re able to define it, and able to finish it, it’s a good candidate to be a goal.

We work together on achieving goals, because collaboration is crucial for so many reasons – that’s another topic though really! Having a goal “assigned” to a single person should be a really exceptional thing, it should be a long way away from “normal”! Pairing or mobbing should be the default way of working, bringing together skills and ideas to give the best results. We like to form temporary “squads” around each goal, who form, achieve an outcome, and then disband to re-form around a new goal every few days. This helps with other organisational challenges as well, like removing key-man dependencies where a single person can be a bottleneck, or the awfully named “bus-factor”, where losing a single member of the team can halt the whole team’s progress (incidentally we prefer “lottery factor”, where someone wins the lottery and jets off to a private island to live in luxury, which is a lot better than being run over by a bus).

We’re building Agile Labs in a very incremental way, and we’re using goals as a tool to guide us in doing this. It’s one of the first capabilities we added to the product, because we’re “eating the dogfood” and using our own product to build our product. For now, goals are fairly lightweight constructs, that keep track of who’s working together on achieving what outcome. The core workflow is:

  1. the team collaborate to identify what improvements could be made next
  2. the team select an improvement from these to form a goal
  3. the team self-select who will collaborate on this goal as a “squad”
  4. the squad capture notes about what they encounter on the way
  5. when the goal is finished the team collaborate to identify what improvements could be made next again

One of the aims of working in these short cycles is to get good at “finishing”. This means also getting good at identifying things that can be finished, and good at staying focused. It means applying a strict filter and staying lean. The aim isn’t to set off on a long meandering journey with no end in sight, because that can be devastating – we are looking for short, sharp well-defined incremental improvements. This is often quite an unfamiliar way of thinking to teams who are used to “building to spec” in a very linear fashion. It’s normal, and healthy, to build stepping stones along the way, and ideally these stepping stones can be released to a customer and still add value. You may well want to build a big fancy thing – in the end – but if you don’t ship anything until you’ve built everything, in its final form, then that’s a long time that the customer can’t use anything from you! Really thinking about setting goals that add immediate value is a crucial skill in delivering early and often!

Share This