An Agile Roadmap: The First Iteration
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.
I’ve started poking around the internet for how folks measure the success of a software development team. I noticed Scott Downey, a Scrum Master at Myspace, uses the following metrics:
Velocity, Burndown, Work Capacity and Commitment Accuracy.
and
- 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 Advanced?
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.
March 21st, 2009 at 4:59 pm
A Post-script:
I think the amount of hero stories we have about the iconic behavior of high-performing teams, can hamper our ability to bring a team there. Yes, we know we want short, effective high-energy meetings that address concrete issues; yes, we know we want to see continuous improvement in the work process of the team; yes, we know we want to see effective and flexible work plans created from within the team; yes, we know we want consistent shippable software. But all this can’t possibly happen, full-bore, at once!
We have to pick one level of proficiency, at a time, with concrete measures to check our progress. At Novice level, what does a highly competent, fluent Novice team do in a meeting? What does it look like?
How does that same meeting look at Intermediate level? Advanced? Superior/high-performing? This marks where I see the opportunity for real growth in Agile coaching and adoption. If we have a concrete roadmap with specific milestones, it turns the team into a fully informed crew of collaboraters, operating at their current fluency. They have the big-picture for when they need it, and they have the next tiny piece of skill work to do too, constantly interweaving the pieces into the greater puzzle. They know what to ask for, and what to expect.
April 19th, 2009 at 11:42 pm
I think that defining the higher levels of Agile fluency will be particularly difficult, because so few teams ever reach it. In my experience, most software teams barely function at all.
I was lucky enough to be part of a team of novices that functioned extremely well, far outperforming established teams of experienced programmers. My sense is that we reached “Advanced” competency, but without definitions that claim doesn’t mean much. One thing we did right was that we were learning and teaching each other and ourselves all the time.
April 20th, 2009 at 4:57 pm
I agree; I hope that somehow we can interview someone who has performed on a superior level team, to discover “what that looked like”.
But even “advanced” or “intermediate” would tell us a lot; if you can mine your own experiences of:
1. how the effectiveness of your team meetings changed over time, and what benchmarks you observed (who ran the meetings? how often? did that person change? how many people could do it, and when? how long did they last? what results did you achieve? how did that change over time?)
2. similarly, team planning, improving team processes (feedback, metrics, etc.), consistency and quality of software delivery – benchmarks, how did they change over time, emergent properties?
If novices say words, intermediates speak sentences, advanced speak paragraphs, and superiors speak exposition, how does this look on an agile team?
I think out there, we have enough experiences that we can sift this all out. It just takes mining that experience, don’t you think?