It’s Not All About Agile!

Chris Webb, now of PWC, shared a presentation that contained the now famous Deloitte Agile Landscape  as shown above.

In that presentation he highlighted the large number of development teams saying they are agile, and the wide variety of definitions of what that means.  One interesting observation was that “beginners use frameworks, experienced people use what works”.    I agree with that – frameworks are like tools – they are ways to enable less experienced designers and developers perform at higher levels.

Most, if not all the teams I work with, or invest in have embraced Agile, at least as a phrase if not a reality.  However, I wonder if they might be missing the boat.  Good software should have four attributes: it must be functionally correct (e.g. meet or exceed requirements), it must be understandable, it must be efficient, and it must be maintainable.   In my experience, an Agile approach, done well can enable the development of software that delivers those attributes.  But it can just as easily lead to the same garbage software developed in other approaches.  The variable?  Good or bad design.

Agile doesn’t eliminate the need for design.  It may break up some of the design tasks into smaller increments, and enable more opportunities for re-factoring but it still requires good design to be effective.

If I’m right, then the key is having people on the Agile team who can do good design.  So I’ve been thinking about how to evaluate team members experience to determine if they are likely to be good designers and identified six experiences that I would expect the designer to be able to demonstrate with real examples or evidence:

  • Core technical skills. The demonstrated ability to identify and use patterns, frameworks and library functions to solve problems.  Has she demonstrated core programming skills at some point.
  • Demonstrated experience refactoring or redeveloping. Has he had real experience developing a version 2 or a refactored version of software they developed.  Its only through experiencing and fixing the problems of an original design that one learns how to design better.
  • Proven quality of their design. What examples can she point to that demonstrate their designs are high quality?
  • How have they reused software and how has their software been reused. What examples can he give of how they used other’s functionality or technical code in their designs, and equally importantly what examples can they give of their design being sufficiently abstract to be reused.
  • How have their past design stood up to maintenance? What statistics or evidence can they give that their past systems had life and were able to be maintained and enhanced.  Check the track record.
  • How many different environments and languages have they mastered? I think that a good designer has to have learned to apply patterns and design practices across more than one environment.

In future posts I’m going to explore these six experiences in more depth and justify why I think they are key to identifying good designers.