Screening Organizations as an Agile Candidate

A lot of Agile recruitment articles provide tips on the language and qualities that a good Agile candidate should use in their application.  I want to flip that and help candidates find a good Agile organization to work for!  Here’s a few pointers you can use during the interview process to increase odds you end up working for a company that might actually “get it”.

Focus on the Leadership

Although the Agile Manifesto doesn’t explicitly call out leadership, it does reference things a leader would typically be responsible for to support an Agile organization.  Given that, here’s a few related questions you might want to ask:

“If my Agile team experiences an impediment outside of their control, how would it be handled?”

• If the team will be expected to figure it out themselves then they likely don’t have leadership with a collaborative Agile mindset.
• Conversely if the issue will be taken away from the team and given to management to resolve with minimal team engagement, that might be an indication the organization has more of a command and control approach.
• If the team doesn’t have a clear and common escalation path to a single point that can resolve it in a timely manner, then there may be a problem with siloes.
• If leadership doesn’t typically volunteer to own system-level impediments and follow them through to resolution, then there may either be a problem with accountability or a lack of maturity in the organization to understand their larger system.
• If the team will typically be given considerable autonomy to pursue the solution, and they are given management and leadership support towards that end then the organization usually tends to be more Agile.

“When our team has a dependency on someone else and they don’t have the same priorities, how are those disconnects managed?”

• If the answer doesn’t include how team backlogs are aligned with an organizational backlog, then there may be an issue with enterprise alignment on business priorities, or a lack of maturity about how the organization is a larger system and not just independent departments.
• If the answer doesn’t include how business makes decisions on prioritization of work across projects or programs, then there may be an issue with product or business siloes.
• If you are practicing Scrum the Scrum guide explicitly states that “cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.” Although this reality is uncommon, a good Agile organization will recognize it and respond with something like “we try to get as many of the skills, authority and responsibilities to deliver end-to-end on the team.”
• If an organization uses visualization to map the end-to-end interconnectedness of the various services (or value stream mapping might also help), and there are specific policies on how to handle the interconnections and expectations between teams then the organization tends to be more Agile.

“Are there any concerns with Product Owners changing direction every few weeks?”

• Changing priorities aren’t necessarily a bad thing. The Agile Manifesto even says “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”  However, if it looks like an organization suffers from the “kid in the candy store” syndrome more than the “pivot to deliver awesome results to the customer” approach you want to be able to quash that.  Make sure their answer touches on the points of responding to strategic or necessary change vs. just changing based on an individual’s preferences or needs.

“If my team fails to deliver on time for a scheduled release, who is held responsible and how does leadership respond?”

• If the response says things like the Project Manager or Scrum Master are held responsible, or that the individual(s) that are accountable would be determined and dealt with accordingly, or the team needs to get better at estimating, then these might be indications of a less Agile environment.
• A more Agile answer might include they would manage customer expectations as soon as the delay is forecast, that the team and organization collectively would be expected to learn from the experience and use those learnings in future initiatives.
• Among other things the Agile Manifesto says we should value “Responding to change over following a plan”. That doesn’t mean a plan should not exist, but it does mean an Agile organization and business should willingly recognize that a plan is just a forecast and not a commitment.  That makes this sort of a trick question!  An Agile organization should therefore somehow indicate in their response that the delay or change could be for a good reason and they would want to evaluate the impact and reason by consulting with the team, the business, and the customer.

Focus on the People

It’s people that turn their skills and abilities in to deliverable value and a good Agile organization will recognize this.  The Agile Manifesto even says “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”, so the focus of a good Agile organization should be on building a great environment and trusting their employees.  Here are a few questions that might help lead you down that path.

“Can I observe the team in action?”

• If the organization denies your request, then ask the question “I’d like to understand why this isn’t possible or preferred.” The risk of pushing for an answer is the interviewers may not appreciate being questioned on their approaches, but that in itself might be an indicator of the culture.
• An Agile organization will value transparency and will likely allow you to observe the team in action (barring any confidentiality issues). This may not become possible until you reach a later stage of the hiring process.

“Can I interview with the team without leadership or management in the room?”

• Similar to above, if you are denied access to the team this is possibly an indicator of the organizational culture.
• Similar to above a more Agile organization will understand the need for transparency including tight team collaboration, trust, and relationships. Those are the foundations for a high performing team.  The organization should also value the feedback and input from the team regarding your suitability as a team member since you would be expected to fit in and deliver with these people.

“Can I see where the teams do their work?”

• Shared meeting rooms that need to be booked in advance, work cubicles or a workbench environment with shared or hoteling communal desks in an open floor space with no walls are indications the organization may not value or understand what a good collaborative workspace and environment is.
• Distributed teams are not on their own an indication of a low-Agile maturity company, as there are methods and tools to help compensate for distances. However, it does indicate the organization may value salary and real-estate savings over the benefit of face-to-face communications, so you may want to follow up with a second question along the lines of “What were the reasons for forming distributed teams?”  One acceptable reason to have a distributed team is to be closer to the customer.
• More Agile organizations will create colocation opportunities and enable teams to set up their own comfortable areas for working. Dedicated team rooms, large boards showing the team’s own view of their work including icons, stickies, comments, notes, and pictures are indicators there may be Agile flexibility in the work environment.  In other words, how “customized” does the work environment seem to the team.

Focus on the Mindset

The Agile Manifesto says “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”  It also talks about welcoming change, emergent architecture from self-organizing teams, continuous attention to technical excellence, and simplicity.  Be sure to look for some of these key indicators when questioning the organization, just as they would question you in an Agile recruitment process.

“What happens when there is a need to work overtime?”

• It may be difficult to get a reliable answer for this question, as the person being asked may not know the specific conditions for the team you are interviewing for or they may not want to divulge the answer. This question might be better directed to the team members rather than the interviewer if you have the opportunity.
• If a team rallies around the work and everyone works together to solve the issue that led to overtime, then that might be a good indication the team at least thinks in an Agile manner.

“What happens if testing isn’t finished or done properly?”

• If the explicit role of tester is expected to finish the testing, then this might be an indication of less Agile organization or work environment.
• If the team is expected to share the burden and rally around the remaining work, then this indicates a more Agile work environment.
• A really good Agile mindset would be to also leverage the Inspect and Adapt approach. First, to acknowledge that something likely led to the issue to occur in the first place, then to conduct a focused assessment of the work and determine actions to hopefully mitigate it happening in the future.

“What if my team identifies a need for a technology or skill?  How is it approved?”

• Less Agile organizations will have a formal process of evaluating needs, such as business cases or cost/benefit assessments to be documented and reviewed by either management or a panel.
• More Agile organizations will empower their teams to seek out what is needed and either fill the gap as required, find creative ways to solve the problem, or have a discussion with a manager to get approval.
• Higher Agile organizations will allow their teams a wide range of latitude when trying to solve these problems, sometimes even giving them a pool of funds (sometimes tied to quarterly or semi-annual budgets) to pull from as they see fit. However, it is unusual to find organizations that give teams complete autonomy.

“How does the organization innovate?”

• Note that this is a pretty open-ended question, and it isn’t typical so it may trigger some unusual responses.
• If the organization indicates they get their stakeholders together to brainstorm ideas for future products and services, then they may not have a very Agile mindset.
• If they have a process or defined method to allow for innovation (e.g. Lean Startup, Hackathons, etc.) might indicate a mid-level of Agility as they have put some thought in to it and formally recognize the value of innovation.
• If they consult with their customers early and frequently about their needs, including going on-site and working side-by-side with the customer, getting feedback on prototyping, design work, and user experience then they are likely closer to an Agile mindset.

“How is technical debt managed?”

• If the response seems unclear or unorganized then the organization may not have a formal way to deal with technical debt, which indicates a low level of Agility.
• If teams are given the opportunity to allocate certain percentages to fixing technical debt, then that indicates a slightly higher level of maturity.
• If teams and/or individuals are encouraged to seek out known issues and technical debt and they are allowed to self-organize around the issues and self-allocate capacity, then that indicates a higher level of maturity.
• If technical debt and bugs/defects are viewed as a virus or infection in the system and the team swarms the issue as soon as it is identified (known in Lean as “Stop the Line”) then they are at a fairly high level of Agile maturity.

Focus on the Business

The Agile Manifesto says “Business people and developers must work together daily throughout the project”, which is more about how to collaborate to ensure business and IT are aligned rather than focus efforts on the business.  Aside from that statement the concept of business Agility seems implicit in most of the Agile Manifesto, however it should really be core to what an organization is seeking in order to become Agile and not just do Agile.  Here are a few questions you may want to ask to dig a little deeper.

“What does Business Agility mean to you?”

• If their response indicates having business and IT collaborate on solutions then their statement may align with the wording in the Agile Manifesto but it doesn’t necessarily mean they understand the intent. You would want to dig deeper to find out what does “collaborate” specifically mean?  Are there any separation of responsibilities or is it truly shared?  What would a typical day look like during development and are the business people really at the table with skin in the game?  Does the work that a team receives get vetted by customers before and is their feedback truly sought often?
• A higher Agile maturity response would be to systematically evaluate customer needs and work towards solving those problems. Having proper methods to consult directly with customers and get their feedback, then use that information to drive decisions about what work gets accepted and what changes are required to service the customer’s needs all indicate Agile thinking.

“How is the organization structured to deliver?”

• This is an interesting question that will likely result in a wide range of answers.
• If projects and programs get staffed from an organizational chart of silos of expertise (e.g. Development, HR, QA, Production, Support, Architecture) then that is an indication of a low Agile Maturity organization, especially if the business, delivery and operations groups are defined separately.
• Similar to above, however an org chart showing teams and divisions might indicate a slightly higher level of Agility.
• A diagram showing product lines or value streams would indicate a medium level of Agile maturity.
• A large enterprise-level board that visualizes the work and how it flows through the organization from concept to delivery would indicate a fairly high level of Agility.

Focus on the Processes

One of the four value statements of the Agile Manifesto says, “Individuals and Interactions over Processes and Tools”, so it’s important to determine how your potential employer operates.

“How are bugs and defects managed?”

• Bugs and defects are indicators of a lack of professionalism. Mistakes will always happen, but how an organization deals with them will help indicate how Agile they are.
• If bugs and defects are logged in a database or tool for future triage, then they are likely at a low level of Agility.
• If bugs and defects are triaged and prioritized while working and a decision is made whether to fix it now or later then that is a slightly higher level of Agility.
• If a team swarms an issue and works to resolve it as soon as it is discovered, then that indicates a high Agile maturity approach.

“How are lessons learned performed?”

• Being an Agile organization means being lifelong learners and having a vested interest in continuous improvement. The Agile Manifesto even says “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”  Furthermore, if they are practicing Scrum then they should be leveraging  Inspect, Adapt, and Transparency since they are all key supporting pillars of the Scrum Values.
• If retrospectives are conducted at the end of a project, then the organization is likely at a low Agile maturity level, as nothing can be done towards improving while the work is being done.
• If retrospectives are conducted at a regular cadence (say weekly or even monthly) then that indicates a slightly higher level of Agile maturity.
• If actions are taken by teams and they follow up on them frequently to ensure they are improving, then that indicates an even higher level of Agility.
• If service level reviews are conducted at frequent intervals, and that information is then passed on and shared at a system (organizational) level then that organization is experiencing a higher level of Agility.

“Where does the work come from and go to for my (potential) team?”

• Agile organizations will understand the work doesn’t start and stop within each internal team; it flows end to end from customer request to customer need being fulfilled.
• If it is unclear who the customers (upstream) and consumers (downstream) are for the product or service that your team will be providing, then it is likely at a very low level of Agility.
• If it is known who makes the work requests and who uses your solution (especially if they are different), then the organization is likely at a low level of Agility.
• If a backlog is used to manage stakeholders requests and the team works on those requests as they are received then that is an indicator of a somewhat Agile organization, especially if the backlog is part of a larger pipeline of backlogs that are interconnected at a higher level.
• If there is a system in effect where teams and individuals pull work based on their capacity, then show their work so the end-to-end flow and defined policies for handling the work is visible, then they are working at a higher level of Agility.

Focus on the Work

On the topic of work the Agile Manifesto says we should value “Working software over comprehensive documentation”.  It also makes the following two specific guiding principle statements; “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale” and “Working software is the primary measure of progress.”  The key here is to interpret what does “working software” mean to the organization.  In more generic terms it should mean delivery of a solution that is valuable to the customer.  That means an Agile organization should attempt to do work that is valuable for the customer and then measure how effective they are at satisfying customer needs.

“What metrics do you use to measure success?”

• Status reports, burn-up charts, Gantt charts, milestone deliverables on time, on budget, and with the required features and functions all do not typically address value, they are usually measures of progress based on a predetermined plan. An organization that uses these types of metrics is typically at a very low Agile maturity level.
• Organizations that use measures like customer satisfaction, net promoter scores and employee engagement/happiness are typically higher on the Agile maturity level, as they are beginning to consider customer needs and sustainability.
• Lead time, cycle time, delivery (run) rates, confidence levels, and efficiency rate measurements all typically indicate a more Agile organization, as the focus is on how long it takes to deliver something and how predictable or reliable the delivery and service are.
• An organization that works specifically with their customer to co-define additional measures of success (i.e. what is most fit-for-purpose for the customer) also indicates a higher level of Agile maturity.

“How do you ensure the work is aligned with organizational strategic goals?”

• Organizations that conduct performance appraisals against goals that are passed down from the upper hierarchy claim to ensure those goals are directly aligned, however there is usually little real connection between the tactical work that is done and the original high-level strategy, or the work and value to the business or customer. These organizations tend to be less Agile.
• Organizations that build master backlogs that are managed by Chief Product Owners and that are broken down and “handed” to various Product Owners to work on with their respective teams do display a certain amount of Agility in the work at the team level can usually be tied back to the larger epic or organizational work items.
• Organizations that provide transparency by visualizing and managing the work end-to-end at the enterprise level all the way to the team level, and that highlight issues, impediments, blockages, dependencies, and policies on how to manage the work tend to be the most Agile.

Conclusion

These are just a few of the questions you should consider asking when screening organizations for potential employment.  There are many other ways to determine the Agility of a business, but these will get you started. Feel free to comment below and suggest any other good questions you think someone could ask during an interview to determine if an organization is Agile, after all ‘Agile recruitment’ goes both ways.

Meanwhile, to improve your odds of success in applying and in screening out organizations, you should consider attending an Agile-focused training course such as Certified Scrum Master, Certified Scrum Product Owner, Team Kanban Practitioner, Kanban Systems Design or Kanban Management Professional will help you prepare by not only giving by you the necessary fundamental Agile skills but also the knowledge and language to successfully navigate an Agile recruitment interview and conduct your own screening of an organization to determine how Agile they are.

BERTEIG specializes in delivering both public and private versions of the above training, so please check out our website, email us, or call us (1-888-532-7785) if you have any questions.  We may even be able to connect you with an Agile organization that has employment opportunities, so you never know!

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