Are Agile certifications worth it?

I recently came across this article on InfoWorld talking about “7 agile certifications to take your career to the next level”. I read it hoping to gain some insight on their opinion of how certification would benefit your career. Did they think the value came from the skills you learn from obtaining the certification or are there certain “Agile” qualifications sought after by employers?

Of course, I already have an opinion on the value of Agile certifications from my own experience – and I have to admit a large bias in that area. Now, whilst I’d actively encourage anyone to attend some of the various training courses and coaching sessions on offer to actively learn as much as they can (in addition to their own self-learning), I don’t personally place much value in Agile certifications. Most can be obtained after a short (in some cases, single day) course with a relatively easy exam at the end (many with near-guaranteed pass rates).

I find they’re usually required by companies that aren’t very agile and typically demonstrate a Dunning-Kruger failure to recognise genuine ability in others (and their own lack of knowledge) relating to Agile methodologies, practices and associated ways of working. This is usually evident from the questions they’ll ask you about your Agile experience. Instead of questions like:

• What are the biggest problems you’ve encountered using Agile methodologies – how would you try to tackle them?
• What was your role within the team and what other roles were included in the scope of your team’s work?
• How many teams were working on the same product – how did you work together successfully?
• What other methodologies do you have experience of – how do they compare?

You’ll probably just be asked:

Are you a “Certified ScrumMaster”?

It may (or may not) surprise you that this simple question is all too often the first (and only) question asked to assess my Agile credentials…

To me, most Agile certifications are purely a money making scheme for the companies that offer them – and are absolutely no guarantee of ability. The fact that a (very) high percentage of them require you to renew your qualification every 2-3 years – without any additional training or assessment – speaks volumes. Take them for what they are. If you can gain a qualification after just a few days training and with no practical application of those newly gained skills, great – just don’t place any more value on that piece of paper than you would for anyone else with a similar level of experience…

Common problems adopting Agile

Agile is not a silver bullet – despite what many claim. Agile doesn’t magically improve delivery, but it can bring significant improvements if approached in the right way. Let’s take a look at how not to introduce Agile into your organisation.

Beware of Waterfall in Agile clothing

I’ve found on many occasions that when a business issues a diktat that they will now implement Agile, it can be difficult for them to make the conceptual shift. Sometimes they’ll (unintentionally) keep their existing structure and processes and simply go through a renaming exercise instead. However, as we well know:

• The Scrum Master is not a project manager
• The Scrum Team are not all developers
• The Product Owner should not be a business analyst

So, if you have simply filled new Agile roles with the nearest equivalent traditional job title, there’s a strong chance you haven’t changed much about the way you work – instead you have simply renamed your current methodology to sound more “Agile”.

You’ll also see projects become “epics”, requirements may become “stories”, meetings are suddenly “stand-ups” and planning is now called “grooming” – but has any of this your improved your output?

Evangelists cause issues

Once a decision has been made to become “Agile”, an early step embarked upon for many businesses will be to recruit an Agile specialist. There are a two important issues with this approach:

First, these specialists are often aligned to one specific methodology (we’ll discuss that later). At worst, they will apply it dogmatically, without the pragmatism required to effect change in some larger or more traditional organisations.

Second, the criteria for recruiting these specialists is often that they have a relevant Agile certification, as that is the only way they have of assessing a candidate’s Agile credentials. For any methodology to be successful, sufficient practical experience is required. This doesn’t come from books or (one-day) courses.

Don’t default to Scrum

Scrum is Agile, but Agile is not Scrum. Scrum isn’t the only Agile methodology in town (even as I often default to using Scrum terminology…), yet it’s often adopted without any consideration about what it actually provides and what limitations it may have.

Scrum may be the best-fit for your needs, but you should always perform some analysis based on the specific situation you’ll be working in. Furthermore, don’t fall into the environment / scalability trap. All too often, I’ve seen Scrum trialled isolation, with a small independent team, then it gets rolled out across a much larger organisation with several teams (and their complex dependencies) thinking that it will just work. It very often doesn’t.

Each software methodology has its pros and cons – what looks good in theory may not be as successful in the real world. Try some out.

Narrow scope limits change

The most common mistake when trying to become more Agile, is that changed practices are only applied to the technical phases (usually just build). Requirements are still gathered up front, then there is a design phase. After the now “Agile” build phase, a test and release phase follows and so on. This is a red flag that you’re actually using a sequential methodology (like Waterfall…) instead of an agile methodology.

This is a problem because you’re going to be severely limiting the potential benefits that can be realised by adopting a more Agile approach by constraining the scope of change in this way. As many businesses eventually discover, the build phase is often the least of their problems when it comes to successful project management.

Sometimes other phases are actually included in the “Agile” scope, but they will occur in an isolation fashion instead of collaboratively. The scope of a Sprint is dictated by the business and Scrum Master (in private), rather than agreed by the team.

Divorced responsibility

Another pseudo Agile anti-pattern is “pushing (problems) over the fence”. This will typically take the form of the business expecting the Agile team to deliver requirements that haven’t been articulated or even formed yet – and then not being involved in the activities designed to find them out.

Issuing requirements akin to “whatever it does now” also demonstrates a distinct lack of stakeholder engagement. The business needs to take responsibility for ensuring their team has a complete understanding of their expectations if that is what they hope to deliver. Collaboration is one of the most important aspects of Agile and can be the most difficult culture to change.