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 are simulations / (serious) games / workshops, simply because by ‘doing’ 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 issues. Some of those practices do really originate in agile / lean, other have been simply recognised as agile / lean because these are often used by agile / lean people 🙂 Some of the practices exist for long time! Actually, any self-respecting ‘real’ manager should know and apply those practices!
The goal of the simulation is to discuss the given impediment and to 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, budget are the responsibility of the product owner. Typical team impediments should be reflected back to 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. It’s important that some actions are taken on by the team itself, 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. As well, words should be carefully chosen, to have the correct meaning in the tests. Hence the link with poetry 😉
Smells (warnings) regarding test scenarios:
- 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 visualizing how different variables in a system are interrelated. (wikipedia.org)
Causal-loop diagrams can be used to analyse how the system will behave when changing variables, or when we are 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