Hire and Grow an Agile Mindset

For a long time, product development has been considered, unfortunately, as an industrial endeavor. Create plans, schedule phases, make designs, and hope the actual work will be executed as expected. Having a team of experts where everyone works in their respective function is a good solution for complicated industrial projects but fails in complex ones. With complex problems, we do not know what the unknowns are, we cannot plan for them, we can only experiment and let the learnings emerge.

Scrum (and Agile) replaces the industrial plan-driven approach with experimentation. Scrum is difficult to use effectively because it is not a process, it does not tell you how to work; it only gives you the environment for the best ways of working to emerge. The result will be unique, it will be the process your team creates to solve your team’s problems.

For this kind of environment, people with a different mindset are needed. People who expect to do what their manager asks them to do, in the way they are told to do it, are helpful only when work is predictable. When dealing with complexity, when not only the solution but even the problems are not known yet, we need people with a holistic understanding rather than experts in a single area. We need people who continuously look for new ways of working through discovery, experimentation-based learning and collaboration.

We need people with a different set of personality traits and values, we need people who can deal with ambiguity, who appreciate that healthy conflicts are key to collaboration to learn and innovate, who experiment enough to be confident and proud of what they produce, who have a customer-centric mindset and who accept to own their work and be self-directed.

It Starts with Hiring

Too often, we hire based on skills (soft or hard) exclusively. We should continue to care about them, but we should also look for the personality traits and values that are key for success with complex work.

Personality Traits

Let us start with personality traits. What kind of questions can we ask to identify individuals who can handle ambiguity, manage conflicts, are eager to experiment, and what should we look for?

Ability to handle ambiguity (thrive with partial information in a complex environment)

• Question: Tell me about a situation in which the customer or user of your service or product kept changing their mind and were not sure what they wanted.
• Observation: Identify people who treat ambiguous situations as opportunities to learn with the customer, to experiment and to try out new ideas.

Agreeableness and straightforwardness (healthy conflicts)

• Question: If someone in the team continues to have a different point of view about the customer and solution you deliver, what would you do? How do you typically deal with this conflict?
• Observation: Create opportunities for questions and focus on how your answers land. The way your interviewee asks follow-up and clarification questions is often a valid indicator of their listening skills.

Willingness to experiment (innovation and learning)

• Question: What experiment have you tried in the past to challenge the existing approach or process, and how did it help?
• Observation: Look for the interviewee's initiatives to try something new and challenge the status quo. If it was successful, what additional changes were proposed? If it failed, what learnings came out of it?

Willingness to learn and contribute across functions (cross-functionality and collaboration)

• Question: How did you contribute to your team outside of your main responsibility or function? What new skills have you acquired from your team outside of your primary function?
• Observation: Identify people who collaborate with other functions in their team to support them and learn from them, even if it is not part of the person’s main responsibilities.

Values

Also, look for work values. What kind of questions can we ask to identify people who care about the product or service they provide, put themselves in the customer's shoes, and can take accountability for the work without being asked for it?

Pride in the product (ownership, leading to higher quality and innovation)

• Question: Tell me about a product or service you helped create. What excited you about this product?
• Observation: Pay attention to how they talk about their product, its value and contributions, and the outcomes it has achieved. Delivering products in a large and complex organization is always hard, especially when there are many different people involved. But despite the complexity, agile teams take ownership of their work and enthuse about its value and contributions; they expect problems and challenges, yet focus on the achieved outcomes.

Customer centricity (higher return on investment, shared ownership and higher motivation)

• Question: Tell me about a customer you helped. What was their problem? Why was it important to them?
• Observation: Listen for your candidates’ abilities to step in customers’ shoes; negativity around the customers and their problems could be a red light.

Self-direction (lesser need for command-and-control and faster decision making)

• Question: Tell me how you work with your boss. What do you expect from your manager?
• Observation: Pay attention to what they expect from their superiors, including their bosses or managers. As self-organizing and empowered teams are the foundation for agility, people who look for a lot of guidance and support from their superiors may not be the best fit. People who can unleash their creativity based on minimal guidance to create value-delivering products are more likely to thrive.

On-Boarding

As a side note, I will always remember my first day in my first Scrum team. At 9 am, I had my first Daily Scrum, and I was asked “What do you plan to work on today?” I was lost, the only knowledge I had about the product came from the information I received during the interview a couple of weeks earlier. The colleagues I just met minutes ago were all looking at me, waiting for me to tell them my plan for the day. My answer probably sounded like “mmm… I don’t know… I don’t know anything on this board…” Their answer was simple enough “Just pick one, preferably close to the top of the board, and one of us will work with you today.” We continued with the same approach for a couple of weeks, working every day with a different colleague on a different part of the product, until I was able to say “I will work on this today, and it is ok, I don’t think we need a second pair of eyes on this one.” The amount of pair-working decreased over time, but never disappeared completely, and I was happy I joined a team without having to go through long presentations or documents. I was treated as a professional colleague from day one.

It Grows Through Reinforcement

Hiring certainly is the first step, but the Agile mindset needs to be continuously nurtured and promoted. Also, since it is unlikely you will change your entire team, some people will grow the mindset on the job. When used appropriately, the following practices will help anchor the cultural change.

Work-in-Progress Limits

Work-in-progress limits look simple, but they provide a very powerful tool to increase cross-functional collaboration (and reduce bottlenecks in your workflow). Consider the situation depicted by the following image:

It is Wednesday, the team just passed the middle of the Sprint. At the end of the day, developers (programmers) in the team are done with Product Backlog Item (PBI) 9 and 7. Two options are presented to them.

• Without work-in-progress limits: Tomorrow, at the Daily Scrum, they proudly announce they are done with their work items, push them to testing, and pick item 10 and item 11 for development. Individuals responsible for testing look at their colleagues’ queue with envy, thinking: “We have so much testing work left. I hope we will be done by the end of the Sprint, but it is unlikely.”
• With work-in-progress limits (i.e., max 3 items in testing and 5 items in development): Tomorrow, at the Daily Scrum, they proudly announce they are done with their work items, but they cannot push them to testing since it would exceed the work-in-progress limit for that column. They cannot pull a new item from the queue either since the development column is maxed out as well. The only option they are left with is to ask their colleagues: “There is a lot of testing work left in the team, is there any way we can help?”

These work-in-progress limits will lead to:

• Increased cross-functional collaboration: In the previous example, the developers might have limited experience in testing. The first time this situation occurs, they will not be able to do the testing work alone. After a few weeks, the testing experts might be able to delegate some of the basic testing to their colleagues. After a few months, the developers might be able to do most of the testing work by themselves, leaving only for the most advanced cases to the experts. Obviously, it also works the other way around, testers supporting developers, and with other functions such as analysis.
• Focus on the delivery of value: Another benefit we get in the previous example is to force the team to focus on value delivery rather than utilization. We do not try to get as many items started as possible, we focus on finishing as many as we can. This ensures we do not close Sprints with a lot of work left in progress.
• Whole team feeling: Lastly, it creates a whole team feeling. It feels much better when help is offered without having to ask for it. It shows that our colleagues do not care only about their “tasks”, but they care about the entire team. We win together, or we fail together.

Cross-functional Learning

One requirement to have cross-functional collaboration is skilling. As discussed, work-in-progress limits can create cross-functional learning opportunities through pair-working, but other techniques can also be used.

Skills matrices are frequently used to generate transparency on the skills availability and bottlenecks in the teams. They create visibility on who you can work with to learn a new skill, and which skills need to become more common in the team.

Another technique we applied in a team I worked with was to “force” each team member to work on something new every Sprint. Each iteration, I had to pick a task I did not know anything about, and work on it with someone. I would not be “punished” if I did not do it, but it was more than allowing me to learn something new; learning was part of the team’s DNA. Instead of saying “we are willing to invest in your skills, but only if…”, it was “if you are part of our team, you have to invest in your skills.” Even when we were under pressure, we continued to follow our values.

Risk-Taking and Experimentation

Agile is all about inspection and adaptation, which requires transparency. And transparency will not occur unless there is psychological safety. When team members feel safe, they feel they can raise concerns, they can argue to identify the best solutions and they can try new approaches. Also, the safer they feel, the more they open to their colleagues to learn from them and to rely on them. Frequently, teams must be reminded that failure is ok (as long as they learn something out of it) to create this feeling of safety.

Unfortunately, even when psychological safety is present, experimentation does not happen automatically. Everyone is more comfortable continuing with “the way we have always done it” rather than experimenting with something new. Sometimes, there needs to be a reminder that thinking outside of the box and innovation are good. When this little “push” is not coming from the team members themselves, it should come from the Scrum Master. We should not try new things only when we are stuck, we should try new things as frequently as we can and see if we can learn something out of it.

The Scrum Master

These practices, and the many others that might help the team when they face a challenge in their growth, must be applied in a way so that the team understands their value. Applying any technique mechanically when dealing with knowledge work is useless and can even deteriorate performance and engagement. “We have to do Agile/Scrum/Work-in-progress limits/User Stories/… because the Scrum Master/Manager/… says so” is unlikely to make any of these changes succeed.

There comes one of the most misunderstood concepts in the Scrum world, the Scrum Master role. The Scrum Master is not the new name for the Project Manager, it is not the JIRA housekeeper or the meeting organizer. Scrum Masters, according to the Scrum Guide, are true leaders who serve the Scrum Team and the larger organization. Among the different ways they serve the Scrum Team, the first one listed in the Scrum Guide is: coaching the team members in self-management and cross-functionality.

The Scrum Master leads the Scrum Team by helping them understand why they are doing Scrum, and how different techniques, principles and values can solve the problems the team is facing and make their life better. If you are a Scrum Master, consider the following question: “If I ask one of the team members why we do Daily Scrum, what will this person answer?”

• Because you (the Scrum Master) told us to do it
• If we don’t do it, it is not Scrum anymore
• I do not know; I am just doing what I am told to do
• I do not know; we have always done it
• Because it helps us find opportunities for collaboration and reduce risks and surprises in our delivery

If you get one of the first four, your next question should be “If it does not make sense to you, why didn’t you say something?” and start promoting an Agile mindset here.

Performance Evaluation

Performance evaluations have also a big role to play in the team’s culture. It drives behavior and can, when done improperly, significantly impede collaboration, willingness to experiment and customer-centricity.

Everyone in the team (except, maybe, for Product Owner and Scrum Master) should have the same goals and measures. They should cover the delivered business value and predictability, number of bugs and code quality metrics, and continuous improvement. Cross-skilling should also be part of it, with a focus on teaching for senior employees and acquiring new skills for junior ones.

The Scrum Master measures would focus more on driving continuous improvement, Agile/DevOps practices adoption, cultural change, organizational support, and employee morale. For the Product Owner, we would focus more on customer satisfaction, return on investment and delivery team enablement.

Conclusion

Traditional organizations with rigid roles face challenges when trying to keep pace with changing needs. The problems we have to solve and the environment we operate in are different every day and, as the illusion that we can plan everything fades away, we realize we need individuals who will be able to thrive in positions we did not know we needed. Only the people closest to the products and to the customers will know what is needed, and they can only get it through cross-functional understanding and collaboration, and continuous experimentation.

Source for some of the interview questions: How to Select and Develop Individuals for Successful Agile Teams: A Practical Guide | Scrum.org

Disclaimer: The views and opinions expressed in this article are those of the author and do not necessarily reflect the official policy or position of his current or past employers.