If your company has a development team, then the chances are that they are using “agile” development techniques. “Agile” can sometimes mean different things to different people, and so instead of delving into the nuts and bolts, let’s state some of the primary goals of agile development:

  1. Transparency: To ensure that everybody in the team knows what they – individually and as a team – are working toward.
  2. Output Not Process: To prioritise output (code) over bureaucracy or documentation.
  3. Speed: To increase the overall speed of delivery through better coordination and reduced re-work.
  4. Flexibility: To allow for a (limited) amount of flexibility that a more rigid approach may prevent.

One of the main challenges with development work is that the backlog of requirements often greatly exceeds the resources available. For example, FixSpec’s backlog often is typically in the 300-400 open items range! Such a large backlog can feel quite daunting from a prioritisation perspective, and correct delivery ordering becomes a challenge. A classic mistake is to attempt to bite off too much at once, which bloats releases, slows them down, and makes predicting delivery dates a nightmare. The risk of scope creep rises quickly, as colleagues argue for cramming in “just one more item” because they don’t know when the next release will hit.

The solution we’ve found is to reduce the cycle length significantly. FixSpec operates on a 4 x one-week release cycle, the goal of which is to deliver one production release every four weeks using a set pattern:

  • 2 x one week “strategic” sprints,
  • A one-week customer-driven sprint,
  • A final one-week bug sprint.

Each sprint has a clearly-defined “theme”, and we assemble a defined set of tasks of each type into the sprint scope. The use of themes allows us to ensure a healthy balance of quickly addressing customer items while allowing plenty of time for innovation-driven strategic items. Your set-up may be different, but this is what works for us.

Now, this might be interesting for developers, but this blog series is about efficiency in the onboarding process. So what’s the connection?

If we re-visit the selection of goals at the top of the article, you will probably agree that these should also be critical objectives for onboarding:

  1. Transparency: To ensure everybody what they – individually and as a team – are working toward, which also includes business stakeholders.
  2. Output Not Process: To prioritise output (customer live) over bureaucracy. Note: I’ve removed “documentation” here because – in our view – onboarders already under-document what they do.
  3. Speed: To increase the overall speed of delivery through better coordination and reduced re-work. For onboarding, this means more done in parallel, and reduced errors on both sides.
  4. Flexibility: To allow for flexibility that a more rigid approach may prevent, something of particular importance as firms often wait for customers or vendors to complete actions.

So if the objectives are the same, then we believe that adoption of a weekly, “sprint-inspired” cycle can boost onboarding efficiency and therefore accelerate connections.

Before you move your FIX tracker to a Kanban board, note that we are advocating a sprint-inspired approach and NOT the classic development version!

Here are some critical differences to bear in mind:

  1. Pre-defining a week of tasks will be near-impossible as your plans will almost certainly be knocked off course by factors outside your control, such as customer availability or readiness. Instead, consider what should be your prioritisation across projects and focus within them.
  2. Always look for parallel tasks. Time and again, we see firms adopt a strictly linear approach to onboarding when tasks can – and should – run conducted in parallel. So if you are stuck in one area, think hard about what else you can get working on.
  3. We are not advocating ideas such as “daily stand-ups” as these do not translate well to FIX onboarding. We would, however, highly recommend a weekly meeting – preferably on a Friday – where the whole team comes together to share updates, celebrate success and plan the following week. This meeting is a much-overlooked but vital source of efficiency and one we will return to in later posts.
  4. Plan for vacation time. One of the most common examples of onboarding delay cited when talking to firms is that a project stops dead while someone goes on holiday. Holidays are typically booked months in advance, and so there is no excuse for this to happen (unless you only have one onboarding team member!). It’s a clear sign of poor organisation and inefficiency, and that you should improve team communication and hand-overs.
  5. Allocate time for strategic items. Just as FixSpec allocate half of our time to strategic work, so should your team invest a significant proportion (25%-50%) into continual improvement. How about improving documentation to avoid answering the same question again and again? Or building template forms or emails to capture and send data more accurately?

Moving to a weekly cycle does not necessarily mean buying a fancy software package; in fact, trying to do this in the wrong software may make things worse. Focus on the process before the software. Start listing out tasks and activities that go into an onboard and think about how to implement and track them across the team and share progress.

Have you had a positive or negative experience when implementing an onboarding process? We’d love to hear your thoughts – get in touch at happytohelp@fixspec.com.