View details for any practice by clicking it on the map.

Agile Engineering Fluency

A model for undertanding the specific proficiencies involved in creating a good 2+star agile team.

Teams develop by gaining fluency at specific proficiencies. Those proficiencies seem to follow common patterns: later proficiencies require fluency at lower-level proficiencies.

Why fluency?

Fluency means the ability to perform some proficiency without thought and in all circumstances. You are fluent at the things that you do when you are behind on a critical deadline and dealing with a live-site issue in the middle of the night with a customer on the line. When the chips are down and stress is high, you will perform using the techniques at which you are fluent.

Outcomes are determined mostly by the stages at which everyone on your team has full fluency. The things at which you are aspiring (you do them on your best days) will not give consistent results. Your overall result will be determined more by your normal and worst days than by your best. For this reason, we recommend that teams focus on developing fluency at various levels, not just aspiring to basic capability at the proficiency.

Why not skip levels?

Some proficiencies are not even understandable or valued until fluency is achieved with some set of prior proficiencies. The tight inner dev loop (red-green-refactor, with minimum time in red and green steps) is one such.

Until a team has gained full fluency at reflective design, they will not be able to create good designs in such small steps. R-G-R is actively harmful for early teams. Yet once a team masters reflective design, R-G-R gives them more frequent data and assessment of the results of their designs: they couldn't get as good a design in any other way.

What the model gives you

This model lays out the Agile Engineering stages of proficiency. Each stage shows what it is, its pre-reqs, what it obsoletes, how to gain basic proficiency, how to attain full fluency, and some of the benefits and costs caused by fluency at that stage.

Contributing

The model is editable. We welcome insights. To contribute, fork the github project and send me a pull request. All of the data is stored in stages_data.js. You can edit the markdown live on the site, then copy the contents for this file from a textarea in the options pane (open using the little curled up corner in the lower-left).

All contributions are given under the license for this project. By issuing a pull request, you indicate that you understand all copyright and other IP issues, have rights to your contribution, and are releasing such rights to that contribution such that we can include it with the rest of the model for immediate publication.

Legend

Show
 
All