So You Really Want to be an Agile Developer?
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?
Faux Agile
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.
Full-On Agile
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?
– Bob
Think Different 
I don’t quite agree on your definition of an Agile developer. In fact, I don’t even think the term makes any sense. I do agree with you about the concept of an agile team being truly cross-functional, self-organising and sharing responsibilities. But to that end there is no such thing as an Agile developer, Agile tester, etc. There are only individuals who work in such a team and carry out whatever activities are required to deliver the product (i.e. usually analysis, development, testing, etc. – activities, not roles).
To my mind, if anything an Agile developer is a developer who works in a cross-functional team in an organisation which has transitioned to reject traditional project approaches and instead has adopted Agile principles in an effort to be agile (i.e. being able to quickly respond to change in order to gain competitive advantage).
However, something I have been thinking a lot about lately is the flawed concept of an “agile team”. Calling a team alone agile implies it is sitting within an organisation that has not embraced an agile philosophy. If this is true, how exactly is the team agile? Yes it may be cross-functional, self-organising, working at a sustainable pace etc. but to me software agility at its core is about exactly that – agility. If the teams within the business are not able to change what they are working on at a moment’s notice in order to shift to a new stream of value then there is no agility. And the teams will only be able to do this if the organisation as a whole has embraced Agile in terms of principles, practices and philosophy.
Hi Neil,
Thanks once again for joining the conversation. I tend to agree with your observation that the term “Agile developer” fails to make much sense. I only use it here because it’s the term prevailing in e.g. Scrum teams, and for want of a better label that folks can relate to.
And I very much agree with your view on the flawed assumptions implicit in the term “Agile team”. You may have heard about this thing called FlowChain? 😉
For the record, until and unless organisations really embrace the complementary ideas of “Whole product” and “incremental delivery (into production)”, then the “Agile team” will remain a dysfunctional ghetto. Once embraced, the need for an “Agile team” dissolves, leaving more effective organisations to get on with the business of developing valuable products and services – feature by feature – in response to the ever-changing ebb-and-flow of market demand.
– Bob
Yes, nice catalog of the typical anti-patterns found in semi-agile approaches.
I assume you are using a fairly wide definition of developer (and development team) though. For me it is enough that salespeople, and marketing experts, and IT administrators, and the janitor,support staff, the accountant and a secretary (and everything else you need, for non software projects the list could be pretty long) are on the same cross-functional team. It doesn’t necessarily mean that all the guys doing programming will definitely have to say create the magazine ad in illustrator, AND keep the books, AND answer the phone when suppliers call. (Although considering it isn’t a team once you get more than 10 people in it, it probably does mean they will be doing a lot of other activities apart from programming).
Personally I would love to be a developer on such a full-on Agile team. Especially where the product is not 100% software. Imagine coming in to an automotive manufacturing team as a programmer, and swarming on a mechanical engineering task. Now that is what cross-functionalism is all about!
I’d be interested in hearing how people go about actually putting together a team of true “cross functional” people. Where do they find them? In practice, there’s no such thing as a team of 5-10 people where everyone can do anything and everything equally well.
It’s hard enough to get skilled people that are cross functional across the domain of development. And it’s great that they are self organized and take responsibility for whatever they are supposed to make. But that they should do everything from idea to finished product makes little sense to me.
My guess is that most developers will answer a definite NO! to your opening question. 🙂
I think the question is not whether someone wants to be a full-on agile developer, but rather who is capable of being full-on agile developer. Most people (not only programmers) in SW development organizations I saw seem to live in a shell pretending the product is created solely be the sum of involved forces neglecting the synergy of cross-functionality and swarming. From what I saw only a tiny fraction is capable to come out of the shell, so many organizations have to live with mediocre team members (albeit excellent programmers/testers/managers), left alone most of the organizations accepting mediocre programmers/testers/managers as the reality.
Yes is the answer, yes I do. This will however never happen when there is even a sniff of command and control style management. The question is whether being ‘more agile’ brings benefits over being ‘less agile’? Do the benefits occur on a continuum or do you only reap a benefit if you go ‘all in’?
@Stuart You and Sergey are spot on. I don’t know if there is an agile benefits continuum, but I suspect that the answer is that it is non-linear. Let’s say my boss eagerly adopts the agile concept of ‘release working code frequently.’ Let’s also say that he is old school, and views tests as ‘not working code’. If I do TDD and my colleagues don’t, who releases working code more frequently? Yes, it depends on the definition of working, but who (in this situation) defines that? It’s not me and it’s not the end-user. It’s my boss. This is just one possible example.
Alright, based on the above list I see now what Agile is not. However this does not tell exactly what the Agile is. I would like to see a list of items describing what Agile is.
Yay! Just what I do. I talk to the users, design the software, write it, build it, then deploy it instantly to all users (one click deploy ftw). I keep my todo list on a 5 square per inch composition book (2.99 at Office Depot). Surprisingly fast and easy.
The goal is to have every people involved in an activity (for example a project) know what other people involved are going to do. Any specialist face some kind of problem and the others members, involved in other kind of activities, should know that problem and do his best to help.
I have had the pleasure of being full-agile for a while now but I must point out that you are not describing the agile team that IS responsible for most (if not all) of these things. I hope you will clarify that the agilest team has all of these components contained within it, so long as the team was created with agile in mind.
I do agree with almost all points mentioned – we don’t need any roles on a team that are not adding value! The only objection I have is the Scrum Master. If this role is done right (and that’s almost never the case), Scrum Master is a full time job adding tremendous value to a product. The Scrum master constantly seeks ways to remove the sticks and stones that lie in the team’s way and thus enables the team to immerse themselves in all other value-adding tasks without interruption. However, if a Scrum Master sees himself as a kind of project manager, consultant, head of the team or anything, he is truly worthless and you’d be better of without that role. So go and find one of the few good Scrum Masters out there!
Pingback: Faux Agile « Res Technicum
Loved the definiation of Faux Agile!
Agile developer? What does it mean? LOL Agile development is good on some situations but not all. Nothing is a solve-all, but it doesn’t mean it is not good!
A collaborative, self-managing team will be successful no matter what methodology they use. Unfortunately such teams are only slightly less rare than unicorns (that is, I’ve been on one such team, but no unicorns to date). If you have any advice on finding such a team, blog that.
“A collaborative, self-managing team” is a principle promoted by Agile (which is not a methodology, by the way).
There is far too much talk these days about methodology, process, and management. Writing software has been “Managed” to Death. (Usually by people who do not code). I day – Code, follow, or get out of the way. Take your money sucking agile with you. It does not work. It adds little and costs too much. Leave the developers alone and let them do what they do. Stop trying to manage things to the literal “Letter of the code”. Now please, tell me I am wrong. Its ok, that’s what you guys do all day… talk. I know you won’t appreciate this position because you are all enjoying your confirmation bias little “agile fest”.
I hear if its managed well enough, you don’t even need developers.
“Code, follow or get out of the way” – Do you think code is all that matters in production? If so, why? Why do you feel you can give me such a set of options to choose from? For the record, I can, still do and have coded. Is that the only thing required for success? In my opinion, no. Would I follow you? No. Would I choose to get out of your way? No. Would I even like to pick from your set of options? No. Why? Because I feel you’re fencing me in which is somewhat ironic as your comment to me reads as “Don’t fence me in”.
“Take your money sucking agile with you” – How much money is sucked up (I prefer lost) by developers focusing on code rather than interacting with customers or understanding how their design choices make operational work with the systems they create error prone and diagnosis of problems impossible? I can tell you how much I’m paying developers, I can tell you how many times they’ve shipped stuff that isn’t fit for purpose and had to re-work it because they focused just on code. I can tell you how many days they spent doing that and can thus give you a very big cash figure representing waste. How much money do you reckon agile costs and how have you come to a figure?
“I know you won’t appreciate this position because you are all enjoying your confirmation bias little “agile fest”.” – I don’t appreciate your position because it’s confrontational and non-discussive. My only bias is to ship something worth a damn, I’d like to hear more about what you would like to do and how you plan on achieving it and why you think your approach is better than others.
I won’t demand that you answer any of those questions, I would hope however that you might see I’m inviting you to a discussion.
If this is the definition of an Agile team, then I don’t want it. I am a developer, so I like to write code. I don’t want to write requirements, I don’t want to test, and I don’t want to write user manuals. I have done these things in the past, so it’s not that I’m not good at them, I just prefer programming so that’s all I want to do.
This is not a closed-minded viewpoint. My company is a large financial firm that will never be the agile that you define. But we are trying to follow some important practices such as code reviews and meeting and talking directly with the users of the software to see what they want. I find these meetings with the users very enjoyable and enlightening. But I also think that there are some that are just better than others at certain things. My team does have a business analyst that is a total rock star. She is always on top of the requirements, she tests and finds errors that even the testers miss, and she is tuned in to the business and can make suggestions based on how they use the system. So I appreciate having multiple skill sets that can be drawn on when needed, but I don’t think you need to be everything all of the time. At the end of the day, the happiness and satisfaction of the user is most important, no matter what methodology you choose. The user doesn’t care about waterfall/faux agile/agile or whatever they just want working software.
Lovely post, and even comments. Enjoyed every bit.
While I do value agile techniques, and employ them a lot, I don’t consider myself an agile programmer. And I did my best over the years to resist to management efforts to transition development to an agile process. Why? Because more often than not agile processes are misused – the focus on flexibility is used as an excuse for bad planning, stupid change requests, and a lot of resource waste. And it is this waste, and this particular type of waste, that causes burnout – passionate programmers will happily work long hours if they think they produce something valuable, but won’t be able to stick to the job for as little as four hours a day if they feel that what they do is nonsense.
So my motivation for non-agile methods is not that I’m trying to avoid stuff which most programmers don’t like. Agile is like a fragile ecosystem: very difficult to set up, very easy to destroy/pervert. OTOH, TDD, frequent deliveries, intense and frequent communication with all involved stakeholders, and easy adaptation to change aren’t necessarily a monopoly of agile methods.
Great post. I was checking continuously this weblog
and I am impressed! Extremely helpful information particularly
the remaining part 🙂 I care for such info a lot.
I used to be looking for this particular info for a very lengthy time.
Thank you and best of luck.
Yes, I do.