The team is not delivering value to customer, or it takes too long to do so
Central question
How can we make our deliveries more valuable?
Context to scenario
describe: Requirements Stories tasks and epics
Examples and Demos
Something something
Answer Common Questions
How does it help? What needs to change? How the customer will see this?
Motivation to question and conclusions
By focusing on user value from the start of our pipeline, we can reduce the number of guessing work, as well as delivering smaller increments that build up to something.
Related notes:
More meetings
Introducing more meeting takes away dev time, often not enough artifacts are built and we end up just wasting time.
Definition of Workflow
The shared understanding of how value gets delivered, which includes work items, start and finish points, states, WIP limits, policies, and service level expectation. It is visualized on a Kanban board.
Minimum DoW
Definition of work units that deliver value
Definition of points where we have 'started' and 'finished' (ready to pull vs done)
States to which the item flow from started to finished (WIP)
How WIP is controlled
A Service Level Expectation (SLE) for how long it would take an item to flow from started to finished
How Kanban controls WIP
wip
XP and embracing change
XP sees the feedback as only useful if it's fast and early, it needs the customer to be always available.
XP and Scrum
XP without Scrum Works, Scrum without XP does not.
So why Scrum?
Scrum's original intent was to make something that was agile into something more palatable to business'. So it turned agile into something around agile, instead of being agile.
User Stories
Stories should be always user focused. Behavior driven even. Stories should not take more than a couple days to be completed. They can be part of a larger effort (EPIC) but they should be self contained.
We must remove technical implementation details from User Stories all together. Whatever the implementation take is, it's an engineering problem and not a management problem.
Desired outcome, not the solution.
A good rule of thumb is: A good user story is One Small Thing that the user needs, not everything that they might desire.
People tend to think that User stories needs to capture all user wants from a feature to be valuable, making it more complicated and testing more difficult
A story cannot be a statement of the work that needs to be done, this fall under either by over-specification or remote control programming
Bigger stories rely on getting things right the first time. It gives very few space for course correction. You need a perfect guess of what the user wants.
If the cost of failure is less than the cost of planning, you must not plan.
However we should allow for failing and develop enough team confidence so that we have enough prototypes for each deliverable (refer to Delivering Value). Picking the best one and iterate on that based on the customer feedback.
Do what's valuable, don't do what is not.
There are three states of being. Not knowing, action and completion.
Accept that everything is a draft. It helps to get it done.
There is no editing stage.
Pretending you know what you’re doing is almost the same as knowing what you are doing, so just accept that you know what you’re doing even if you don’t and do it.
Banish procrastination. If you wait more than a week to get an idea done, abandon it.
The point of being done is not to finish but to get other things done.
Once you’re done you can throw it away.
Laugh at perfection. It’s boring and keeps you from being done.
People without dirty hands are wrong. Doing something makes you right.
Failure counts as done. So do mistakes.
Destruction is a variant of done.
If you have an idea and publish it on the internet, that counts as a ghost of done.