Being an Agile developer


Knowledge workers are key to Agile

What does it take to be an agile developer?

Your team may be considering some Agile practices. Or maybe they’ve already started to adopt some of them and learned quite a bit about how to do planning, demo, retro, and so on. All good things, but here’s the catch: planning, or demo, or retro will not create value, will not code a feature, will not fix a defect. team members do! So, it is extremely important to thoroughly understand what are those things that an Agile developer should and shouldn’t do.

That’s what we’re going to talk about. Let’s get started.

Meet Tina, she’s an Agile developer.

Creating customer value, not code.

Tina keeps one thing above all. Would you guess it? Coding? No. Coding is just a means to an end. Creating customer value! That’s what Tina takes pride in. And this dictates her behavior. As a matter of fact, Tina is aware of the complete set of steps from coding, all the way to having that functionality in the hands of the customer. She’s not interested in creating more code. She’s interested, however, in seeing the code she’s written assisting her customer in achieving their goals. So, Tina will not just sit there and keep coding, but once some functionality has been coded out, she is immediately seeking to integrate with others. And once it’s been integrated, she wants to see it tested. She wants to see all of this happen within the same iteration. Because she knows that unless they integrate and test early and often, they are just deceiving themselves and are waiting for a big problem to happen with a lot rework coming out of the delayed test. So, she herself participates in testing. She writes her own unit tests, and, with other team members, they create higher-level automated acceptance tests; just a few a time, but they have an established, proven, sustainable routine. And that routine has a great side effect that Tina knows saved them lots and lots of effort: those tests—because they are sustainable over time—are also used for regression testing, over and over again.


Tina pays a lot of attention to clarity, good structure and maintainability of her code. If there are problems with code structure (something that happens; after all, it’s a complex endeavor to create software), she refactors the system to improve its structure, without postponing it. And all of this is not because Tina is some kind of perfectionist but because she knows that the way your code is structured determines the speed and the quality of development – it’s that simple. When the codebase looks like a bowl of spaghetti, pull one string and you have no idea what and where will go wrong; but it will. So, it’s all very simple: she’s aiming at a more predictable, faster process.

The team

Tina knows that team comes first. This doesn’t change the fact that Tina is a strong professional, busily working to grow her career. But over time she learned that great ideas, quality and speed come from collaboration. It’s the other pair of eyes that can spot a problem in your own code much easier that you yourself would, because you created it. It’s the conversation over a new idea that instantly reveals the pros and the cons of that idea and allows to quickly improve it together. So, Tina often resorts to pair work with other team members, calls for help, as needed, and is ready to offer help and has done so many times over. Also, Tina is not territorial about her code. As a matter of fact, her team has been through this quite a while ago, having realized the hard way that collective ownership over the code is better and they even try to facilitate that by rotating over various types of functionality, over time. This way a lot of improvements come from just the fact that a new owner gets a fresh look at the code. And they learn a lot this way from each other.

And in Tina’s mind (as well as in everybody else’s, on her team) what truly matters is the team victory and they can get to it every two weeks, as long as they act as a team. Collaborating, learning each-other’s craft, helping each other so that the iteration scope would be accomplished and then taking pride in that achievement together. Those are the moments of amazing unity mixed with a true sense of accomplishment. They are a pack and there’s hardly any problem they couldn’t solve together, and they know it!  

Learning from the customer

Lastly, Tina takes on every opportunity to learn directly from the customer. She takes advantage of every demo; the team does invite the customer and Tina often demonstrates the functionality she contributed to in the iteration, as do the others. But she’s also paying a lot of attention to how their system behaves in the production environment.

Taking action

Alright, what do you think is the most important step in your case to become an Agile developer? If you know the answer, well, that’s the step you should take, because it’s your professional career that matters here.    

Alex Yakyma

Alex Yakyma is the author of “Pursuing Enterprise Outcomes” and “The Rollout”. As a consultant, Alex is helping enterprises succeed with complex challenges. Throughout his career, he operated in multi-cultural, highly distributed environments. Alex has trained a large number of change agents and leaders whose key role is to help their organizations achieve higher effectiveness at pursuing business outcomes.

Explore more content

Improving in the moment

Seeing the opportunity
Read more

Unit and Integration Testing Overview

The two important types of testing <
Read more

Making Joy a Priority at Work

Source Content Available Here
Read more
Contact Us