Agile Coach Interview And Selection Questions

Years ago I was hiring agile coaches, and working closely with a hiring partner who was really really (!) good at finding talent. I had no time, he had some time and was keen to help me in any way we could figure out how. I knew agile, he knew recruitment. I knew coaching, he knew people.

The first round questions that I designed then still hold true today. I was inspired by Joel Spolsky's 12 questions candidates should ask their potential employer before deciding to join back in 2000. It may be a little old in some circles by today's standards, but it is still insightful imho:

The Joel Test:

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

The neat thing about The Joel Test is that it’s easy to get a quick yes or no to each question. And that's what I needed from my first round interview questions that anyone, even a non-agile-skilled or non-agile-knowledgeable person could use. So I came up with 24 quick questions, and we got some truly great candidates making it through the face-to-face screenings.
One of the most (perhaps THE MOST) important things about an agile coach is their experience. Money can't buy experience. Reading about other people's experiences, or attending courses based on other people's experiences is not the same as having the direct hands-on "did the best I could with the information and knowledge I had at the time, and nothing worked...until...after much persistence and many failures something worked!"

All experience is relevant. I am wincing at how arrogant I was when I was younger thinking that attitude mattered more than experience. They are equally important - it all depends on the problem space and time! The thing about people without experience in a particular space, is that they don't know what they don't know. My 24 questions highlighted things that were relevant for the different openings we had going at various times. A quick 10 minute Yes/No followed by a few initial typical HR availability, package suitability, location, role etc matching minutes and wallah - 1x effective initial screening for very cheap!

The very few who made it to face-to-face interviews which were experiential and enjoyable for both the coaches and the candidates highlighted the right candidates each time! Happy daze! (especially compared to traditional candidate screening processes and pains)

Rob's Agile Team Member or Agile Coach 24 Question Assessment:

1. Do/did you use source control?
2. Do/did you not use source control?
3. Can/could you make a build in one step?
4. Can/could you not make a build in one step?
5. Do/did you make daily builds?
6. Do/did you not make daily builds?
7. Do/did you have a bug database?
8. Do/did you not have a bug database?
9. Do/did you fix bugs before writing new code?
10. Do/did you not fix bugs before writing new code?
11. Do/did you have an up-to-date schedule?
12. Do/did you not have an up-to-date schedule?
13. Do/did you have a spec?
14. Do/did you not have a spec?
15. Do/did programmers have quiet working conditions?
16. Do/did programmes not have quiet working conditions?
17. Do/did you use the best tools money can/could buy?
18. Do/did you not have the best tools money can/could
19. Do/did you have testers?
20. Do/did you not have testers?
21. Do/did new candidates write code during their interview?
22. Do/did new candidates not write code during their interview?
23. Do/did you do hallway usability testing?
24. Do/did you not do hallway usability testing?

After you have all the "yes" and "no" responses to these, you will know the level of "modern" and "old" styles of developing and delivering software. Now you get to decide how to direct the rest of the experiential based interview if you decide to let the candidate through to face-to-face more investment round(s).

I advise experiential interviewing during the face-to-face as it is a case of "under stress, we regress", and a lot of coaching can be quite stressful as very little is under the control of the coach who is at best influencing the situation! And any coach who has not mastered conflict management and resolution skills, personal attacks, helping people overcome their own anxieties etc can be quite damaging to your organisation.

f you're more focused on a coach who's technical background is less interesting, you could take a look at the coaching levels and the types of coaching and design similar Yes/No questions to try and understand the tangible hands-on experiences a personal, executive, soft skills, etc coach has.

I suggest at the beginning of the face-to-faces to do some spot-checks to check that whatever Yes/No questions you screened with were correctly interpreted, and that the candidate's response was accurate before proceeding into the simulation(s). Some people, you know, will say anything to get a role! :O

After the simulation assessment(s), ensure you and your assessment team form and document your own, subjective, fact-based, Delphi-style, assessments of each candidate.

My final question for the candidates: Ask each candidate face-to-face what their opinion is of the other candidates. You'll be or not surprised how many candidates know, or know of, the other candidates, and their face-to-face opinions can be quite informative! Also insightful is how they react to those coaches they don't know or know of.

So hopefully by now you have collected all the minimal data points to make a more informed decision about finding the right candidate - a round peg for a round hole / a square peg for a square hole - for your people's (!!) needs. Remember, past performance is no guarantee about future performance. But also remember this is a critical role to match the right person to - as any change agent will by the nature of the role be disrupting people's comfort zone(s). Including your own often.

Good luck with your search and selection process!

Lastly, please let me know how it all works out for you and your organisation. Remember the most important (top) line of the Agile Manifesto reframed is a bit like "we're doing it, and by doing it we discover new and better ways of doing it, and we share with others what we have learned so that we all benefit". That's "agile"!

Thankyou for supporting!

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!

What Is Agile For You What Is Agile For Us

So…what do you want to know?

I guess there are 3 readers this agile principles blog post is targeted at:

1. Total newcomer to the whole agile movement/thing
2. Someone who has had some brief training, or read a few books, or someone working next to a team “going agile”
3. Someone who just wants to understand when to reject agile and when to accept agile

What Is Agile For - And How Do I Learn Agile?

Firstly, welcome to this post (actually several that are linked!) about “agile”. I’ve said to myself for a number years, “do not go gentle into that good night” as many many have tried and most have only partially succeeded…the road to hell is paved with good intentions, and many brave good people who tried to communicate their "Eureka!"

To be inspired, and honour William Shakespeare, a little reminder from Hamlet, Act III, Scene 1 with agile updates:

To be [agile], or not to be [agile]: that is the question!
Whether 'tis nobler in the mind to suffer
The slings and arrows [mistakes] of outrageous fortune [delivery in the past],
Or to take arms [learn from the past] against a sea of troubles [complexity],
And by opposing [with a modern, learned mindset and approach] end them [deliver successfully and sustainably with a team that becomes a real competitive advantage]?

Note - I’m not trying to introduce or explain my interpretation of "agile" with this particular post. 

Instead I am going to connect various ways I have taught the 12 agile principles that are behind the agile manifesto to people who have attended my courses or people I have coached or led in organisations. I’ve read (and continue to read) (all) the books, speak to (all) the people and make my own mind up based on my experience.

I reckon if you and your team and/or peers follow the logic of the linked “HowTo Learn/HowTo Teach the agile principles” - and apply my guidance, you and your learners will discover for yourselves what these elusive, ambiguous, uncertain, etc principles mean for you and for your unique situation. And this deeper learning/realisation will set you up for great success in whatever you are going to attempt for the rest of your career.

A pushy declaration, I know. But I’ve been watching the people who really “got it” on my training and how their careers (thanks to linkedin!) have proceeded since 2010…and I am very pleased for them! And even more pleased that a simple manifesto and a few simple principles that were initially thought about in the software development and delivery space that I initially embarked my adult work life in ... have become to be understood as entirely applicable in all walks/works of life.

In the purest nutshell, by the dictionary, agile means "quick and nimble". These days it also has some ambiguous meanings appropriately and inappropriately added to the term, including "10,000 practices you can try to make your organisation quicker and nimbler" - also known as more competitive.

Agile Is [NOT] Too Much To Learn

I’m iterating this post, but over time the dedicated walk-throughs for learners, trainers, teachers, managers and the curious will expand here. Agile is really easy to explain and learn, but challenging to embody. You will see! 

• Agile in 3 Words
• Agile in 4 Words (in response to my earlier "3 word" attempt)
• Agile In a Nutshell
• Agile In a Nutshell Part 2
• Agile In a Nutshell Part 3
• Agile In a Nutshell Part 4
• Agile Principles 101
• Agile Principles 102
• Agile Principles 103
• Agile Principles 104
• Agile Principles 105

What Is Agile For?

My recommended “understand, embrace agile right in mind to do agile right and get the best benefits” and "read them now!" agile books currently are:

Perhaps Agile is not a What, perhaps it is a When, or maybe it is a How?

Thankyou for supporting! Happy learning "to be agile" :-)