Teaching Agile is like guiding a human to catch a non-descript fish in a river using their bare hands.
Somehow if you’ve succeeded/survived/thrived within Agile environments many times before, you might figure “hey that endorses me as a teacher of the Agile”. However, no matter of workshop or accreditation can prepare you for the kind of teaching that is taught within an emerging Agile environment. Like the environment itself, your teaching of it will evolve. How can you convince those new to Agile, that it’s going to organize the disruption that results from any iterative design process—from a process that delivers software (for example) fast and furiously, thriving in transparent and flat-like smaller teams, without heavy requirements (but changing ones), little to no up-front documentation or long review cycles? Certainly, not by attempting to define it because..
a. by the time I define it, it would have changed;
b. I couldn’t possibly define it fully because it was different every time I lived it;
c. My definition will be different than somebody else’s will be different than…and so on;
d. Every definition is as relevant as its successful implementation. Every war story, context dependent.
Ok then what if we went with some keywords associated with Agile that come up all the time, each with their own definition that could at least give someone a feel for the territory? But Agile, like any slippery member of the paraphyletic group of organisms, tends to shift and morph depending on the environment within which it transforms (‘it’ referring both to Agile and the environment). Familiar words no single human can completely agree upon since they are best defined in context, include scrumboard, scrum, burndown, stand-up, sprint, iterative, cycle, backlog, impediments, scrum master, velocity, product owner, development team or ________ team.
But I’m not about to define them all in this post. There are far sager wordsmiths. I am here to pompously declare however, that in some ways the best way to teach Agile is for an extant member of the hominin clade to live and breathe an Agile process…and…..fail at one. Of course the human mind loves to succeed before trying…loves to know how cold the river is before stepping in, how fast it runs to ensure balance, what dangers lurk within it in order to decide footwear, etc.. prior to coercing the entire body to jump into the water and grab that slippery gill- bearing craniate animal. Even if we slightly refine the analogy and fish from the safety of the shore, it’s easy to say that it’s impossible to know exactly what you’re going to get.
Anticipating that many of the readers of this post may in fact be human, and before casting line may want to at least be primed (if not warned) I am compelled to bait you by describing what might happen in an imaginary Agile environment—the same kinds of stories that Agile development teams can come to depend upon themselves for sublime angling—stories based on a user’s actual experience. Let’s pretend to live this one temporarily letting go of fishing analogies:
a. Brynn (whom we will describe here as a Project Manager although like many new PM’s considers herself to also be the Product Owner and has a tendency to micro-manage) has delicately and graciously identified a lovely and beautiful problem or pain that she thinks deserves to be solved by her and a team of people who are joining her (again, her perspective) on this particular iOS mobile software development expedition. (ex. As an Agile team member/lead, I need to properly identify a problem, so I can make sure I solve it from a customer’s POV vs my POV even though my POV is more better like)
b. She goes about understanding the problem from that elusive and somewhat ambiguous customer’s perspective (debating with her team who the actual customer is) with a variety of psychodemographic tools and/or empathic methods she has learned from her latest UX workshop.
c. She uses the magic translator app (or ‘brain’ in common parlance) to deconstruct each customer or user story (yes this is an inception moment) into an arguably indefinite number of features, which she and her team will never ever complete due to the inherent nature of the human mind to overscope (this post was originally intended to take me 15 minutes and 500 words with no drawings).
d. She converts these superbly demented features into a list of tasks using a metric system no one can agree on.
e. She and her team attempt to clearly articulate each of these tasks which are plopped into some board named after a violent ball/wrestling game hybrid that grown humans ‘play’. (yes a scrum board for the semantically obsessive). Her team decides to use a typical To Do, In Progress, Done chart to plot the tasks based on each user story.
f. She organizes most of them neatly using square stickies of rainbow colours (with a colour code per column) and adds the pink ones to a column usefully titled TO DO.
g. Those that her and her team think are somewhat completed (you never really completely complete any) are placed in another column irritatingly titled IN PROGRESS with barely an idea of how little or how much in progress they really are. Some more OCD oriented PM’s will likely assign a % per In Progress sticky task and/or hunt down team members regularly asking them to commit to their original estimate (which has a statistical probability of 16.67% or a 1 in 6 chance since a die is usually rolled and a number assigned), if only to feel a temporary measure of calm.
h. She (and likely only she, since barely anyone takes the time unless prompted or electro-motivated) moves that rare and lonely sticky that has not fallen to the ground, into the column called DONE, which gives team members a sense of relief (if they look) although that relief is temporary since there are always more tasks to do, and there is always one more sprint.
And everyone on the team accepts that the scrum board that is populated will only last a ____ number of days or weeks, in which:
1. only a portion of the entire deliverable will rest in a state of ambiguous completion;
2. the entire project may or may not shift in scope;
3. the entire project may actually ‘pivot’ from its original intention since the problem to solve also becomes more refined every sprint, and/or the ‘truer’ problem emerges.
4. Rinse and repeat c.-h. for the next sprint as colleague Larry Bafia would put it eloquently.
To be clear, what is disruptive about Agile is that it is different every time it attempts to ‘catch’ an elusive development process because the product or deliverable(s) is hybridizing the entire time. So that irritating organism we described earlier lacking limbs with digits is more like an adaptable and amorphous mimic octopus that is perfectly suited to the overall climate of rapid change and ever-evolving survivalist needs. You don’t agree to ‘do’ Agile. Otherwise it is aptly described as such:
It’s more accurate to say that Agile gets ‘done’ to you once you enter the zone of solving problems iteratively or of working on software products that launch in Beta and need continued refinement and versioning after launch based on user feedback or you agree to work on a product whose exact features have only been somewhat defined…..
AND sometimes you end up feeling like this.
Keep in mind that this reluctant teaser on teaching Agile was never really meant to give you a sense of comfort or relief, particularly if you are crazy enough to try and teach it to other humans. In fact there are many an article that exist to provide you with that. However, it is my experience that the best way to facilitate others to ‘pick up’ Agile is to encourage them to fully engross themselves in a real project that requires an Agile approach. Aspects of Agile and an agile mindset are certainly facilitated at the Master of Digital Media Program where they let me roam free during the day and all learners eventually have to contend with the reality of adapting within an Agile managed project.
That’s not to say you can learn about Agile by reading a manual or taking a workshop. You can also learn all there is to know about fishing that way. Eventually, though you need to fish. Now, try to describe how you catch a fish to someone without them being on the end of a spear, net or rod ‘n reel beside you.
To properly conclude, The Way of the Agile is to…oh hang on ‘that’ Agile just changed and everything you just read is now obsolete and needs to be refined. Luckily I can scratch this post off my burndown.
God speed and don’t forget to scrum….this scrum.