Analyzing Agile Job Descriptions

Finding a Good Agile Organization

You prefer to work in an Agile manner. You’re reviewing job descriptions because you’re in the market for a new opportunity.

You are also aware many organizations claim to be Agile because they want to be seen as progressive. But they don’t likely align to Agility.

Unfortunately it is difficult to determine the Agile maturity of an organization until you figuratively “get behind its doors.” By then, you have passed the commitment point.

If only it were possible to get some sense of the Agile maturity in an organization before you took the job!

There are no absolute tests, but my next few articles will provide suggestions on what to look for and what to ask.  After all, a job interview should be a two-way mutually beneficial evaluation for suitability.

This article focuses on disseminating a job description for Agility.

There are often clues within a job description. You just have to take a look at the language and terminology through an Agile lens.

Red Flags

Sometimes it’s obvious right in the job description that an organization doesn’t “get it”. Here are a few examples:

• It looks like a project role posting that just had the titles changed to align with an Agile approach (i.e. they substituted Scrum Master for Project Manager).
• The role is specific to one domain (e.g. primarily focused on testing, documenting, analysis, planning, or coding).
• There is no indication that there will be experimentation or empowerment of the team to evolve a solution.
• There is little to no mention about determining, measuring, servicing or solving customer issues or needs.

These are all indicators the organization likely does not have an Agile mindset. It doesn’t really understand what Agility is.

Similarly, sometimes the organizational structure of the potential job may provide clues.

If the role will functionally report to a department or manager of similar type roles (e.g. to a Manager of QA, Director of QA, the Architecture Department, Compliance and Audit, etc.) instead of to a team, service, product line or value stream then the organization is likely more matrix or silo-oriented rather than team or product/service focused.

These are cautions you may not have the opportunity to work in a highly collaborative team-based environment.

Dig a Little Deeper

Sometimes the clues may be less obvious.  Words like “resource”, “manage”, “schedule”, “report”, “status”, “mitigate”, and “update” in the job description suggest expectations may align more with a traditional project approach.

These words are often associated with project-based command and control development approaches. Caution should be used when applying for these jobs.

To be clear, these words aren’t show-stoppers that indicate an organization hasn’t embraced Agility.  But they are strong indicators you should do more in-depth investigation to determine its level of Agile maturity.

Consider Context

Other key phrases may indicate potential issues, but they are somewhat less of a red flag.

Words like “plan”, “facilitate”, “coordinate”, “forecast”, “deliver” or “document” may seem suspiciously anti-Agile. But it is how they are used in context that better indicate intent.  As a result, they are potential indicators more insight would be required in order to draw conclusions.

An example could be the expectation you are to facilitate retrospectives, planning sessions, stakeholder reviews, etc.

On the surface, this activity sounds reasonably Agile. Note that for transparency outcomes and final actions of meetings are often shared with people outside an Agile team.

However, if there is an indication that meeting minutes should be documented and published, reported on, or provided to management then there may be an overlying issue with trust and empowerment in the organization.  This is especially true if it is referring to retrospectives where a trust and protective environment is critical.

Planning

The word planning is often seen as a red flag.  However, planning isn’t forbidden in Agile. In fact, it is an integral part of many of the accepted Agile Methods, practices and frameworks.

The key is to determine:

• How much up-front planning is done?
• At what stage(s) it is done?
• To what level of confidence, completeness or detail it is done?

If the job description talks about building and signing off on a plan before beginning or planning in stages or gates, those should be red flags.  However, if the job description talks about incremental and progressive or adaptive planning, or a continuous learning cycle and feedback loop that feeds in to planning, it might be okay.

Another example would be to have the term forecast deliverable in the list of job duties.  Forecasting is okay for an Agile team so long as the forecast is accepted as a ballpark estimate. It’s not taken as a commitment to deliver.

Unfortunately, getting the internal context to this requires more transparency into the organization, its people, and its practices than you often will receive in a job description.

Documentation

The Agile Manifesto says, “we value working software over comprehensive documentation”.  Often people interpret the word “over” as meaning “instead of.’ That is not the intent.

Documentation is acceptable for an Agile organization so long as it is just in time, fit for purpose, and provides clear benefit and value.  Seeing a job description with the word document should not be a red flag on its own.

It is the type, amount, and the way documentation is used that indicates how Agile an organization may be.

Seeing activities such as “provide, manage, and update all project documentation” or “document status updates” or “oversee change management documentation” are red flags.

On the other hand, seeing the phrases “document features in the form of User Stories” or “document team progress on the project board” are not clear indicators the team or organization is Agile.  In both cases, follow-up is necessary.

When reviewing the activities or duties in a job description, ask yourself “does this activity or expectation align with what I think an Agile team member would/should do?”

Boards

Let’s expand on the previous paragraph where I indicated maintaining a team board is not a clear indicator that an organization is Agile.

First, a team should maintain their own information radiator. It shouldn’t rely on an individual to do it as part of their responsibility.  Secondly, a work board is not bad on its own. But it does not indicate a high level of Agility other than it provides transparency and makes work visible. These are indicators of a lower maturity Agile organization.

Another example would be something like “ensuring delivery or performance is within parameters or tolerances.”

Setting metrics for performance is not an anti-Agile approach. It should be desirable to measure what the customer believes important.

However, language that talks about performance metrics that measure how many stories, story points, or number of features delivered indicate a preference for vanity metrics which are typically associated with lower levels of Agile maturity.

What’s Missing?

Sometimes, it’s what is not written that provides clues.

Job descriptions are often purposefully kept brief, incomplete or vague because the role is forming. The organization wants to evaluate how candidates respond to vagueness.

Still, the absence of information may provide insights.

If the job description does not show that the team or organization leverages technical or engineering practices or tools such as test-driven development, automated testing, pair programming, continuous or incremental delivery, or DevOps then the organization may be at at a lower level of Agile maturity.

Similarly, if there is no indication of the work environment or location, travel arrangements, team organization or composition, or customer engagement, these could be indicative the organization doesn’t value them or is simply using this as an opportunity to have a conversation with you as a candidate about these topics.

In Summary

A job description is usually a crafted summary of the expectations for a role.

Often there are indicators embedded in the language and terminology that make suggestions as to the work environment and responsibilities for the role. We can use an Agile lens to evaluate that information.

At the end of the day, people with an Agile mindset should always value face-to-face conversation over documentation. A job description is often just a document.  The best advice is to use a job description to provide insight and as a means to elicit a more meaningful conversation about the role.

My next article in this series will focus on having a good conversation with a recruiter, including what clues to listen for and what to ask or say.  Stay tuned and check back soon!

Are you hunting for a new opportunity or looking to fill a position. Check out BERTEIG Recruitment.

If you find this useful, please consider contributing with our
“Value for Value” model.