What the heck is all this about anyway?

The problems

  • Lack of communication between commercial and technical teams
  • No collaborative prioritization
  • Bugzilla tasks ignored and never completed
  • No clear roadmap for the future that the whole company can get behind

Which causes...

  • Lack of trust from both sides that what the other wants to work on is correct
  • A Tribal-like attitude of technical vs commercial (fix internal problems vs new features)
  • The company spinning it's wheels and not making meaningful progress for customers
Hopefully by now, it's obvious this isn't the way to run a company.

What this is not

Before we go any further, let's cover what this is not.
It is NOT a blaming session.

everyone has equal responsibility for making this work work no matter your position

It is NOT a discussion about the correct ratio of internal fixes to new features

There is time set aside in the system for having this discussion

It is NOT me forcing a one-size-fits-all solution down your throat

This is a base upon which to build. It is expected that as time goes on and issues are found it will evolve

What can we do?

Let's take each of the problems one-by-one, and look at how some of the features of the new system will help.
Lack of communication between commercial and technical teams

A daily standup meeting taking around 10 minutes happens every day

No collaborative prioritization

Every two weeks a meeting is held between technical and commercial to decide priorities for the next two weeks

Bugzilla tasks ignored and never completed

The main backlog only contains items that are considered likely to get done in the next 6 months

No clear roadmap for the future that the whole company can get behind

Initiatives and Epics give everyone on the team a single goal

The System

This is broadly based around a methodology called Scrum.
However... I am not advocating sticking to the methodology exactly.
Adaptations will be made as time goes on.

Sprints

  • Sprints are timeboxed periods of work
  • Everything else revolves around the sprints
  • A sprint should have a clear goal for work to be completed

The backlog

  • The backlog contains longer-term items for the business
  • It should only contain items likely to be worked on in the next 6 months.
  • It can contain bugs, new features, and technical debt items

The sprint queue

The Sprint backlog contains work that was previously in the backlog to work on for a sprint.
  • It should only contain the amount of work you think can be completed in the sprint
  • Every non-firefighting item worked on should be based on something in the sprint backlog
  • It is acceptible to add items to the sprint backlog as the sprint goes on

Meetings

There are various meetings that are scheduled regularly to facilitate planning and tracking of work in the system.
We will go through them in the order in which they will happen

Sprint Planning

The sprint planning meeting is held just before each sprint. It's purpose is to prioritize and estimate work to be done in the next sprint.
  • It should be kept to 4-6 hours
  • It should start with prioritization, a collaborative conversation between technical and commercial teams to decide what work needs to be done
  • Each item should be estimated
  • Items should be added to the sprint queue making sure it is achievable

Daily Standup

The daily standup happens at the start of each day and serves as both a progress update for the team and a time to think about blockers for the day ahead.

Every team member should give an update on:

  • What they did yesterday
  • What they are going to do today
  • Anything blocking them on any of their tickets in the sprint queue

Sprint Review

The sprint retrospective happens at the end of each sprint. It's a time to formally review this process, look at what worked well and what didn't, and commit to making any necessary changes.
  • Before the meeting, each team member should be able to add to a shared document the items in bulletpoint form:
    • What went well
    • What went badly
    • Suggested improvements
  • Though there are more questions you may want to add later.
These meetings keep happening, and may happen during a current sprint.
For example, a sprint planning meeting for a sprint starting next week may take place on a thursday before the previous sprint has ended.
Likewise, a retrospective may happen during a sprint looking back at the previous sprint.
Hopefully it's all making some sense right now. I'll stop here and take some quick questions before continuing.

Epics, Stories, and Tasks

Each piece of work is usually organised into epics, stories, and finally tasks.

Epics

Epics describe a large feature of piece of work. For example, "Implement in-house mimics", "Get current codebase into production"
  • Usually delivered over more than one sprint
  • Broken down into stories and tasks
  • Should usually take in the region of a few weeks to complete

User Stories

Each task that should deliver value to the customer should be written as a user story. They help keep the focus of the whole team on being customer-driven.
A user story is written in the form of 
As a <role>, I want to <thing>, because <the value they get>
For example: "As an engineer, I want to see live engine parameters, because I don't want to have to travel to the site to troubleshoot the problem"
Each user story should then be broken into individual tasks. These are the tasks that can then be worked on.
A user story should be completable within a single sprint. If it isn't, it needs to be broken down further.
Not every task will fit into a user story. Take, for example, a technical debt payoff item for renaming a variable. That's not delivering value directly to the customer so can't be a user story.
In this case, just add a task directly to the backlog for dealing with it.

Tasks

  • They are the smallest item of work
  • They will be what you are directly working on day-to-day
  • Each task should take 1-2 hours to complete.
  • Can be as part of a user story or directly part of an epic

Demo

Timeline

In order to make sure this actually get's implemented, I've put together a timeline for the first few sprints.
  1. 2nd January - First sprint planning session in the afternoon
  2. 6th January - First day of the first sprint
  3. 16th January - Second sprint planning session for the second sprint
  4. 21st January - First retrospective session for the first sprint
I will be regularly visiting and offering advice and guidance in the evening after I finish work.
I know this is all going to take some getting used to. All I ask is that everyone gives it a go for the first month or two and to keep an open mind.
I've seen this work for all kinds of projects now, and though it's not perfect it's a big step up from where Dexdyne are right now.
I'll take quick-ish questions now, and have individual sessions with everyone later to walk though in more detail their responsibilities are and answer questions in more detail with examples.