Agile Principles 102

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:

1. The trainer can "tick the box" on the "we covered the basics" section / poorly defined learning outcomes
2. Only 1 slide!
3. Only 1 page to print for the pack for the attendees! Save the trees! Save the planet!
4. 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!
5. There is some interaction with the trainees!

The consequences of this teaching/learning agile principles approach are:

1. Not enough positive effect or impact on the learners
2. 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
3. Some learners feel left out and/or confused by this session - seriously only 1-3 louder folks engage passionately with this approach
4. 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!

Timebox Rules For Better Time Management

For many years I studied techniques and practices of time management. Partially for my own sanity, and partially in an effort to help my team or the organisation I was consulting or coaching become quicker and nimbler (aka "agile"). I picked up lots of cool one-liners like "survival of the fittest" is incorrect in modern management philosophy - these days it is about "survival of the ones who learn only the right things the fastest".

We Don't Have Time Means We Have Strategic Conflict! We Use Timeboxing To Make This Transparent And Improve The Situation For All!

So on my journey I realised I also had to study prioritisation theory and practices. Surprising to me at the time, time management and prioritisation are 2 sides of the same coin effectively - especially in light of what it takes to survive (let alone thrive)!

Although there is a good Timeboxing writeup on wikipedia, I found it was too theoretical and not usable for people who had not tried many different options, nor did they want to read all the references to understand how to implement!

The below rules I came up with for my experiential training modules are really simple. I have yet to see any better that really help a group or team of people to focus on the most important thing(s) for the most amount of time available.

Timebox Rules For Better Time Management

I think I was inspired by deep reflections on how the agile Scrum framework and how we learn from our errors to come up with these rules that have helped me and many others who have followed them over the years.

Sometimes I vary the ordering by placing #3 nearer the end but for this timeboxing writeup it seems clearer where it is now:
1. Set the end time
2. Everyone watches the remaining time
3. Break large timeboxes into smaller timeboxes
4. Breadth or overview 1st
5. Depth or detail 2nd
6. Stop when time's run out
7. Don't worry - trust the process and stay with it

By following this guideline, the most important thing(s) have been covered, and you can always iterate or run another timebox again if you need to. (ie, use common sense, always!)

The main thing this framework helps with, is moving individuals and people forward. The brain is a muscle, so the more you and your team practice my timebox rules, the more you will get out of this, and achieve.

For example, a 30 minute meeting to make 2 decisions starting at 10am.

1. Welcome everyone and set the visible timer on the table/wall so that everyone knows that the end time is the end time. This is meeting is serious. (30 seconds)
2. Ask everyone to focus on the remaining time and to remain "in the meeting/room" and help everyone stay on focus of the timebox. (30 seconds)

There are now 29 minutes remaining.

3. Start a 3 minute overview timebox to ensure everyone's initial thoughts are heard before going into details. Agree the order of importance of the 2 decisions ("there can be only 1 priority 1")

There are now 26 minutes remaining.

4. Start a 5 minute timebox on the first decision that needs to be made
(assume the group is unable to decide)

There are now 21 minutes remaining.

5. Start a 2nd 5 minute timebox on the second decision that needs to be made
(assume the group is unable to decide)

There are now 16 minutes remaining.

6. Ask everyone to silently reflect on what they have learned or know about decision 1 for 1 minute
7. Ask everyone to silently reflect on what they have learned or know about decision 2 for 1 minute

There are now 14 minutes remaining.

8. Start a 5 minute timebox on decision 1 again
(assume still no decision)

There are now 9 minutes remaining.

9. Start a 2 minute timebox on decision 1
(assume a decision)

There are now 7 minutes remaining.

10. Start a 5 minute timebox on decision 2
(sometimes magic happens, and you don't need the whole timebox!)
(assume people all unanimously agree within 2 minutes)

There are now 5 minutes remaining.

11. Thank all and end the meeting early. DO NOT DRIFT INTO "any other business" or "miscellaneous agenda items". End the meeting. If people want to social then social, but it's no longer a meeting and make that clear!

For further motivation to help you and your team learn this best time management system, check my earlier post on No Time To Improve. Timeboxing gives you the time for doing the right things right.

Thankyou for reading! :-)

Agile Principles 101

So I spent the first few times teaching the Agile Principles in the way that I was ?taught? on a very expensive public certification* and it was the way I saw all the other agile coaches and trainers doing it. Peer pressure - even for an agile coach or agile teacher - is a tough thing to deal with! 

So too is that excruciating inner desire of wanting to teach all of the things (especially the things that took me a long time, and I learned the hard way)! But you only get a few minutes, hours or days in the lives of those whom you wish to help and there is a limit to how much of an impact you can make in those few short moments of time!

How To Really Teach The 12 Agile Principles Mindset - A Mystery Mastered

So 1 MS PowerPoint slide would go up, and the class would read the slide and the words silently. (How did I even know they were reading? Or were they just pretending to read so they could go home earlier?)

I would timebox this reading exercise to 6 minutes, as there are 12 of them. And everyone can read and understand complex phrases within 30 seconds, right?!!? 

And of course then another timebox for 4 minutes for Questions - "Are there any questions about this?" - kind of "emperor has no clothes" style - 99% of the time no one would ask anything. Probably because the principles are so simple to understand - people looking around would see their colleagues, managers, unknown strangers nodding knowingly! Perhaps even smirking with that secret deep understanding!

And, no one ever wants to feel uncomfortable - especially not by asking an obvious (to everyone else) question to clarify their own understanding, their own perception, their own experience!

Here's what that slide typically looked like (it hurts me just to revisit the old old decks!)

Notice how neatly all 12, and the title, fit really neatly onto 1 slide! Win! ;-)

I particularly like the tiny font size, and the bullets! Wow! Those bullets - they really draw attention to what's so very important to make sure the 12 principles of agile successfully transfer off the presentation and into people's consciousness, and cause the learners (?) to change their way of thinking, of being, their behaviours and thus the real target - their way of working to being more productive with the limited resources and time they have available!

Now for some truth of this widely used, common, dare I say - standard or best practice - approach...

In a nutshell, the pro's of this approach are:

1. The trainer gets at least a 6 minute break
2. The trainer can "tick the box" on the "we covered the basics" section / poorly defined learning outcomes
3. Only 1 slide!
4. Only 1 page to print for the pack for the attendees
5. Lots of nods from the trainees - the words do seem sensible - which makes all trainers feel good inside!
6. Very few questions (in 4 minutes) if any, and, no time to get into any real detail of either the trainer's experience(s) or learners' experience(s) - so only quick superficial answers or "park that one" statements to move along!

The con's of this approach are:

1. Zero positive effect on the learners
2. Sometimes negative impact on the learners as they begin to logically unpack and envision applying in their own organisation and discover stumbling blocks with all or nearly all of the principles!
3. Learners feel rushed
4. Learners realise the trainer might not be a good one or that the training content might not be good

Post mortem: 

Did you notice who gets more benefit from teaching the agile principles like this? Who's paying the money? Who's earning the money? Is it a fair exchange?

No one can apply anything that is read from a densely packed and boring slide like this! The agile principles are too concise and need expansion/discussion to help people interpret them correctly singly and collectively, and within the context of the learners which is unique from group to group, team to team and individual to individual. It's a subjective perspective thing!

I suggest don't teach or try to learn the agile principles this way, please. It's simply a waste of time and energy. I have many more experiences and ideas which I am sharing on What Is Agile For

* Seriously!!? Who can learn something as simple (NOT!) as ballet or agile (or anything else of real substance that is life changing) after only 1 or 2 days on an expensive course for which you get a certificate/certification/membership!!? Certifiable/certified maybe. :-)

Make The Agile Principles Real, Make Them Useful, Make Them Usable, Or STAY HOME! "Hey, teacher! Leave these kids alone!"

Thankyou for supporting! Best wishes on your journey!