Going AGILE. R.I.P Mina
Today almost every job description in software business has requirement of knowing agile methodologies. While it’s often good to do things agile, the requirement itself doesn’t make much sense. It’s like requiring the applicants to know how to brush their teeth — every developer who is abreast of the times knows how and does it regularly on daily basis. Or at least they should.
I can still remember the days when all agile methodologies were new (at least to where I worked at that time). That was about 8 years ago today. Moving to agile at that time required huge amount of effort and lot of people were recruited just to coach people in the agile way of doing things. For some this actually improved productivity but for teams like ours, were we already worked in somewhat agile mode, it only caused more pain. That time the requirement was added to every new job description automatically even the position did not have anything to do with software development.
Thing that bugs me about the requirement is that agile methodologies aren’t necessarily used in the company at all — it’s just something that a job description should include because it’s hip. In almost every organization I have worked, the Agile Manifesto values and principles are not followed or are only followed partially. This makes the requirement for new employees even more obsolete.
While it, in most cases, makes no sense to do agile using Scrum or some other agile framework strictly by the book, it would still make sense to actually use agile in some magnitude if you are requiring it from your employees. Especially the Manifesto values “ Working Software Over Comprehensive Documentation” and “ Individuals and interactions over processes and tools” are many times forgotten. This is unfortunately true at least for most bigger companies.
Root of the problem
I have worked as Scrum master for many teams over the past years. The problem hardly ever comes from the team as most of the agile violations are forced by the project or quality management. Pressuring teams to work with cumbersome processes and doing superfluous documentation is not the right way of getting things done. It is also very frustrating for the developers and makes the Agile word to be replaced with good old Waterfall. I would recommend for you to also read this article by ayasin about the same problem.
Solution
To start solving the problem you should first let your developers do their job and concentrate on developing software. Going further you should pay close attention to what your developers have to say of existing or prepared processes. Listen very carefully especially if you are a manager without engineering experience.
While doing these won’t necessarily solve all your problems, I can assure that it’s the first step for better tomorrow. Take the jump to the cold water and cancel all unnecessary meetings, walk your processes through once again with your development and most importantly don’t interrupt your developers flow.
Task for you
Next time you write a job description for open position please save yourself some typing and leave the requirement for agile methodologies knowledge out of it. And if you are lucky enough to get an interview to place with the requirement please do yourself a favor and ask how exactly are the agile methodologies used in the company.
Extra task: Leave me a comment what kind of problems have you seen in your organization and how much do you follow the Manifesto? Or have you completely dropped the agile way of doing things and why?
I am Heikki Hellgren, Software developer and technology enthusiast working at Elektrobit Automotive. My interests are in software construction, tools, automatic testing and all the new and cool stuff like AI and autonomous driving. You can follow me on Medium and Twitter. Also you can check out my website for more information.