Practices for high-quality software delivery
Ways of working help to define how we approach our work.
By developing a consistent set of practices, organisations can enable learning across projects and make it easy for 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 types of projects.
Our ways of working are based on our experience at Fluxus, but are always open to improvement. We share them here and the info in this article can provide a baseline for others to work from. In the first of this two-part series we look at planning.
Planning
Key client roles
Our sponsor is the person responsible for 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 organisation. 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.
#beyondestimates
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.
Evenly-sized features make planning easier
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-5 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.
