Agile Dilemma: are Managers Happy, Developers are Unhappy or the Other Way Around

The purpose of Agile is to deliver value and delight customer. But better make employees happy as well.

Agile has emerged as the mainstream project management philosophy and methodology, does it make managers happy, developers unhappy, or the other way around, or ideally, can it make everyone happy as a fountain of improvement, interaction and incremental?

Agile is done correctly, developers are the first to be happy, and then overtime managers are happy. Developers should have the more freedom to choose how they implement the best solutions, using right architecture, design and agile engineering methods that assure product quality. Developers need not be told what they have to do, rather, they need to know what is expected of them as the outcome. 

If the agile values and principles are understood properly, they can really add value to projects and people involved. The developers actually like Agile. They don't think it's the holy grail, they feel it works better than Waterfall, as it gives them freedom to explore, make and change as needed, and deliver value much earlier. People blindly follow some rules, but do not have that ideology, that results in failures and unhappy people. The managers, the clients and even the team need to have the Agile mindset before they work on a project. That is the biggest miss found in organizations who say they are Agile. 

It depends from what angle you are looking at it; if you are using agile to double the velocity of team and continuous improvement, then it can be too much pressure on team, but if it is about empowerment of agile teams to make their own decision and commitments, or in self-organized (Scrum) teams, developers are empowered and happy, as long as Scrum master protect them from external interference; but management might feel uncomfortable, losing some kind of power regarding the team; or lack of management discipline may cause the project failure. In the other situation where the project was on schedule, but not on value: The manager was ‘happy’ because the project seems to be delivered on time, but the team was unhappy because of the bad quality of the source code. Result: the software was impossible to maintain, to evolve, and a lot of conflicts have appeared with the hierarchy.  It is important to find the right balance.

Autonomy is a key ingredient to the success of agile: It’s actually a rather important need for the best work to be completed. Scrum and Agile are for the developers to be happy and hereby produce. Managers are secondary, but will eventually be happy because mandated agile adoption can be met with unhappiness. Further, the company, regardless of their practices, can be an unhappy place if the leadership team is lacking. Imagine how a manager could be truly happy if their team isn’t curious to know how you are measuring the happiness/unhappiness levels of developers and managers. Have there been any attempts to identify what "happiness" is to them? Is the evidence showing up to work with a smile on their face? Being nice to co-workers? Bugs/line of code? Or is it how long they have been with the company ...not looking elsewhere for employment.

Happiness seems like such an elusive thing to quantify. Maybe it’s just one of those things that we know when we see it.There just seem to be so many variables to consider. Still, the very meaning of Agile philosophy is to set the guidelines and build more productive and happy working environment for both individuals and teams; for both engineers and managers, with result to bring happy customers as well. 

Posted in: Agile,CIO Debate