focus: lean delivery workflow
TRANSCRIPT
Introduction
Our ways of working help to define how we approach our work.
By having a consistent set of practices, we enable learning across projects and make it easy for our teams to share knowledge and insights.
A well-defined process helps to ensure success and promotes the ability of the team to self-manage in varied client engagements.
The ways of working are based on our experience, but are always open to improvement. This document is a baseline.
Key client roles
Our sponsor is the person responsible for bringing us in and/or signing off on budgets.
The product owner is the person responsible for prioritising features and approving completed features.
Sometimes a programme manager or project manager may be working for the client. Our main relationship to this person should be to demonstrate that our system for producing features is working and that the product owner is happy.
Impact mapping
● Ensures that development is driven by business goals● Gives stakeholders, product owners, UX and engineering a shared document● Identifies which actors and impacts are being met and which are under-served● Visualises features in terms of their outcomes● Shifts focus away from designing features towards shaping the outcomes
The impact map is our primary resource for scoping a project and defining the criteria by which the project is judged.
The book Impact Mapping by Gojko Adzic explains the concepts and benefits of impact mapping in detail.
#noestimates
Estimates can help a client to plan, but they can also be misleading.
Instead of complex estimation systems, we ensure that features are small units of work that can be achieved in 1-5 days, with contingency.
This makes planning easy - if all features are similarly sized, we can agree on a number of features to deliver by a certain date.
We can also swap one feature for another without expensive re-planning.
This requires discipline when scoping the project, to ensure that features fit within 5 days, or are divided into smaller features that do.
I.N.V.E.S.T
Features should be:
● Independent, so that they do not depend on other features unless necessary
● Negotiable, so that it can always be revised if new information arises
● Valuable, so that it is meaningful to stakeholders and end-users
● Essential, so that it fulfils some crucial need for the customer
● Small, so that it fits within 1-4 days and ensures quick turnaround
● Testable, so that we can be confident that it works as expected
Lean UX
Lean UX helps us to develop ideas about how features can work for users.
By making UX a conversation, we get everyone’s assumptions out in the open.
Paper prototypes and simple wireframes are easier to change than detailed PSDs.
Thinking about how a system behaves rather than how it looks leads to better UX.
UI sketching is a great way to include non-technical stakeholders in designing the system.
BDD
Behaviour-driven development means developing an understanding of how our software is meant to work by describing its behaviour.
BDD isn’t about testing, though it can enable it. We write BDD to improve our understanding, not to improve our test coverage.
Combining BDD and Lean UX means that both our visual and conceptual understanding of system behaviour are documented but also easy to change.
BDD scripts should resolve ambiguities in the design by explaining how specific examples should be handled.
Kanban
Our kanban board measures the progress of features. It measures how much value has been delivered, not how much work has been done, or who did it.
The board shouldn’t include bugs or technical tasks, because these don’t give us a good idea of overall progress.
Each card should represent one feature from the impact map.
One person can only be assigned to one card, with no exceptions. Multiple people may be assigned to the same card if they’re working together.
In-progress cards should be moved to done before starting any new cards.
Kanban
Kanban is:
● A system for tracking feature development
● A visible marker of progress
● A signal for when activity is needed on a feature
● There to tell the client how the things they care about are progressing
Kanban is not:
● A to-do list of personal tasks
● A list of everything that needs to happen
● A holding-pen for opinions or ideas
● There to explain why features aren’t being worked on
Progress is measured in features delivered.
Similarly-sized features are easy to substitute without changing scope.
Anything that isn’t a feature is an implementation detail.
Technical dependencies are checklist items on the relevant card.
BACKLOG DOING APPROVE DONE
Definition of Done
Before starting work on a feature, you need to know that you can deliver it - what done means and when you have finished.
This starts with a conversation between the person delivering the feature and the product owner (or stakeholder) who will sign it off. As part of this you will create and discuss acceptance criteria. These should be focused on the business impact and be in plain English. These can be used as the basis for BDD tests.
Definition of Done
In addition to the acceptance criteria for an individual feature, the project will have a wider ‘Definition of Done’ which will apply to every feature. This should be tailored to suit a project but for example, to be considered “done”, a feature must typically:
1. Have acceptance criteria agreed with the customer2. Pass peer review of code3. Have automated tests, and these must pass, including regression tests4. Meet the acceptance criteria5. Be approved by the product owner6. Be releasable without manual steps
Continuous delivery
Continuous delivery means that as soon as a feature is completed, we are ready to deploy it to production.
To do this, our codebase needs to stay in a releasable state at all times.
Once a feature meets the Definition of Done, it should be releasable immediately to production. Automated deployment procedures should ensure that there is no disruption or downtime except in rare cases.
Continuous Improvement
Everything about our ways of working is subject to continuous improvement.
We should aim to deliver faster, with higher quality, greater reliability and lower cost over time.
This means that we must learn from our experiences. Improvements made on one engagement must be spread to others.
To do this, we will need to share technology, processes and techniques across projects, and meet regularly to discuss how to diffuse any improvements made.
Further reading
● Impact Mapping by Gojko Adzic● Lean UX by Jeff Gothelf● Lean Startup by Eric Ries● Continuous Delivery by Jez Humble and David Farley● FIRE by Dan Ward● The Goal by Eli Goldratt
Further suggestions welcome!
Contact
http://www.fluxus.io/