I’ve saved the real zinger to kick this off; I haven’t seen anyone mention this, so pardon my ignorance if this has already come up in the dialogue over useful Agile learning models.
But I have to ask: why do I mostly see in Agile culture the two learning models, Dreyfus and Shu-Ha-Ri, that both specifically apply to individual progress? If we see Agile as a model of team collaboration (for the most part in the environment of software development), then don’t we need to measure the fluency/competency of the team, rather than individuals?
I think one can apply some Agile principles to one’s own track of personal growth, but as a team methodology, I think we must look at Agile as happening, or not happening, on a team level. The team sinks or swims together.
This means that we have to step further back from individual-mastery focus of Dreyfus and Shu Ha Ri.
We also have to separate Agile, as a software development methodology, from the goals it enables the team to accomplish more quickly and efficiently. Think about linguistic fluency; I won’t quiz you on your ability to name and employ all the different pedagogical tools your French teacher used to teach you French (flash cards, conversation partners, worksheets, quizzes, etc.). I’ll quiz you on your ability to speak fluent French. As we have seen, I can differentiate this fluency into different levels of proficiency.
How on Earth do we do that with an Agile team? We need to measure Agile success not in terms of fluency in Agile, but in terms of the work group’s fluency in software development.
Velocity, Burndown, Work Capacity and Commitment Accuracy.
- They are Hyper-Productive (>240% higher targeted value contribution)
- They have completed three successful Sprints consecutively
As I understand it (not having used Agile in the software development world, but rather in the outdoor recreation world), a “successful Sprint” means that the stories that the team committed to finishing in that Sprint, have gotten to done/done; finished, tested, integrated, with customer approval. Shippable code.
Also, just as a fundamental skillset, every work group must express some level of skill in their ability to plan their work as a team, to give feedback and improve their work, to run effective meetings; all these things too must act as milestones, in some fashion, on their way to consistently producing shippable software.
So, can we weave all of this into a whole, differentiate it into four (or so) levels of proficiency, with an embedded Appreciative Inquiry tack? We want to know what the team can do fluently, at every level, in addition to what they may struggle with.
What does any software team do competently, at Novice proficiency? What directly observable behaviors? What can we tease out, and say, “yeah…I would call this set of basic fluencies a Novice level”?
What does any software development team do fluently, and competently, at Intermediate? Empirically, what do we see? What seems to fit well here?
At Superior? How much experience do we have with Superior-level proficiency, in software development teams? We may have too much information on what we expect to see at this level, and too little for the others. So, what do we see at this high-performing level?
The ACTFL proficiency roadmap took quite a bit of development, back in its day. I think we can shake out a good roadmap from basic fluency to high-performing fluency pretty quickly, if we can dig out of our experience those consistent milestones that will help show us the route. Unfortunately, all of us probably have plenty of experience in what the team couldn’t do, but tried anyway, thus masking their level of fluency with the aura of struggle and failure. We don’t necessarily want to know where the team failed; we want to know, at each step, what the team could do competently and effortlessly, so that as Agile coaches we know exactly what to work on next. We have to create that nested hierarchy, so that every level the team has a solid grounding in success and fluency to take them to the next level of proficiency.
Any ideas? Looks like we may need a Part III.