5 Tips for Velocity in a Product Engineering Team

Deadlines loom, conversion metrics tick, marketing teams hustle and commercial pressures build behind the product team — no less acutely anywhere else than in a digital product team. Priorities and turn around times are discussed in Sprints of 10 days and naturally, smooth operation over these short bursts is highly critical.

This article shares a snapshot of some of our experience in optimising our approach to SCRUM delivery (rather than development tools) and here are a few recent modifications we focused on to maximize efficiency.

1) Remove project initiation barriers

Foundations of a Fortress

There’s nothing quite like a thorough Sprint 0 to hit the ground running and while a great deal of de-risking, configuring and wiring-up test frameworks is one thing — we’ve gone a step further. What tasks usually found in Sprint 0 can wemake repeatable, leaving a leaner Sprint 0, so a shorter project initiation time or more time to de-risk the project further?

  1. Migration to Bitbucket — a subtle one but unlimited repositories removed a commercial barrier of adding repositories for new projects without incurring a fee. However little that fee was it still went through an authorization process.
  2. Cloning Jenkins — using a build tool to configure your build tool? Yup! We’re implemented automation of automation allowing us to lower the overhead of setting up a new continuous integration project.
  3. Vagrant + Docker — the now widely used Vagrant has enabled us to have multiple machines but the introduction of Docker means that not everyone needs 1TB of memory to run their VMs.

So the upside? Starting a new project can now be done in hours when using our methodology of preferred and consistent product platforms.

2) Not being afraid of micro-services

Breaking out abstract concerned into a separate work-stream

Micro-services are well publicized (SOA MKII?) to help minimize dependencies within a monolithic software code base. By breaking out — say — an integration broker or recommendation engine then this can sit with another small team. The reduction of the team size reduces communication overhead and allows a team to run autonomously.

Our initial fear was that it may create a bunch of dependencies and DevOps overhead but through using technologies like Docker to run deployments and templated containers, these fears were instantly negated.

Parallelisation of a product road map with a technology stack that is oriented towards switch service-oriented — modern frameworks such as PlayFramework (Scala) or Symfony2 (PHP).

3) Requirements: A good story is worth telling

Stories should have detailed narrative with technical implementation (see previous post about user stories).

A good thought-out requirement means less confusion from the team right the way through, from estimation to task break-out, writing the code and finally through to authoring acceptance tests.

  1. User Story
  2. Technical implementation notes
  3. Acceptance criteria (written in a BDD style)
  4. Links to designs and assets

Understanding first, opens the door to a successful implementation. Our learning here was to move to proper BDD-style acceptance criteria — this coincided with our test coverage for acceptance tests rocketing but had a profound effect (perhaps in conjunction with the tests) on the amount of rework coming back.

Hello there velocity! ;)

4) Demo Days — Actually Do Them

In the past, a “demo day” was a deadline for project management to ensure UAT passed acceptance and for a retrospective to discuss how the Sprint went. Did we all actually demo the software, kick back and objectively view the work? No, UAT did that, right?

By running an actual demo day with the whole team around the product, running through a use case (amalgamated from acceptance criteria from stories in the Sprint) and openly discussing with investors, product owners, stakeholders and engineering teams, we have found ownership of the delivery quality being spread more widely.

5) Appointed framework oracles: open thy brains

For us, an essential organisational shift was to encourage teams to break out and arrange code reviews outside of their team. A benefit of being a multi-project environment and having an awesome team (kudos Byngers!) is that knowledge is located within the business and should be accessed to unlock and unblock bizarre framework issues.

We found that one of the major factors affecting our velocity in the past, were the times where engineers had issues with libraries or frameworks behaving unexpectedly or dying without errors. Having a mechanism to bring someone from another team to investigate not only improves training but unblocks the issue. In the meantime, encouraging engineers to switch branches also helps avoid lost time.

For us this was mostly dealt with with by our senior delivery team and to limit the amount of story points a senior engineer took on in a day to provide more time for helping others.

So to summarize..

Many of these experiences we’ve had are perhaps already recommended and probably known about — undoubtedly all software engineering teams face similar challenges. These were things that visibly made a difference to our output and we hope they may help to steer you on the path to velocity.

  • Planned preparation with optimized Sprint 0
  • Breaking the problem down with micro-services
  • Understanding the project better
  • Accountability for the whole team with demo days
  • Sharing knowledge with framework gurus

About the Authors

Byng is a tech consultancy based in London and Leeds, with a team of full stack software engineers and consultants, specialising in web & mobile. We develop innovative digital platforms for business.

http://www.byng.co

A single golf clap? Or a long standing ovation?

By clapping more or less, you can signal to us which stories really stand out.