Why programmers can shine in an agile team

Why programmers can shine in an agile team

I am a Business Analyst and Scrum master. I work in agile teams since 2012. In the past 6 years, I have experienced the ups and downs of this framework. And I can understand why most of the people hate the Agile framework. But let me explain why you, as a developer, will love the Agile framework (if it is used properly), even it seems the whole world just hate this method (and blame on us, Scrum Masters!)

Why developers love agile


What developers can experience without agility

At the company where I work, we have an inside blog, where I read an interesting post from a senior developer. He just opened up his mind and give us an insight into a developer’s mindset related to project management. Believe me, he was brutally honest and brought up really good points what is the problem with the never-ending projects, and why every deadline cause problem for them. I am going to recall his statements (I cannot link his inside blog – that is why you need your own blog :D)

He summarized, that there is an old quote that I believe originated with NASA during the moon missions that goes something like this – “Faster, better, cheaper – pick two.”  This is also known as the project management triangle.



The problem is, that the customers want all these 3 assets. Conversations with the customers often happen at higher levels and without the input of developers. Thanks to this high-level discussions, how often does a developer hear about the deliverable date of a project before any solution design has even started?  Way too often, if you ask me!

What is worth, when a developer is pulled into time estimation without knowing too many details. Have you ever heard this sentence from your Project Manager: “Give me some LOEs on this, but I don’t want you to spend a lot of time on it”. I guess you do! But then those quick LOEs are used to communicate out as a timeline to the customer.

And then, you and your team are in a trap where:

  • a customer has ordered something, which has been promised to be fast (or at least be ready for the estimated deadline), cheap and the best quality in the world
  • a developer (+maybe the Project Manager) gave an LOE which will be required as a deadline in the future without knowing too many details (even it was not intended to be a deadline)
  • so this kind of teams start with the deadline first and work back from there

This situation is not healthy. Missing the deadline, frustration, scope cutting, long overtimes, exhaustion, and mutual dissatisfaction are coded into this methodology.

And it hap-pens e-ve-ry t-i-me when decisions have been made outside a development team. I bet you have already worked on this kind of project!


What has changed for the developers after we started to use the Agile framework?

In the last 2 years, I have participated in 2 major agile implementations as an agile coach. One was when we started to use scrum, and one was with another team when we started to use kanban. The difference between the two, and why we decided to use the one or the other is a different topic. But what is important, that implementing any agile method increased the developers’ productivity, engagement, and decreased their stress level and deadline phobia. 

How did it happen? It was simple. Developers got involved way early in the planning sessions. So they had at least a clue, what are the requirements from the user, they could give impact regarding the deadline and also they could be serious about quality.

So the fast-good-cheap triangle got another meaning, and we could prepare for any scenario (we could be fast and cheap but with the best quality which could be expected, and it was explained to the customer also).


For example, when we got a “hot lead” from a sales team, our product owner has started to participate in the specifications and requirement gathering meetings. He was there when every negotiation happened, and the requested software specifications started to formulated. What was our luck, that our product owner was our team’s business analyst before, so he knew all of our previous developments, platform from inside out. He know what was capable and what was not.

But whenever a feature has been mentioned, started to discussed during the specification, he just brought back this information and presented in a few minutes during the daily standups. Sometimes the negotiations was not successfull. And what? We have spend maybe 30 min with the updates and simple discussions after our daily meetings? Not a big deal. But when a negotiation got serious, and a contract has been signed, our team has been already prepared.

Our product owner never agreed on any deadline before he got back to the team for inputs. When the negotiations got serious, we discussed all of the requirements as an agile team, involving developers, business analysts, testers, so everybody was familiar with the requests. Even we story pointed them, and because we knouw or backlog prioritiy and our velocity, we could have a good guess, when the development which has been included in the contract can be finished.

Developers never felt missed out from anything, they were up to date with every question and requirements, and even the can have their questions asked and the product owner could got back to the customer with these questions. (Well the customers used to value these questions because it has been seen that we took their requests seriously). Because we hold daily standups, grooming and solutioning meetings every weeks, we were fast with these kind of requirements processing.

Implementing the agile framework has helped our developers to improve a lot, and even to deliver more valuable features in time for our customers.


I hope you felt the same with your agile transformation, Please share your thoughts with us in a comment!
If you found this post valuable, just share it yith your friends, community!

Leave a Reply

Social Share Buttons and Icons powered by Ultimatelysocial