“How Does Agile Make Me a Better Developer?”


In this blog post, I’ll share a bit of a conversation I was having with a participant of my CSM course, who had his team ask provoking questions. I’ll share the questions and my responses. Remember that this is a conversation piece, so I can’t guarantee it’s more than opinions :).
Snippety snip, start the email here (the participants text in blue, my response in black):
> I had a great retrospective with the team that was having buy-in
> issues last week and they expressed some fundamental questions
> that they had not been given answers to.

There are no single answers, but I’ll try to give some possible perspectives.

> How does Agile make me a better developer?

Well, “Agile” doesn’t :). But I guess that’s twisting words :/. I guess by “Agile” they mean the combination of all three layers – mindset, control framework, and practices & tools. So let’s take Agile as that.

Still, I feel the answer is “no”. It is they themselves who make them better developers, by learning a new consistent framework they can choose to use when they feel it delivers higher value. Yes, there are many people who swear by Agile approach, because it let’s them deliver much higher quality code, deliver it faster, spend much less time debugging, and having fun working with a close-knit group of colleagues towards a meaningful shared goal. Yes, that is available to almost anyone who wants to continually improve themselves. No, it doesn’t come for free – they have to put themselves to learning it.

Also, as a point of view, as the number of people who can write virtually error-free code on first pass and deliver highly maintainable code effectively, that skill level turns from competitive advantage to pre-requisite in the next, say, ten years. Having only traditional skillset, conversely, turns from still competitive (because employers don’t still know much better) to competitive disadvantage. I mean, I would not hire a person who didn’t know how to deliver Agile code, or would not be willing to put themselves to learning it.

> How does this process make me happier in my Job?

The “process” doesn’t, again :). Badly done Agile will make their lives miserable, because it will take the old framework, and add expectations of doing faster and more on top of it.

If the environment is set up to support Agile, that is, there are managers who allow (and support) the team to self-organized, participate actively in removing impediments, assign sufficient authority to a PO who can take ownership of the direction, give the SM sufficient time and support to focus on the role, etc., then the team can focus on learning to do proper Agile at technical level and to learn working together as a cross-functional team.

There usually is a period where it gets worse before it starts getting better. XP requires focus and commitment, and practice. TDD will be difficult at first, especially if there is legacy code which is not supportive of code level testing. Pair programming will feel awkward until skill & knowledge levels start to level a bit. Continuous integration and test automation will require learning new skills and establishing new tools, until they start to show benefit by allowing faster feedback on errors.

I recommend the team, assuming they want to go for XP and Agile, to set themselves a two month period where they focus primarily on the process and learning to do it properly. Delivering features is secondary (though not irrelevant). Speed will come naturally. Make sure that your management understands the team’s need for learning new ways and grant them the time. If all goes well, after two months they will be where they would’ve been without XP, but now with a faster process, better collaboration, more shared knowledge, and, likely, happier people. No guarantees, but that’s what I often see and hear. 🙂

But if Agile is supported by organization (or benevolently “allowed” and not actively prevented), it does increase the amount of autonomy and mastery in the work. If you have a good PO, it will also increase the purpose of the work. And those are the secret sauce of motivation.

> What Defines “Productive” for a Developer in the Agile way of thinking?

Shortly, the team has a greater capacity to deliver value to PO and customers. This may be numbers (in terms of features), technical quality, or feature value. Ideally, it is a combination of all three.

Also, we should get rid of the idea of individual productivity and look at the team level. Traditional approach is very poor at leveraging collaborative effort – the power of teams. For people who have not been in a real team, they don’t know what they are missing from their professional life. “Aren’t you curious?”

End of the snippety snip part.

As the reader of this post, what elements would add (or modify) to my above comments?

2 Responses to ““How Does Agile Make Me a Better Developer?””

  1. Ben Davis Says:

    That’s stupidest thing I ever read! Agile decrease debugging time?!?! What are you smoking?! Could you, please, explain how could you support such a bold claim? Have you develop, IDK, anything? Probably not. And this pearl I have to site: “write virtually error-free code on first pass and deliver highly maintainable code effectively”. What could possible any sane person say after such outburst?! Well, I think normal ones will speak with their feet. You are speaking ONLY about developers, where are BAs in your mantra? Are they fell of the Earth all of the sudden? Requirements are vital part of the successful project and if you are missing on that one you destined to fail.

    • Petri Heiramo Says:

      Hi, I can’t fully follow your comment. How familiar are you yourself with Extreme Programming (and associated techniques)? It is some time since I personally developed code, and I’m willing to admit that I don’t have the development skills to actually use XP in work, but I’ve directly worked with people who have applied them very successfully. So I’m echoing the things they have said and that I have observed them achieve. I’ve tried some of the techniques in small scale, so I do have some appreciation of how to do them and that they are not necessarily easy things to adopt (as they represent a major change in how to develop code).

      Anyway, you are very right about the BA’s. I was addressing questions by developers, so I used language for them. I very much think, like you do, that understanding what is the right thing to do is critical. It doesn’t make any difference how quickly the team can develop or how error free the code is if they are building the wrong thing. While in Scrum, the main responsibility of making the right thing is on the PO, good BA’s are very important in helping the PO with the priorities and the details.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: