Agile & Employee Satisfaction

Posted by:

Agile in ICT

In recent years, Agile has become one of the most highly used methodologies in the ICT industry. It’s being implemented by many companies to improve their end product on time and involves every team member.

However with agile, many questions arise concerning employee satisfaction in the execution of such a methodology. As company CEOs tend to be excited about the implementation of new methodologies knowing that it will profit them. And in the process some make promises to employees who actually undertake the procedures of the methodology.

Agile & employee satisfaction

Can there be a way of addressing human satisfaction related to tasks undertaken by each employee? And how can honesty and trustworthiness be taken into consideration? Can Agile break favoritism from the top members of the organization? The proposal to resolve such problems is to bring Agile on all those aspects, for these tendencies are then being exposed.

CEO’s tend to hide behind issues, considering the issues as HR related, whereas the bottom line is the end product.  Company owners are perceived to not care so much about the people who build their product, but about the status of the project.

Surface agile

So what happens is that business owners only adopt the surface of agile, resulting in a waterfall design in disguise; as total, in-depth agile adoption means that employees and their satisfaction are taken into consideration and form a key component of agile.

Let’s make a good methodology the best methodology by incorporating the needs of individuals at a workplace through total agile adoption. Let it be ‘My Agile’, ensuring that needs of employees are being addressed including the top management. Happy employees produce excellent products.


  • 8 questions you MUST contemplate and answer before going Agile
  • How to implement agile into your team

Interesting Infoware Studios Bookmarks


About the Author:

  Related Posts


  1. Wessel Blignaut  June 10, 2014

    I fully agree with your statement “So what happens is that business owners only adopt the surface of agile, resulting in a waterfall design in disguise”.

    As an advocate for Agile PM, I often see projects failing because the Agile principles/methodology are “boxed” into a traditional environment where team members have the gap to fall back to familiar ground (Waterfall principles) when they do not feel comfortable with the Agile approach., or they bend the rules to suit them. This WILL break the Agile methodology.

    What I also often see, is that people do not understand the environment their project exists in and assume that Agile PM is the “new Silver Bullet” that will wipe away all their project issues, without accessing the environment properly to determine whether Agile is the most appropriate methodology for that specific project. The end result is that some projects fail because the methodology applied did not suit the project.
    Agile has its limitations and some people tend to ignore that.

    Agile PM (Scrum specifically) have been proven in many fields over quite a number of years and I am of opinion that it is the people using it, that breaks it and not the methodology that’s flawed.