It takes skill to be "agile". Level up quick with these tips.

Oct 18, 2015 7 min read Pseudorandom

Many believe that to be successful, the members of an Agile team have to be a bunch of highly skilled full-stack hot shots. Some even go so far as to say that you should only hire skilled developers, or “senior” developers. Are the pundits just a bunch of arrogant elitists? Unfortunately, their elitist views aren’t entirely without merit. At their core, Agile teams are supposed to be self organizing and largely autonomous. Take the Scrum framework for example: the Product Owner decides what to build, but it’s up to the team to decide how to build it. Why is that dangerous if the team is composed of junior developers?

As a thought experiment, mercilessly yank your small team of novice developers out of their cozy cubicles and air drop them in a more life-threatening situation: a “special forces” team in some branch of the military. How long will they last if they’re all new recruits, or have only been through basic training? In this context, its obvious that they don’t have the skill and training for that level of autonomy. That’s why novice soldiers are put in with the larger body of the army, strictly following specific orders.

Our friend Dreyfus

The Dreyfus model of skill acquisition explains why this happens. It shows that a person in the process of acquiring a new skill goes through the following stages:

  • Novice
  • Advanced Beginner
  • Competent
  • Proficient  Practitioner
  • Expert (/* Of course, you’re not guaranteed to reach the “Expert” stage. You may stagnate somewhere in the “Novice” or “Advanced Beginner” stages. In fact, most people never get past the Advanced Beginner stage, which is kind of depressing. */)

So what’s the difference between these different stages, and what bearing does it have on you or your team members’ fitness for an Agile project? Well, here are the same stages with a brief (/* and incomplete */) description:

  • Novices want a recipe. They don’t understand or even care why; just spell out exactly what to do and they’ll do it, more or less.
  • Advanced Beginners don’t want the big picture. They generally stick the recipe but can venture out on their own somewhat. Just don’t try to force that big picture on them; they’ll probably brush you off, dismissing it as irrelevant. They want information fast. Run to Stack Overflow and download that “recipe”. Don’t bother with understanding why or when it works.
  • Competents can troubleshoot. They have enough knowledge to figure out why things aren’t working and can often fix stuff without bothering the experts too much. However they still aren’t very good at reflection and self-correction.
  • Proficient Practitioners can self-correct. These guys thirst for the big picture. They need to understand why they’re doing things and they’re able to apply maxims in their proper context. (Think DRY, YAGNI, KISS, One Rule - One Place, Encapsulate by Policy, SRP, OCP, LSP, ISP, DIP, etc, etc…)
  • Experts work from intuition. These are the guys and gals with vast experience that write amazing software, but have difficulty explaining how they were able to do it. It just “felt right”.
    (/* This is also why experts don’t always make the best mentors. They can’t always clearly explain their process. Competents and Proficients can be better for this role. Of course this isn’t usually a problem because true experts are very rare. */)

So imagine an “agile” team composed of novices. What will the software they produce look like, if it even makes it out the door? Most likely it will resemble an enormous amorphous kludge of various recipes downloaded from Stack Overflow. And if they’ve only ever built Widget X, every project to which they contribute is likely to emerge as a variation of Widget X, whether or not it suits the context. Show me the recipe! (/* This actually explains a lot of websites. :) */)

The situation won’t be quite as bad with Advanced Beginners and Competents, but they’ll need a significant amount of hand-holding nonetheless. For example Competents may hear about a principle like the Open/Closed Principle and treat it more like a recipe than a guiding principle within a context. The result of applying O/CP as a golden hammer is a wealth of anemic classes with little or no behavior. Or they read about software design patterns, become “patterns happy”, and apply them - all of them - to every project - to the letter. (/* The resulting products make a grown men whisper “OMG”. */)

Dunning Kruger

Novices are scary for another reason too, the Dunning-Kruger effect, wherein relatively unskilled individuals tend to grossly overestimate their actual ability (/* The flip side is that skilled individuals tend to underestimate their ability, assuming that if it’s easy for them, it’ll be easy for others too. */) . For instance almost everyone rates themselves as an above average driver. Obviously, someone in the population is overrating his abilities. If *everyone *were above average, well then above average would be the new average.

We see the Dunning-Kruger effect all the time in the software field. Someone gains the minimum viable knowledge about some package or framework, successfully applying a few recipes here and there, and thinks they have it “0wn3d”. Yes it’s annoying, and it makes you want to slap ’em upside the head. But remember that you and I have done it too. We’re probably doing it right now. Newton thought he had gravity pretty well nailed down. Along comes Einstein with general relativity and blows him out of the water. Then along comes… Oh yeah, we still believe in general relativity. But Hubble comes along and shows Einstein that there’s more to the universe than just the Milky Way. See, no matter how long you live or how smart you are, you won’t know everything, even if you’re the “expert”. A new mind-blowing experience is waiting for you just over the next event horizon.

So whaddyah gonna do about it?

Ideally your team would be composed entirely of Proficient Practitioners or Experts. But fast forward to the Real World: That’s probably not going to happen. Likely you and your current team aren’t a bunch of flying Aces either. Your company probably can’t even afford Proficients or Experts.

So what do you do? Train the people you do have. Just like the experts, we should always be looking for ways to do our work more efficiently and skillfully. Encourage each other to keep improving; share what you learn. Don’t hoard knowledge. And don’t leave your training in someone else’s hands either. Take responsibility for your own abilities. Andy Hunt, in Refactor your Wetware , encourages the creation of a “Pragmatic Investment Plan”, where you set S.M.A.R.T. goals for yourself and then draw up a road map of short-term objectives to help you reach those goals.

What are your goals? Have you read any good books lately? If you feel stuck in the Novice or Advanced Beginner stage, don’t worry about it. Just own it, then do something about it.

If you’re looking for some excellent books about software engineering and development, here are a few I think every developer should read, and in the following order (affiliate links ahead!–>):

Those are all pretty heady reads, though well-written and accessible. Design Patterns is a little long in both tongue and tooth. That’s why I recommend reading Head First Design Patterns first. Refactoring to Patterns also addresses some of the big issues with the venerable GoF book. For some lighter reading material, I highly recommend the following, in no particular order:

Some essential technology-specific reads:

  • Pro Git   (/* Seriously, everyone should learn Git these days. */)

  • Mastering Regular Expressions

  • UML Distilled   (/* Even though UML isn’t as popular anymore, it’s still used a lot in literature to convey software designs. */)

  • Insert books dealing with your specific technologies here

Happy reading and skill acquisition!

agile skills
Avatar
Ty Walls
Digital Construction Worker

Ty Walls is a software engineer in love with creating, learning, and teaching.