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 original email in quotes, my response in blue):

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?