In my previous post on my software engineering approach I talked about the various feedback mechanisms that can be used to get better outcomes. However, that post is very light on details about the various activities that could be used to manage the process. This post will touch upon what I think are some valuable practices, and the appropriate cadence of using these practices. This post assumes you’re starting from scratch, although any existing organisation will certainly have a set of practices already in place.
This is still a work in progress – expect updates over the next few weeks
Table of Contents
- Setting Strategy and Goals
- Impact Mapping
- Making a Roadmap
- Building a Kanban Board
- Meeting Schedules
- Further Things to Add to this Post
Setting Strategy and Goals
TBD
References:
Impact Mapping
Quoting from https://www.impactmapping.org/drawing.html
An impact map is a visualisation of scope and underlying assumptions, created collaboratively by senior technical and business people. It is a mind-map grown during a discussion facilitated by considering the following four aspects:
Goal: The centre of an impact map answers the most important question: Why are we doing this? This is the goal we are trying to achieve.
Actors: The first branch of an impact map provides answers to the following questions: Who can produce the desired effect? Who can obstruct it? Who are the consumers or users of our product? Who will be impacted by it? These are the actors who can influence the outcome.Impacts: The second branch level of an impact map sets the actors in the perspective of our business goal. It answers the following questions: How should our actors’ behaviour change? How can they help us to achieve the goal? How can they obstruct or prevent us from succeeding? These are the impacts that we’re trying to create.
Deliverables: Once we have the first three questions answered, we can talk about scope. The third branch level of an impact map answers the following question: What can we do, as an organisation or a delivery team, to support the required impacts? These are the deliverables, software features and organisational activities.
I think it’s always a good idea to attach some sort of metrics to goals and impacts. It should be very clear how the goal is going to be measured, and if the deliverables are making real progress on shifting the behaviour of the actor.
A good way to create an impact map is to run a workshop. See https://github.com/impactmapping/open-impact-mapping-workshop for an example on how to do this.
A good cadence to do impact mapping is every quarter, or when goals change significantly.
Making a Roadmap
Roadmaps are tricky things. It can be hard to create, and then having an item on a roadmap can be treated like a commitment or promise. My favourite source of advice on roadmaps comes from John Cutler, where he write The Beautiful Mess.
The first advice I like is his guidance on suitably detailed roadmap items:
Each of the items in the roadmap should have a clear linkage to items on the impact map. For example, the “Key Persona” ties directly into the “Actor” in the impact map above. The “High Level Focus” should tie in directly with an impact.
How often should the roadmap be updated? Many organisations do it monthly, or quarterly. John Cutler has some more good advice: continuous roadmapping. As completed roadmap items move off the board, you immediately add in a new option.
The important point here is that we try to keep this board filled at all times with eight cards. Eight cards! That’s manageable. As new information becomes available, we swap in cards as necessary.
Further references:
- https://cutlefish.substack.com/p/tbm-4853-one-roadmap
- https://cutlefish.substack.com/p/tbm-1952-a-portfolio-of-bets
- https://cutlefish.substack.com/p/tbm-218-level-depth-time-and-frame
- https://medium.com/@johnpcutler/hybrid-boards-for-roadmapping-736a0514d3d8
Building a Kanban Board
The key to a good kanban board is its ability to act as an information radiator. I like to think a kanban board is doing its job if an interested bystander (e.g. CEO, VP product, etc) can look at the board and understand:
- What’s the goal that you’re working on?
- What are the actors and impacts?
- What are the prioritised epics?
- What stories are currently being worked on?
- When will it be done?
- What will be done next?
It’s hard to get all of that information from a single board, but you can get close. For those with a physical board, I find it much easier to do this. Electronic boards (e.g. Jira) make it much more difficult, although there are things you can do to help.
Goal (or goals) should be visible somewhere, written in a sentence or two, with key measures.
Actors/personas should be identified and written down, with a sentence or two.
The real work comes in the epics. One hard rule I use: every epic should be limited to a single impact (with a corresponding actor).
On the kanban board, each epic becomes a swimlane. The priority of the epic will be obvious from it’s position on the board (high on the board means higher priority)
The columns in the kanban will reflect you engineering process. Stories and spikes should be represented as cards on the board, placed in the appropriate swimlane and column. If your process is not well defined, a good starter set of columns would look something like:
- Backlog. I often leave this column out, but you can put in ideas for work if you want to keep track of upcoming work.
- Prioritised. The team has agreed that the feature should be started iminently.
- Ready for Development. The work has been analysed, acceptance criteria agreed, and can be pulled into development when ready. In essence, the “definition of ready” criteria have been met.
- In Development. The development team is working on the story or spike right now. “Working” in this context means coding, testing, reviewing, and all the other things that are involved in completing the work to an acceptable standard.
- Completed Development. All work on the story or spike has been completed. It has met the “definition of done”. The code has been merged into the main development branch, artefacts have been built. Some organisations might like to break this into more columns such as “User Acceptance Testing”, or whatever meets their needs.
- In Production. The feature has been deployed onto production servers.
- In Use. The feature has been shown to have been used by at least one user.
The Phoenix Project book describes 4 types of work:
- Business Projects
- Internal Projects
- Changes
- Unplanned Work
All this work needs to be represented on the board. Business Projects are normally accounted for in the process described above. One red flag to watch for – if all prioritised work is only business projects. Often internal IT projects or changes are not prioritised. This could be back end maintenance, technology uplift, technical debt improvement, research projects. These should all be represented on the board, with clear goals, actors (these can be internal actors), and impacts.
The last point is “unplanned work”. This is emergency work that must be done. I always keep an epic open at the top of the board for this work. Be careful not to put all random bits of work in that epic – make sure it really is an emergency. For example – if a bug is discovered late, it could be an emergency “fix it now!” problem, or the product own could decide to prioritise it later, in which case it goes into to epic most closely associated with the impact of the bug.
TODO: example board.
Meeting Schedules
TODO:
- Stand ups
- Planning and curation
- Demonstrations
- Retrospectives
- Roadmaps and strategy
Further Things to Add to this Post
TODO: keeping this here to remind myself of what to add later.
- Tracking progress
Renaissance Developer 