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.    

Culture of Challenging Assumptions

 When you calculate the value of an idea, epic, or feature (e.g., revenue, cost of delay, etc.), many assumptions are made. As part of transforming toward an Agile culture, it is important to apply a discovery mindset that includes positively challenging assumptions so that you can better understand the value of an idea or adapt the value accordingly for the greater success of your company.

For example, a new idea is recorded that states a value of $1,000,000. The first step in challenging assumptions is using open-ended questions.  Open-ended questions allow you to ask questions in a non-confrontational way. Examples of open-ended questions include: What led you to that conclusion?; What do you think the level of uncertainty is?; What is your riskiest assumption?; and What information do you need to validate this?

The second step is to validate the answers. For example, if the revenue value of an idea is $1,000,000 and based on a conversation rate of 6% but the average conversion rate for products in the field is 4%, then the calculation of value should be adjusted lower accordingly. Alternatively, if the idea uses the same potential population of potential customers as the first product that entered the field, then it is less likely that the second product entering the field will have the same potential customer size. 

The third step is that you must challenges the assumptions of all ideas fairly and equally. By having reasoned conversations about those assumptions and ironing out the differences, you can get a consensus on the value so they can be fairly ranked. When the value is subjective, gut feel, those discussions can turn negative and the organization may end up putting their valuable employee effort onto lower value ideas.  Inversely, the more willing and the more objectively you challenge assumptions, the more likely you will put your employee effort to good use on high-value ideas and greater success for your company

Agile Brevity

When working within an Agile context, there is an emphasis on getting work done and meeting the outcomes of the customer needs. The work is typically structured around various Agile ceremonies depending on the methodology or process a team is using. Key to these ceremonies is to keep them concise. In order to do this, often timeboxing is introduced. However, timeboxing is only as effective as the people’s abilities to keep their discussions concise. I call this technique “agile brevity”.

What is agile brevity?  It is a speaking technique that is both art and skill focused on keeping one’s comments as clear, concise, and value-added within the context of the session at hand. This means that the brain must be hyper-focused on the context and purpose of the session and speaking with agile brevity within that context.  It then means that the person must consider what is the most important thing of value to say that will help progress move forward. This leads to more productive and collaborative working sessions. 

Consider the Daily Stand-up. It is meant to be applied at a team level (~7 people) and take no more than 15 minutes. This means that each person has approximately 2 minutes to communicate progress and impediments. Teams new to the stand-up usually takes much longer than 15 minutes to get through their progress as they don’t yet have experience of being brief. Agile brevity means that they must consider what is the highest value information to communication the progress from yesterday, the highest value information that focuses on the work today for potential collaboration, and the specifics of any impediments so others understand it enough to potentially help, all within a very timely manner.  

Agile brevity also applies to Refinement and Sprint Planning ceremonies. Within the context of these ceremonies, there is typically a timebox on how long is spent on each user story. As there is less structure in refinement or planning ceremonies than a daily stand-up, the hyper-focus of crisply asking the right questions to understand the user story is even more important.  The other attribute of agile brevity is determining if your question or information is of greater value than another person’s question or information. In other words, many factors should be quickly swirling in your head before you speak. 

Agile brevity is a combination of art and skill keeping one’s comments or questions as clear, concise, and value-added on the topic at hand as possible. It keeps people mentally focused, keeps working sessions tight and to the point, and ensures the highest value information and questions get discussed. While its called “agile brevity”, it isn’t specific to Agile and can be used to make any ways of working more efficient, effective, and value-added. If you find your working sessions often running long, consider trying this technique.   

Requirements Tree: Focusing your efforts on the highest value work

Requirement is a nebulous term.  It can mean something large like a strategy, to smaller items like features, user stories, or tasks. People often throw around the word requirement without a strong sense of the type of requirement it is or the level it belongs. It is important for clarity and common understanding across organizations and teams. Otherwise, it can be quite confusing as to which level people are discussing. 

To gain this common understand of the various levels of requirement, I recommend starting by establishing a requirements tree.  It is a structure that represents the relative hierarchy amongst various requirements elements within your enterprise. It makes it clear how requirements levels are connected. For example, a feature is a requirements element that is at the larger than a user story, so I would expect to find multiple children (aka, user stories) to the build a feature.  Think of it as your requirements lineage. 

What are advantages of creating a requirements tree? First, it ensures that requirements elements at the lower level (aka., the children) are aligned to higher level and presumably high value requirements elements. This ensures that you are putting all of your company’s effort on the highest value work. Second, it helps you determine if there are random requirements that made their way in through a back door.  Third, the requirements tree provides context of the level of requirement being discussed and traceability in the hierarchy.  

What are the various requirements elements and hierarchy? There is no industry standard group in either and they can vary from enterprise to enterprise. The key is to establish yours.  I like to start with corporate strategy and end with tasks as illustrated in the figure. 

Once you establish the levels of your requirements tree, it is important to craft a definition to describe each level.  Using the requirement levels from the figure, here is how I describe each level.  A strategy sets  direction for the enterprise.  An idea is a high customer value and outcome-based opportunity.  An increment is an end-to-end slice of the idea to provide value and validate of the idea.  An epic is a function or feature.  A user story is a requirement that fits into a sprint of a week or two and has one persona.  A task is a very small unit of work that incrementally builds the user story. 

In addition, when you have the requirements tree and definitions of each level, you can align roles of who should be working on those levels with expectations and outcomes of each level. 

You may notice that instead of putting the strategy on top, I place it on the bottom.  I do this to represent the strategy as the trunk of the tree as this should provide guidance for how the smaller requirements elements (e.g., ideas, increments, epics, user stories, and tasks) should grow. While your strategy may adapt over time based on customer feedback and the changing marketplace, it should guide the type of work you may consider working on. 

The key to your requirements tree is for you to establish one that makes sense for the type of work you do.  For example, if you only have one division in your company, then a division strategy isn’t necessary.  You may also work with business requirements so place them in the right level for your tree. Those that may consider creating a requirements tree are a combination of executives, portfolio, product owners, and team members.  Once crafted, it should be shared with everyone for a common understanding and a way to validate that the work at the team level is aligned with the highest value work.

Note: For more information on the Requirements Tree, read Chapter 15 of the book "The Agile Enterprise". 

 

Rose Retrospective - A Rose by any other Name

Many Retrospectives in the Agile world tend to follow the “what went well”, “what problems did we encounter”, followed by actions for improvement. I call this the WWW (what went well) retrospective. While this serves as a practical retrospective, did you know that there is no one specific retrospective practice expected by Agile? The Agile principle only asks that “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”  Even Scrum is not specific.  Per the Scrum Guide, it suggests that a retrospective “is to plan ways to increase quality and effectiveness”.

If you are applying the “what went well” type of retrospective, would you like to experience something new, a more adventurous retrospective? Allow me to introduce you to “A Rose by any other Name” Retrospective or Rose Retrospective.  

This is a botanical approach that uses the parts of the rose to explore how things are going and what you can do to improve. The parts of the rose that we explore during this retrospective are the Flower, the, Thorn, and Bud. To put some color to these parts, here are some definitions:

• Flower: This highlights the positives, what you're happy about or what is going well for you or the team.
• Thorn: These are negative things that are impacting your work or life. It may be something that didn’t go your way, causing stress, impediments to success, or something that you’re not proud of. 
• Bud:  These are areas that have a potential to bloom or improve if we nurture and put some focus onto them. They have the potential of becoming a flower. 

How might you implement a Rose Retrospective?  Let’s step through the preparation and steps through conducting a retrospective. 

Prepare the space 

Whether a physical room or a virtual room, create a space to (e.g., white boards, etc.) to add Flower, Thorn, and Bud. 

Determine what cohort of people will participate. It is best to invite those that were actually engaged in the topic (e.g., the team that did the work).

Conduct the session 

Start by explaining the process of the Rose Retrospective and the meaning of the flower, thorn, and bud. Advise them on what they will be reflecting on (the recent sprint, project, time period, etc.). 

Begin with Flowers. Give everyone 5 minutes to brainstorm their flower(s). Everyone shares their flowers. This may include recent successes in delivery, relationships, and progress. You may use data as an input. The intent is boost morale and make people feel proud of their activities and progress. The result is to visualize as a bouquet of flowers on a rose bush.

Continue with Thorns. Give everyone 5 minutes to brainstorm their thorn(s).  Everyone shares their thorns with the intent is to share challenges. The result is to visualize the thorns of a rose bush. 

Finally, the group discusses the buds. Reviewing the Thorns, consider what can be improved and actions for improvement. Provide time to consider the root cause, brainstorm new ideas, and suggesting solutions. Also consider other ideas that may need a boost in areas that are ripe with infusing extra effort to turn the bud into a flower. Prioritize ideas and solutions and focus on the top 2 or 3 actions. The result is to visualize a group of buds that may blossom with some extra effort. 

Work on the actions 

Once the session is over, the next steps are to add the actions to your backlog of work, marking them as high priority. Then work on the actions to turn the buds into bouquets of flower.