Achieving real business value from software projects is hard - most projects fail. This slide deck shows how we reduce risks of failure and increase chances of success by delivering value in small increments with a traceable connection to business goals.

1. Focus: Lean Delivery
Workflow
Practices for high-quality software delivery

2. 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.

3. Planning

4. 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.

5. 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.

6. #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.

7. BACKLOG DOING APPROVE DONE
?
Evenly-sized features make planning easier

8. 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

9. 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.

10. 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.

11. Delivery

12. 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.

13. 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

14. 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

15. 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.

16. 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 customer
2. Pass peer review of code
3. Have automated tests, and these must pass, including regression tests
4. Meet the acceptance criteria
5. Be approved by the product owner
6. Be releasable without manual steps

17. 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.

18. Learning

19. 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.

20. 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!

21. Contact
info@fluxus.io
http://www.fluxus.io/