So You Really Want to be an Agile Developer?
What does it mean to be an Agile Developer? Where does that path lead? I’m wondering how many developers out there have ever had the opportunity to find out. And for those – few, I suggest – who have, did they like it as much as I have?
By now I think many folks are aware of “faux Agile”. Groups of people, rarely even worthy of the title “teams”, where folks go through the motions of “doing agile”, typically at the behest of managers who want “productivity” or some other – often imagined and nebulous – agile benefits, but who remain unwilling to allow the groups to adopt many, if any, of the core Agile behaviours.
Agile as the Manifesto Intended
For the rarer case, where circumstances are more favourable, folks can indeed feel happier to have the opportunity to “do Agile” – to some extent “as the Agile Manifesto authors intended”. But even for these folks, and yes we can assume many of them will be more like teams than mere groups, many will not have the opportunity to experience “full-on” agile development.
What is full-on Agile? Do we need it?
For me, full-on Agile is “Agile as the manifesto authors intended”, but with the knobs turned-up to 11.
Maybe it’s going to be easier to explain by listing what full-on Agile isn’t:
- It’s not having Business Analysts responsible for the requirements.
- It’s not having a Scrum Master, Agile coach, or some other functionary who doesn’t “do development”.
- It’s not having Architects responsible for the product’s features, interfaces or internal structure.
- It’s not having Product Owners between customers and the development team.
- It’s not having developers producing software separate from authors writing product manuals, separate from business folks designing a service on top of the software, separate from sales and marketing folks wondering how to sell the final product.
- It’s not having managers hiring new team members, shifting folks between teams, stipulating tools and methods.
- It’s not having Project Managers doing budgets, tracking costs, maintaining risk registers and issues lists, negotiating with customers.
- It’s not have a test team checking the outputs of the development team.
- It’s not even having testers working with developers to create tests before or during development of a feature.
- It’s not having a Quality Manager stipulating coding standards, test coverage targets, or processes to conform to.
- It’s not having metrics people (or Scrum Masters, or Project Managers) tracking velocity, burn-down, value delivered, or whatever.
It’s not that all the above activities are unnecessary. Far from it. It’s a matter of who does them, who takes responsibility for them. As I see it, “full-on Agile” means that the development team (collectively) makes sure all these things get done (and decides which of them need to be done, which actually add value).
This has at least one major consequence – developers find themselves doing many things other than those they traditionally love, other than those they might feel are “the developers’ job”. (And, incidentally, other specialists on the team finding themselves doing many things outside their established specialisms).
Hence my opening question: Do you really want to be a full-on Agile Developer?