Are you "agile"?

I've interviewed over 300 folks in the last 2 years while building the Okta team. Most have been product development folks. One topic that often comes up is Agile development. As in "do you guys do Agile?", or "at company xyz we exclusively practiced Agile".

Few terms in interview land are more overloaded than "Agile".

Whenever a candidate has "Agile" on their resume or speaks about it in the interview, I always ask them, "What do you mean by Agile?" I've heard some pretty interesting answers:

• "Yes, we have daily meetings".
• "Yes, we have chickens and pigs and only the pigs talk at meetings - well, mostly".
• "Yes, we have monthly sprints, we release the product after 6 or so sprints - well by release I mean, we give it to QA" (yes, an actual quote).

At Okta, we are very much into Agile development. Yes WE do Agile development. When I say this to candidates it is as unclear to them what I mean as when they say it to me. In order to explain what I mean by Agile, I've come up with the following "Agile litmus tests". If you pass these tests, then congratulations, you are Agile.

Do you have short iterations (1 month or less), where the work is truly done? Short iterations, when you get all they key tasks done (testing, well written code, documentation), ensures you aren't building up technical debt and keeps it clear how far along you are. For some companies it isn't realistic to release every week. They have to come up with more artificial "gates" - things like checklists that include all the things required before something is "done". At Okta, we release the new enhancements to our production service weekly. Everything has to be done. Done as in done done. This makes things much more clear and simple than trying to close out an iteration without having to release it.

Do you have high-quality automated test coverage for everything in your product? You're almost assured of passing this test if you have short iterations. Short iterations are only truly possible with high quality automation. Companies that don't have high quality automation but still do have short iterations usually aren't actually releasing the product after each iteration. They're allowing these "false" unreleased iterations to accumulate bugs and technical debt. There are usually several "quality" sprints before the real release where they make up for poor automation with manual testing.

Surprisingly, high-quality automation is very rarely listed by candidates when they describe the agile environments they've worked in or even when they list the key components of agile.

Within a sprint, are people allowed to focus and execute on what they signed up for? It is very common when I speak with candidates that they'll describe un-Agile environments as "the priorities are always changing and we're always fighting fires". Uninterrupted focus is very powerful and motivating. This one isn't black and white as things come up and you need to react, but on balance, is firefighting in your company the exception or the norm? Here at Okta, we work very hard to organize things to let people aggressively sign up for tasks, and focus on them during a sprint.

Do people, from the bottom up, sign up for what they can accomplish during a sprint? Or is this pushed down on them by management? Management “by the whip” does not work in our industry. Most leaders know this so they try to avoid it by “nicely telling” their team what they need to get done and by when. This may not be as abrasive as a whip, but it is equally ineffective over the long term. Nothing is more powerful than talented people making a commitment to themselves and their teammates to get something done.

All the effort from your leadership team should be focused on finding the best people, and building a “bottoms up” environment.

Do you strive to continuously improve? Do you do retrospectives and think hard about how to get better? Do you follow through on this and avoid repeating the same mistakes?

There’s our take on “Agile”. There’s an entire industry around defining agile development and training teams to work in an agile fashion. They’ll talk about scrums and stand ups and chickens and pigs and the like. All of this is great but I’ve found if you build an organization that passes these tests, you’re well on your way to the massive benefits of a high performing engineering organization.