Similarly in the UK, I've heard that people who've had driving points deducted from their licences are shown videos of accidents that were caused by speeding drivers, intoxicated drivers, drivers in non-roadworthy vehicles, etc. Learning from the bad impacts us more, and teaches us good.
This time I did not reveal the "masterpiece single slide" in a single click. Instead I made use of PowerPoint's fly-in, appear, and other "On Click" events to have the bullets appear as required (some lines are longer or more complex than others, so give the trainees a few extra seconds to read and understand, occasionally - I am such a nice trainer!)
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
DO: Happier users getting valuable features earlier
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a
DON'T: We give our users unusable software quarterly, half-yearly or annually only, we (in)frequently upset our users, we lose our jobs.
Business people and developers must work together daily throughout the project.
DON'T: Business and development don't understand each other, don't know each other, don't work as a team, so the environment is low trust, low knowledge, low productivity, work and value does not flow, and people are stressed and unhappy. No one is satisfied with anyone, including ourselves, blame game is played often, so eventually we lose our jobs or we leave our (bad) jobs.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amountof work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
DO: We continuously learn and improve and become stronger as a team - we become a high performance team that can do anything.
DON'T: We keep doing the (every) thing(s), the same way(s), we never get better, we never modernise our skills, we get bored, we are boring, we are overtaken by other teams, we look bad in comparison, we ... lose our jobs.
In a nutshell, the benefits of this teaching/learning agile principles approach are:
- The trainer can "tick the box" on the "we covered the basics" section / poorly defined learning outcomes
- Only 1 slide!
- Only 1 page to print for the pack for the attendees! Save the trees! Save the planet!
- It's much better than just a single slide of reading and a short FAQ (aka agile principles 101) before moving on as some of the learners do engage with the thinking process and take some of the messages into consciousness!
- There is some interaction with the trainees!
The con's of this teaching/learning agile principles approach are:
- Not enough positive effect or impact on the learners
- Some negative impact on many learners as they begin to feel that agile is being forced on them, that it's "go agile or lose my job". "People don't resist change, they resist being changed." - Peter Senge
- Some learners feel left out and/or confused by this session - seriously only 1-3 louder folks engage passionately with this approach
- Learners realise the trainer might not be a good one or the training content might not be good
"go agile, or lose your job!" is not a positive message nor a reasonable call to action! Look how well "Stop smoking, or die!" or "Lose weight, or die!" is working in the health industry. It's not that these things are not true to some degree, it's that they're also false to some degree. And the framing does not allow for that "shade of gray" - so people can spot just one counter example and choose (with logic) to disbelieve all of what the principles are trying to encourage understanding of.
A handful of learners will become more aware of the big picture and hence will support because they believe. But that's not good enough unfortunately!
Users and customers are not always the same thing! The market place - the fact that every software team member is facing off to the market place no matter if they are the networking engineer, database guru, feature team member, scrum master, product owner or any other role required to get the software Done, is overlooked - even in this approach. And this is fundamental - that's why the highest priority is called out so explicitly at Number 1 position!
Don't teach or try to learn the agile principles this way. Rather use this as a thought experiment (or 12) once you have taught or learned them in a more positive way. I'm documenting my experiences via my earlier post What Is Agile For You What Is Agile For so if you are interested, read the other methods linked there!