I was looking around for how to make my teaching of the agile principles much better than my and the class's experience of them as per "industry standard" captured in my earlier post:
agile principles 101.
Somewhere along my many readings over the years, I came across an article describing changes to the teaching method for fire fighter training used somewhere in the US (to the best of my recollection). I've hunted for the reference but have not found it again (yet) unfortunately.
The fire fighter training story went along the lines of teaching trainees by having them watch videos of fire fighter crews operating in various scenarios and then facilitated debriefing of the elements that made each crew successful. Apparently this change to the previous training method was marginally better as there was a minor percent improvement in successful rescues / blazes extinguished / fire fighter injuries and deaths.
Then someone discovered that a small change to the content produced much better results. Instead of showing the trainees scenarios that were successful and then debriefing, they showed unsuccessful scenarios and then debriefed the errors.
Scenarios where fire fighters in their rush to save took personal risks, overlooked snagged hosepipes, did not operate the hosepipes and ladders effectively as 1 team, etc. And the result of these individual, and at first glance, minor errors, rescues failed, blazes were not extinguished and fire fighters were injured or died. Debriefings of these failure scenarios caused the trainees to learn (a lot) more, and (a lot more) quickly, which was quickly demonstrated by these new crews having much higher percentage success rates, and most importantly, fire fighter injury and death rates!
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.
So...I thought I would apply this principle to teaching the agile principles.
For many many classes, I spent a few more minutes on the same slide I used previously (how lucky to not have to "waste" any more precious slides on this foundation to the whole huge "agile umbrella of knowledge"!
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!)
So now I had the class read 1 principle at at time, and after everyone finished reading the current principle I asked the class - "What effects would happen if you/we did this?". Followed by "And what effects would happen if you/we didn't do this?".
Typically the 24 DO / DON'T outcomes (which I hoped were deep realisations embedded forever in the learners' consciousnesses) were similar to below:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
DO: Happier users getting valuable features earlier
DON'T: We don't satisfy our users, sooner or later we lose our jobs
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
DO: The development team adapt whatever we/they do to accommodate users' changing minds
DON'T: We build the wrong thing, we don't satisfy our users, sooner or later we lose our jobs
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
DO: Happier users getting features preferably every few weeks or few months
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.
DO: The business and developers work together and become 1 balanced team
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.
DO: Hire good people, support them, they are super motivated and do the best job they can
DON'T: Don't support our people, give them bad environment(s) in which to do complex work, don't support them, and continuously interfere with how they do what we ask for. People get frustrated, and either they leave their jobs, or eventually lose their jobs because they're just blocked from doing (enough) good.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
DO: Less documentation, fewer/no hand-offs, more quality conversation which is better for conveying difficult abstract details and concepts to each other. More productivity time.
DON'T: Convey information to each other in the least efficient and least effective ways, resulting in miscommunications, misunderstandings, and a lot of wasted time, effort and money. All this waste results in unhappy business people, we lose our jobs.
Working software is the primary measure of progress.
DO: Everyone believes the development team's progress "report" as it is clearly running in front of eyes and fingers, or not, and hence everyone can plan more confidently based on realtime, real, information.
DON'T: Measure progress by some other means - maybe Red-Amber-Green "traditional" governance reports, Earned Value Burnups, (C)RAID Logs, and we plan based on those abstractions of progress, and quite often those abstractions are not reality and may be quite stale at moment of understanding. And when progress reports are not reality, a lot of wasted time, effort and money goes into that "cottage industry" for negative Return-On-Investment (ROI) and the organisation's plans are wrong. This results in unhappy business people, and ... job losses.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
DO: Everyone goes together and works together. Few surprises. No late night and weekend work for anyone. Morale stays high and energy levels are protected and nourished.
DON'T: People work late nights, weekends, get tired, get grumpy, produce bad quality plan/artefacts/tests/requirements/analysis/code/architecture/designs/workshops/sessions/meetings/etc. Boom-and-bust cycles. People miss their personal lives, they leave their jobs. Quality suffers, the users and company suffers, and ... job losses.
Continuous attention to technical excellence and good design enhances agility.
DO: Our codebase remains cheap to maintain, nice for people to work in and learn from, and we can realistically and constantly "welcome changing requirements, even late in development" from Principle 2 above. :-)
DON'T: Our legacy codebase becomes expensive to modify, it is no longer "soft"ware, it has become "hard"ware, and people hate working in it because little changes require great effort and introduce great uncertain risks that developers are unable to easily (if even possible) mitigate and hence the developers appear to go slower (but actually they're doing a lot more difficult cognitive work!). It creates cognitive dissonance in developer's minds and this is tiring and annoying, so they get sick of it physically due to stress and sickness rates are higher than "normal", developers/analysts leave temporarily on long-term illness, or leave the role, or something blows up in production, and after a short period of job creation (Operations needs more people to deal with poor Change/Development/Tech/etc outputs) ... eventually job losses.
Simplicity--the art of maximizing the amountof work not done--is essential.
DO: We keep things simple, we save effort, time and money, so more productivity and happier users!
DON'T: We overcomplicate things, waste a lot of effort, time and money, sometimes even make quality worse. We maximise workload, decrease creativity and innovation, and people leave their jobs, or we lose in the market place and eventually lose our jobs because our competition is quicker with new features and products.
The best architectures, requirements, and designs emerge from self-organizing teams.
DO: The team knows their design, requirements and architecture inside-out, back-to-front and can confidently do things at speed, knowing "where the skeletons are buried", and where they risk nothing, a little, some, more, a lot, or "bet the whole farm" - when they have to.
DON'T: The worst architecture and worst requirements are pushed onto the team who don't understand or know them evenly or equally well, and hence unintentionally build the wrong things in the wrong ways and nothing integrates or works properly, or worst developers paint the whole codebase into a corner. The users and business people get upset as the investment is lost, developers ... lose their jobs.
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 consequences 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
Post mortem:
Did you notice who gets more benefit from teaching the agile principles like this? Who is not getting benefit? What about all the negativity taste in the mouth at the end?
"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.
This approach does not work well enough. A negative call to act only works when the person called this way really believes that they will actually die otherwise (a gun to the head, and someone's finger on the trigger, and no doubt they will pull it unless you do as they say), and even then, a substantial number of people (and in team work, you only need 1 to be out of alignment) will freeze or flee in different direction. Some will evenly actively fight against it - sabotaging, cynical outbursts, campaigning, using Schopenhauser's methods to win any argument.
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!
Also, the summary interpretations are a HUGE gap from what the principles are actually saying!
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!
Every line of code or configuration or content that in some way supports the objectives of the business' service to its customers is either "for" or "against" success in the market place. The principles are trying to make "IT" folks aware of this, as most are blissfully friends with their computer and that's most of the extent of the engagement with the firm they work for. They can't see the tight chain of inter-dependence that truly exists between how quickly and cleanly and consistently they work, with how well the end customer perceives the company.
This approach is more effective than the industry standard agile principles 101, but it causes a lot of hostility quite quickly and hence is simply not effective.
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 so if you are interested, read the other methods linked there!
Thankyou for reading! Let me know what you think!
