Last week, I wrote about how software companies can claim to "do the Agile" while implementing waterfall or spiral models of software development.
If "fake agile" is the norm, asking a hiring team "do you do real agile?" is pointless. Nor is it helpful to ask about various agile-related ceremonies. No team is going to tell you 'Yeah, we waste about an hour every morning going over trivial issues during standup' – especially not in an interview setting.
When I interview, I want to find out if the team follows the Agile Manifesto and its Principles. If the core is rotten, the rest (SAFe/Lean/XP/Crystal/TDD) are just lipstick on a pig.
Note: I am not advocating that Agile is the end all be all way to create software. Waterfall, spiral, and other SDLC methods have their uses. I happen to usually look for web development roles and like an agile environment.
Here are 3 questions to help you find out if the company you are interviewing with is doing AgileFail – ask a developer you'll be working with:
"Tell me about the last time you refactored a module."
Follow up to get an answer on when it last happened, how large was the refactor, what caused it, and if management was involved.
A waterfall development process usually refactors at the beginning of a project, or when the project can no longer bear the weight of technical debt and outdated design decisions. This leads to large and long refactor periods, often after spending much time convincing management and multiple missed deadlines.
A spiral model team has built-in refactor opportunities, after milestones or batches of customer feedback, leading to medium-to-large-sized refactors.
An agile team has a refactoring as you go mentality. Only a handful of modules are touched at most and require little to no management wrangling.
An agile answer would sound something like: 'I abstracted out the shipping calculation last week while adding DHL shipment support, it was the right opportunity to separate the UPS specific logic from common carrier abstraction.'.
Related Agile Principles:
Continuous attention to technical excellence
and good design enhances agility.The best architectures, requirements, and designs
emerge from self-organizing teams.
"Tell me about the last piece of user feedback that became a feature."
Follow up with questions on how user feedback is gathered, how frequently that communication occurs, and how involved devs are in the feature design process.
A ScrumFail team often would blank on this question, features are decided on and designed by individuals with no interaction with the development team. Or the product owner decides to add a feature to meet a KPI and the requirements are handed down at the beginning of a months-long planning period.
A spiral development team gets these periodically – such as during milestone deliverable reviews – and spend a chunk of time incorporating those new feedback into the existing software.
An agile team gets user feedback in the form of direct user interactions and usage data, developers are involved early and often in new feature development.
Here's a hypothetical answer that I would love: "The product owner told us users reported the shipping calculation selector was confusing, so I worked with our UX designer on a few alternative designs. They are currently being A/B tested".
Agile Principles involved:
Business people and developers must work
together daily throughout the project.Individuals and interactions over processes and tools
Customer collaboration over contract negotiation
"Tell me about the last feature of yours that got dropped."
This one is simple, I want to confirm that features get dropped, period. Bonus points if the feature is dropped due to user feedback or otherwise gets bumped by a higher priority item.
Waterfall teams have a deadline for each piece of work – coerced or otherwise – and simply do not drop features. Of course, unexpected high-priority tickets keep flying in. So developers are constantly sprinting forward while dodging incoming P0s. This road leads to misery and burnout.
Spiral process teams check in on a predetermined schedule and may decide to cut out-of-scope or infeasible features.
An agile team tries to plan things out, but they also know that plans do not survive first contact with the enemy. And if you are responsive to change, you have to frequently drop outdated plans to make room for new ones. Features may start as a research spike or proof of concept, but they are validated via user feedback and they get dropped if priorities change.
A good answer here would look like this: "Last month I was working with the designer on a new checkout workflow, but we got a spike of complaints about shipping options after we expanded services to Europe so the checkout flow work got dropped to a later date".
Agile Principles involved:
Responding to change over following a plan
Agile processes promote sustainable development.The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Take-Aways
Why these questions and not "how do you decide on a new feature?" or "How often do you refactor?"? Because the alternatives invite calorie-free answers like "user feedback is the most important guide for our product roadmap" and "we write the highest quality code that gets the job done".
I want concrete examples from the past, not hopeful future fluff. So if you are on the job market looking for a team that cares more about being agile than going through the motions to look agile, ask these questions:
- "Tell me about the last time you refactored a module or class."
- "Tell me about the last piece of user feedback that became a feature."
- "Tell me about the last feature of yours that got dropped."
If you find this post helpful, you may also be interested in learning more about how fake agile is done, or how a comment hierarchy can improve your code review process.
Top comments (0)