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 <thevalue 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.
2nd January - First sprint planning session in the afternoon
6th January - First day of the first sprint
16th January - Second sprint planning session for the second sprint
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.