Cheating in Agile
There are many things in the Agile and Lean Startup communities that enchant me. Being of a social reform political tendency, the ideas of self-managing teams¹, paying team members enough so that money is not an issue of constant concern and they can focus on doing great work², all members being seen as equal and contributing with their different views to creat a multi-skilled team¹ are all so familiar and at the same time delightfully utopic that I cannot avoid wanting to do this for the rest of my days.
However, we live in a world of ingrained Fordism, of industrial, serial-production management. This management method was created to deal with physical labor of marginalized workers, and yet we are constantly being submitted to practices that, even when good-intended (like bonuses for results), simply don’t work for our field of production².
When you offer a bonus for achieving a specific result, you create a scenario in which innovation and quality are left aside and the only goal in sight is that given result, even if there are better, cheaper, fantastic other ways of creating even more value for your employer. You start working for the sake of the bonus and losing all creative work can add to your career and your company.
There are several issues that derive from this mindset and echo in the Agile community. The one that bothers me more frequently is the idea that standardized tests are more valuable than experience. Some time ago, I was discussing certifications with a Scrum Master I work with, and he mentioned his certification was less valuable, because the test was too easy, or the institute offered the training, but no test. I asked him what would be a better option, and he mentioned another certification, for which training was not necessary, but the test was hard. I was baffled.
The reason this belief that tough tests bothers me is the same as the bonus. In my experience, I’ve seen people memorizing the Agile principals, using cards and techniques. I’ve seen team members that are constantly disrupting team work and act as dictators inside a scrum team brag about having scored so many points in the certification test. I’ve had to deal with a team of certified individuals that refused to work with estimation because they felt that transparency was over-rated.
Tell me, are any of them really better than someone that has no certification, but truly lives by Agile’s principles?
Agile is a mindset. It’s a deep and sometimes painful adoption of culture. In my book, a certified professional that constantly acts against the principles is no agilist, but a cheater. They are no better than someone who took notes to the test and hid them under their palm. So don’t be that person. Be someone you want to work with, who sees criticism as a way to improve and experience as the only way to check if you’re right or wrong.
Having a certification apparently makes people relax and gather a sense of self-worth and authority that go against everything the Agile mindset stands for. Does that mean we should stop certifying people? Certainly not. But we need to address the dishonesty factor that comes from the laid-back “I can’t be questioned” attitude that follows certification. People literally say “I am certified!” and then ensue in the most destructive, unlike-Agile behavior. We need training. We need empathy. We need honesty. We need courage. We need focus on interactions, NOT PROCESSES.
Clearly, standardized tests are not being efficient. Maybe we could remodel certifications, so that the team and the trainer go through a series of real-life activities, and the certification is a result of the real-life application of knowledge in those activities, including criteria as empathy, listening to criticism, prioritizing people over processes, and being able to identify your strengths and weaknesses to start working on them.
Or maybe I’m just a dreamer.
I just hope I’m not the only one.
If you like this post, don’t forget to recommend and share it. Check out more great articles at Code Like A Girl.