Sometimes it can be hard for a team to learn within their existing processes. Mistakes can be costly, and trying out new practices and techniques can be difficult at first. These training courses are designed to help the team spot obvious pitfalls, learn through making mistakes in a safe environment, and find out how to make their existing projects “safe to fail” instead of “fail safe”.
Agile, Lean and BDD Courses
All courses are available to run at customer sites with prices on request. Expenses for courses run outside of London will be extra.
Please note that I do not currently have work visas for any countries external to the EU. If you require me to obtain a work visa, this may result in extra expense.
About all courses
Most people are familiar with BDD at a scenario level. Perhaps you have tried it, and are struggling with the tools. Perhaps you would like to know how to start.
BDD is much wider than just scenarios! From 2006, Chris Matts’ work on Feature Injection has played heavily into practical, effective BDD in a number of different environments. I am therefore taking the focus away from the tools, and into effective analysis, so that scenarios can be phrased and maintained successfully.
The two philosophies behind BDD – Deliberate Discovery and Real Options – are important for understanding why BDD works, so that participants are able to use it in their own context.
2-day BDD Course
- Deliberate Discovery (Game)
- Real Options (Talk)
- Deliberate Discovery Brainstorming (Workshop)
- Introduction to BDD and Feature Injection (Talk)
- The Pennies Game: Flow and Collaboration (Game)
- From Vision to Scenario (Workshop)
- Retrospective (Workshop)
- Review of Day 1 (Game / Workshop)
- Effective Scenarios: Keeping it Maintainable (Talk and Demo)
- BDD and Risk (Game)
- BDD for Life: Applying BDD to Anything (Talk)
- What might make it fail, and how to fix that (Workshop)
- BDD in a box – a review (Workshop)
Deliberate Discovery – “as opposed to accidental discovery” – is one of the philosophies which lies behind Behaviour Driven Development. It comprises the act of targeting areas of ignorance in a project, whether related to domain, process, people, technology, etc.
By deliberately targeting areas of ignorance we can accelerate learning – usually the constraint on software development projects – and identify areas of risk.
Deliberate Discovery also warns us that there will always be aspects of a project that we don’t know we don’t know, also called 2nd order ignorance. Bearing this in mind can help us to seek feedback faster and keep options open.
Game and Workshop
The Deliberate Discovery game consists of a simple game in which the rules and context are apparently obvious – but there are surprises in store!
This is followed by a brainstorming workshop in which we list the many things which we discover throughout our projects – whether helpful or otherwise – and think about ways in which we might have discovered them earlier and made better choices.
Attendees will learn
- how varied discoveries on projects are
- why it can be beneficial to deliberately target areas of ignorance
- how to be mindful of, and mitigate, 2nd order ignorance
- why collaboration and conversation are essential in software development
- why missing an opportunity to learn is wasteful
3-day Agile, Lean and BDD Course (coming soon)
This course consists of most of the 2-day sessions, together with an extra day focusing on the basics of Agile and Lean needed to understand iterative development and how to work effectively in a collaborative, conversational environment.
This extra day will not be necessary if all participants have already participated in Agile projects or have undergone Agile training such as a Scrum course.
All workshops, games and talks can be run individually. Cost depends on location, audience and the session required, and may be free for some audiences. Please contact email@example.com if you’re interested.
Notes on TDD and Acceptance Testing
In 2003, Dan North, my mentor at Thoughtworks, realised that a lot of the difficulties he encountered when teaching TDD were due to the word “test”. He founded the Behaviour Driven Development movement in response.
TDD is primarily a design activity, and writing user-centric scenarios before coding can be seen as a learning and conversation opportunity. I teach the skills you would commonly associate with these practices through Behaviour Driven Development instead. My experience has been that trainees pick up the necessary disciplines in BDD far more easily than when using the TDD vocabulary.
BDD is not an “advanced form of TDD”. If anything, trainees find it simpler, as it alleviates some of the confusion caused by TDD’s vocabulary. This focus on simple language and communication also makes it easier for developers to communicate with each other and with the business.