Chris Webb, now of PWC, shared a presentation that contained the now famous Deloitte Agile Landscape https://www.slideshare.net/ChrisWebb6/last-conference-2016-agile-landscape-presentation-v1 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:
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.