Hiring for the Culture of your Future

As an Agile Consultant, I occasionally help companies hire for talent as I’m transforming companies (e.g., an Agile transformation, business transformation, digital transformation or similar). When I’m helping with interviewing or hiring talent process, the interviewers circle back together to discuss the candidate. I often hear things like “They don’t seem to fit our culture”. Sometimes, there is a question built into the interview questionnaire asking, “Are they a cultural fit?”. 

When a company is satisfied with their culture, I can understand that you would align with the concept of hiring for cultural fit.  However, when you are working through an agile, business, or digital transformation, this implies that you are also transforming to a different culture with new ways of working. When you say “hire for a cultural fit” it needs to be to the new culture that you want.

For example, if the culture is more command and control where work is prescribed upfront, then the work culture tends to be very individual driven (I have been assigned my task and I will work on it) with little feedback is asked for (do the work and get it done by the deadline). If you are transforming to Agile ways of working, you need a much more collaborative and team-oriented culture where people are pairing up on tasks, helping each other, and where feedback is expected. Hiring for the former (command and control type culture) will not help you get to an agile culture of collaboration.  

If you are going through any type of transformation as a company, include a theme or work on re-evaluating the hiring process. Take a look at your standard interview questions and adapt them for the culture that you want. Also, describe the type of people that will fit your future culture (e.g., collaborative, team-oriented, etc.) and share this with the interviewers.  This will help embed your current culture with the people that will support the culture you desire for the future.    

Agile Requirements - A Promise for a Collaborative Conversation

Most topics surrounding the establishment of requirements revolve around how to write them (including my recent article entitled User Story Writing Starter Kit).  However, not enough is written about the key ingredient of a robust requirements process.  Some will say that when you document the requirement, you are done with the requirements process.  I content, that this is just the beginning.  The real value of a requirements process is not just writing it down, it is to begin the collaborative discussion. 

In an Agile world writing down a requirement begins the discussion between the business and engineering side.  Whether this is between the Product Owner and Development team or the Customer and Programmer/Tester, the importance is that a shared understanding begins.  This discussion initiates the learning amongst the business and engineering side where the engineering side more thoroughly understands the business value of the requirement and the business side better understands the technical options of the requirement.

It goes much deeper than this.  In the old world, there is a typically only a one or few folks who attempt to capture the whole requirement in a documented form.  This forms the basis for a requirement specification that may get ‘thrown over the wall’ to development.

I would suggest a much more robust approach starts with writing down the requirement and then continues with the fleshing-out of the requirement in a collaborative manner with the whole team.  This utilizes the brainpower of the whole team whereby each member may contribute to the understanding of the requirement and how to best provide a working solution for that requirement. 

From a process perspective, the discussion first begins when the requirement gets introduced by the Product Owner to the Development team.  As an example, this could be in a grooming, refinement, agile release planning, or sprint planning (depending on your approach) where the highest priority requirements are discussed and fleshed-out with the team’s input.  During this session, the collaborative discussion may focus on the following: 

• Understanding why it is a high priority
• Validating/updating the User Story is in Canonical Form (or defined form)
• Understanding the business value and customer perspective
• Describing acceptance criteria
• Considering high-level technical details
• Identifying unknowns and risks (each should have an action to investigate and mitigate)
• Identifying what is out of scope
• Identifying dependencies
• Decomposing epic to user stories or each user story to tasks
• Providing high-level sizing (e.g., t-shirt sizing, story points, etc.)

As the collaborative discussion ensues (usually in a time-boxed manner), the requirement gains more clarity and robustness, where there is a team understanding of the work.  As details are discussed, the Scrum Master, Product Owner, or anyone on the team, captures the details within the requirement.  At some point, the Product Owner and team will decide that it is ready to go into the sprint or work queue.  There is no ‘throw it over the wall’ to folks who have little understanding or context of the requirements.  Instead, when it is time to build, the developer and tester are fully aware of the requirement since they have collaboratively provided input into it. 

Whether you work in a more traditional world or an Agile world, consider adapting to a more collaborative requirements discussion approach.  Gaining the brainpower of the team and moving to a pattern of learning can achieve a much better understanding of the customer need and ultimately a better solution for the customer.