Agile Tour Brussels has been a great event, likewise previous editions.
The sessions I’ve attended:
- Solving impediments with agile/lean techniques (by Ben Linders)
- Poet’s guide to acceptance testing (by George Dinwiddie)
- Causal-loop diagrams (by co-learning)
Solving impediments with agile/lean techniques (by Ben Linders)
My preference is simulations / (serious) games/workshops, simply because you learn a lot more (and it sticks).
This simulation involves a list of issues (impediments) of different kinds and a list of tools/techniques/practices to tackle problems. Some of those practices do originate in agile/lean; others have been recognised as agile/lean because agile/lean people often use these đ Some of the practices have existed for a long time! Any self-respecting ‘real’ manager should know and apply those practices!
The goal of the simulation is to discuss the given impediment and find (one or more) practices best suitable to start solving the impediment. As well, the discussion evolves of who is supposed to take action. Typical areas such as requirements, priorities, and budget are the product owner’s responsibility. Specific team impediments should be reflected in the team by (for example) the Scrum Master (in a Scrum team), and the Scrum Master can assist in exploring how to tackle the issue. The team itself must take on some actions, so the team learns how to deal with problems in the future.
Poet’s guide to acceptance testing (by George Dinwiddie)
The Given-When-Then format is a style to represent tests and is part of Behaviour Driven Development. The goal of the exercise was to evaluate the level of clearness (un)ambiguousness of given tests. Frequently tests are filled with clutter, pre-conditions, post-conditions, and other irrelevant information. Also, You should carefully choose words to have the correct meaning in the tests. Hence the link with poetry đ
Smells (warnings) regarding test scenarios:
Resources:
- Given – When – Then (article by Martin Fowler)
- How to get the most out of Given-When-Then (by Gojko Adzic)
Causal-loop diagrams (by co-learning)
A causal loop diagram is a causal diagram that aids in visualising how different variables in a system are interrelated. (wikipedia.org)
You can use Causal-loop diagrams to analyse how the system will behave when changing variables or adding a ‘solution’ (or ‘quick-fix’).
The exercise involved the creation of a causal-loop diagram regarding the change of having individual versus shared ownership of a system component. See the example below.
The variables identified:
- Quality of the component
- Quality of the product
- Level of coherence (holistic view)
- (number of) Integration issues
- Level of knowledge sharing / knowledge availability
- (number of) Organisational silos
- Level of reusability (maintainability) of the component
- (number of) different technologies
Lean UX workshop
Creation of proto-personas and hypothesis statements
