You may have heard of Selena Delesie, frequent Software Test Professionals conference speaker and perhaps the most famous test consultant to come out of Research In Motion. RIM created the ‘BlackBerry’, the first massively successful integrated mobile device. When Selena started there, the BlackBerry was a fruit.

You might even know that Selena is a test consultant, specializing in working with teams, helping them ‘gel’ and develop, as both a consulting software tester and an Agile Coach.

Yet you probably didn’t know that she has a college degree in combinatorics – perhaps the single most cause of the explosion in complexity of test projects.

Given her background, we thought it would be fair to invite your questions about teams, teamwork, customers, tough bosses, and other ways we have to deal with those fleshy carbon-based life forms we see every day.

Selena will now answer your questions.

Question: Sometimes team structures can change dramatically over the course of a project. A tester who finds themselves managing their workload, may soon find that someone is placed over them, and now they report to this person and are maybe ‘guided’ a bit by them also. Finding yourself in such a situation could prove a bit of a minefield to navigate for some. What is your advice to testers who may suddenly find themselves squeezed within layers of bureaucracy, to maintain accountability upwards, but still exercise leadership, and use their own talents and experience to better the project and team? Timothy
Western, Hinton, West Virginia

Selena: A new manager can wreak havoc in the day-to-day rhythm for people. Why does this happen? A new manager wants to know what’s going on. They want to learn the projects, technology and processes. They may want to form relationships with people. Sometimes they want to exert control over the team so everyone knows who’s boss.

In these situations it is necessary to build a relationship with the new manager, establish trust, and be proactive. It will be difficult to exercise leadership and fully contribute your talents and experience otherwise. I have found it helpful to adjust to the new structure by:

  1. Meeting with the new manager to share your background prior to, and at, the current company. You want them to know about you, the roles and responsibilities you’ve had in your career, and the special things you bring to the team and company. The sooner you are able to start building a relationship with the new manager, the sooner they will trust you and stop micro-managing.
  2. Learn about the new manager. You want them to know that you are interested in what they bring to the organization and that you will support them. What have they done in their career to this point? What attracted them to this role, organization, and company? What are their goals for the organization? What help do they need to achieve that? What is important to them in terms of the team, projects, and process? What isn’t important to them? How often would they like information about what you’re working on and how would they like it communicated?
  3. Be proactive. This includes sharing information, identifying issues and recommending solutions, and undertaking initiatives that improve the value of the team. Being open, honest, and a visible leader allows the new manager to back off because you have consistently demonstrated that you will keep them in the loop and tackle problems as they arise.

Question: I often seem to find myself in a position where I’m expected to lead but I’m granted no management authority. How do you see the function of a leader and a manager differing and what are some strategies for leading without hierarchical authority? Curtis Stuehrenberg, Seattle, Washington

Selena: A manager focuses their energy on doing things right. They often work to satisfy the bureaucratic needs of the organization before what may be the right thing to do. For example, they might insist on team members following a process that adds 75% overhead to a project activity, because the process and their boss require it. The process and overhead then eats away at the quality and quantity of work people contribute to the project, resulting in poorer quality and significantly delayed projects.

A leader focuses their energy on doing the right thing. Leaders don’t usually get mired in organizational bureaucracy when making decisions. They consider bureaucracy along with all other information relevant to the situation so they make decisions that support the best in the people, team/organization, project, and relevant processes. Colleagues trust them to make good decisions, offer appropriate advice, and do what it takes to guide the situation to improvement.

Note that some managers are leaders. They are able to balance doing the right thing with doing things right, as they base decisions on the entire context of a situation. Those managers may be hard to find in some organizations.

So how can you lead without hierarchical authority?

  1. Build relationships. People are more likely to follow someone’s lead when they know something about each other both personally and professionally. Learn about what they like to do outside of work, chat with them throughout the week, and ask about what they enjoy about their job. Show that you are interested in them, not just what they do for the project.
  2. Earn respect. People want to work, collaborate, and learn with people they respect. People give respect when someone consistently does what they say they will, makes decisions that support the best interests of those involved in the situation, share information openly and honestly, and treat others with respect.
  3. Involve others. In a leadership position with no explicit authority, be cognizant to involve people in a variety of ways. Be open and forthcoming in sharing information so people know you aren’t hiding things from them. Include people in discussions and ask for their input and idea’s so they know their opinion matters. Focus your energy on learning from and with the people you lead and they will in turn follow your lead.
  4. Be sincere. People have a nose for recognizing insincerity and will quickly discount your authority as a leader.

Question: Let’s say a development team (including all roles) decides they are committed to delivering the best possible software they possibly can, but their management pushes them to cut corners and work overtime to meet deadlines. How can they explain to management that accumulating more technical debt will slow the team down even more in the future? Lisa Crispin, Castle Rock,

Selena: Talk to management about the impact of situations like this in terms of business risk and money. Management cares about saving money, making money, and the company reputation. When a project is pushed to release to meet deadlines by cutting corners and mandating overtime, they are focused on meeting or exceeding revenue targets. Even if they understand these decisions reduce product quality and push work downstream to a later project, they don’t usually grasp the full impact.

Management doesn’t understand the impact of having staff work at an unsustainable pace. Overtime is seen as a method to get more work hours done in the same calendar time, which in their mind equates to meeting deadlines.

  • In this situation take some time to understand the business risks. Do you have recent or similar project data that shows an increase in software defects reported internally and/or externally as a result of a lot of overtime? Is there data available that shows a reduction in revenue, market share, or customer base as a result of such a project? Share this information with management and extrapolate what the business risks will be for the current project when you express your concerns.
  • Now go a step further and use this data to estimate how much money it will cost the company, in terms of revenue loss and additional costs to support a low quality product. Management is more likely to take your concerns seriously when they hear that an expected 10 hours of overtime a week by each employee is going to cost 40% of the project budget in the next quarter alone to deal with reported quality issues.

Management also doesn’t fully grasp the impact that cutting corners in design, code, or test has on current and future projects. Here, follow the same approaches as above but focus on how cutting corners in previous projects increased business risks, increased costs, and reduced revenue, market share, and the customer base. Provide a comparison with what these will look like if the project proceeds without cutting corners.

While you could spend hours or days pulling this information together, you shouldn’t need to. Most organizations have a bug tracking database, quarterly financial reports, project time tracking tools, and project budgets readily available. If not, find someone who has the information to share it with you. From there you can estimate a base hourly rate for employee time and do some quick calculations to support your argument.

Start by understanding and communicating business risks, not just technical risks. If that doesn’t help, move on to the money data. Keep in mind that sometimes, regardless of what you do, management will still make the same decision. They may be willing to accept the risks and financial impact in order to satisfy some other business need you are not aware of. In future projects, be sure to push the decision about what the team focuses on into management’s hands so they are held accountable for their decisions.

Question: I have lots of experience with managing software dev and QA teams, but they were not officially practicing Agile. I’ve also had plenty of Scrum training (ScrumMaster Cert + tons of reading/writing about it) and I’m a certified CTI coach, so I’d love to get into Agile coaching, but all the jobs require so many years of Agile experience under your belt.

What opportunities are there for volunteer Agile coaching? Any other ideas of how to build up that skill set so it can be used on a resume? Yvette Francinco, Colorado Springs, Colorado

Selena: There are a lot of options available for you to get started as an Agile coach. The good news is that your experience in managing and leading both development and QA teams is transferable. Your coaching skills in helping people and projects succeed are fully relevant in an Agile environment. It is also good that you are actively reading and learning about Agile through a variety of avenues – keep doing that!

Some things you may want to consider trying:

  • Take a position as a Scrum Master or Product Owner. Emphasize your experience managing software teams and projects, how you are learning and keeping current in Agile knowledge, and your passion. Doing a stint in one of those roles will help tremendously in building your resume for an Agile Coaching position.
  • Are you looking at jobs in companies that need Agile coaches, or a consulting/coaching firm who employs Agile coaches to work with client organizations? In the first situation, try approaching a company via someone in your network about coaching Agile teams free of charge to build concrete experience, expand your network, and gain references for your work. You can also try this in the second situation. If you haven’t searched for Agile coach positions in both of these avenues, then do that too.
  • Build an online presence for yourself as an Agile Coach. Contribute your insights and ideas to Agile forums, comment on articles, write your own articles, and blog about different Agile topics. Use Twitter to gain a following and direct people to your writing and ask them to comment. You can add all of this to your resume to support your brand as an Agile coach. Use LinkedIn to support this and ask for trusted colleagues to provide references that speak to your Agile knowledge, coaching skills, and team development.
  • Build and maintain a network of people in the Agile industry. Attend Agile peer workshops, coach camps, and conferences. Promote these activities on your resume. Build relationships with people you respect in the industry. Regularly connect with them to discuss ideas; you want them to get to know you and the value you can bring to an Agile team as a coach. Once you’ve done that, the same people you respect will start recommending you for coaching gigs they think you are a fit for.

Remember, every Agile coach had to start somewhere. They didn’t all get coaching jobs because they were Agile Coaches. They got them because they established a positive reputation in their field, gained credibility, and demonstrated strong coaching skills.

Question: What would you tell a tester who would like to collaborate more
with programmers, but isn’t sure how to get started? Gary Masnica,
Seattle, Washington

Selena: Figure out how open the organizational culture and the programmers are to collaborative activities. If they are very open, just ask! If not, you may need to start small to ease them into more intensive collaborative activities over time. To get started, ask to collaborate on: requirements reviews, design discussions for new features, troubleshooting problems encountered in testing, creating a strategy for testing a feature, diagnosing defects, and design reviews. Activities that are a big culture shift, such as pair programming and pair testing, might need to be progressed towards.

For other thoughts, see my response to the next question.

Question: Follow up question, if I may. How would you best explain the benefits of programmer/tester collaboration and why it should be done? What if the programmer/tester is in an adversarial environment and is intimidated by collaborating? Gary Masnica, Seattle, Washington

Selena: Simply telling someone they should collaborate because it is better will rarely win them over.

In an adversarial environment you need to spend time establishing relationships. Some people need to have something in common, mutual respect, and feel valued before they will step outside their comfort zone. They may be inclined to collaborate with you when you know something about each other both personally and professionally. Learn about what they like to do outside of work, chat with them throughout the week, and ask about their job. Show that you are interested in them, not just what they do for the project. Earn their respect by consistently doing what you say you will do, sharing information openly and honestly, and treating others with respect.

Once relationships feel healthier and more positive, talk about what you would like to collaborate on and why you would like to do it. Describe the benefits for them, for you, for the team, and for the project. For example, explain that collaboration for activity X will:

  • Save them time. Be specific about what and how.
  • Reduce the amount of bugs they need to work on. Describe how that will happen.
  • Provide them with more time to work on fun feature development. Explain why that will occur.

Ask them what they think. Discuss any concerns with an open mind. Then ask if they would be willing to try it, and if not, what needs to happen before they will? They might need time to let your new ideas sink in and feel comfortable enough to try them. If you are having difficulty gaining agreement to collaborate on a particular activity, you may need to start smaller (see suggestions in previous answer).

Question: I’m working as a test manager in a project where I have an off-shore dev and test team to lead. The time zone difference is quite small so we have decent overlap in working hours. We use Skype for continuous communication, we have a shared wiki for instructions, backlog and a defect tracking system everyone on the team can access but I still feel our level of communication is lacking. This results in a lot of bugs we really wouldn’t need to have. Do you have any advice on how we could improve on this and try to prevent some of the bugs caused by insufficient communication? Petteri Lyytinen, Finland

Selena:It sounds like you are doing a lot of things right already! Tools like Skype are incredibly helpful for keeping distributed teams connected, and wiki’s are helpful for keeping information in one place that everyone works from. If you aren’t using the Skype video chat feature yet, I recommend using it for team communications. Being able to see and hear each other during conversation helps forge stronger relationships, which leads to increased and improved communication.

I recommend having a team retrospective focused on exploring the impact of insufficient communication on the project, and how to improve team communication. Telling the team what to do to improve communication isn’t going to make it happen. Behavioral changes rarely come from being told to change. They come from understanding the impact of a behavior and deciding what will be done to change. Have the team create a working agreement that outlines specifically what healthy and productive communication looks like for the team, and get everyone’s agreement that they will hold themselves and each other accountable to it.

Question: Do you agree with the concept that being a manager for a team means not being a doer anymore? Why or why not? Mark Vasko, Cleveland, Ohio

Selena: No, I do not agree with the concept that being a manager means not being a doer anymore. For example, I have a colleague who has worked in a small company as a manager with four team members and was able to successfully be a doer about 60% of the time. As a manager with a small company, the team members required little management, and the company hadn’t yet grown overly complicated or rigid. That said, when that same colleague moved to a larger company there was more responsibility, direct reports, and bureaucracy to balance, so they had no time to be a doer.

Even if the company culture and team support it, some people will not be able to balance being both a manager and a doer. Wearing a management hat requires a different type of strategic and reflective thinking than that of a doer, and it can be tricky to balance both and wear them at the right times. The team members might struggle with how to interact with the manager if they don’t talk about what that should look like. The manager will need to be careful in their role as a contributing team member that they don’t exert their influence and power as a manager over the other team members.

So, it depends on the team, the people involved, and the company culture as to whether a manager can also be a doer.

Question: How do you, as a leader or manager, introduce new ideas to a team for them to try without getting pushback or resistance from them?
Ted Young, San Francisco Bay Area, California

Selena: It helps to know the team members well enough to be able to anticipate where you might get push-back or resistance. If you don’t know that yet, spend some time getting to know them. Learn about their values, strengths, concerns and worries. Then consider whether the collective team may push-back in ways different than each individual would. Talk to each of them about your idea and why you would like the team to try it, and then listen to their feedback and concerns. Talk about it!

Recognize that it may take time for people to become open to trying new things. You might need to warm people up to the idea by talking about it in small doses over a period of time. People like comfort zones and are often perfectly happy with things the way they are. Discuss the benefits of trying the change and how the new idea will help them in their daily work, their personal growth, or anything else. Describe the potential impact the change will have on the team, project, and organization.

Finally, consider that push-back and resistance is fuel for improving on the new idea. Maybe there is a good reason the team is resisting that you haven’t considered yet. Be open to new ideas your team members have. Fully explore ideas as a team and discover an improved new idea that everyone will buyin to. The newer idea might be a step back from your perspective, but may provide an improvement in the team process and function that you weren’t expecting.

Question: Can you really have team work with others who are the anti-social programmer stereotype? Jon Hager, Denver, Colorado

Selena: It depends on the behaviors of individuals and their personality types. Some people are introverts – they enjoy working alone and gain energy from doing so. As team work requires collaboration and communication, introverts may be drained by all the interactions. Other people may be deep thinkers who need time to think about and explore information and ideas more thoroughly than other team members might. Yet other people may be highly tuned to the emotions and feelings of those around them and choose to avoid interactions where they are likely to be bombarded with negative energy from others.

Do you see my point? Just because someone is identified anti-social, it doesn’t mean that they are truly anti-social in a negative sense. Different people have different needs and may need more down time from team collaboration than others do. Performing teams will respect that and work around those individual’s needs.

That said, there are people who refuse to work with others collaboratively and productively and insist that they must work on their own. If those people are unwilling to work with the rest of the team collaboratively and productively, then you can’t have team work.

Question: Say a team has two testers who are very good individually. Anytime they are assigned projects and they need to work with other team members, their productivity drops. If they are the solo tester, the output is really good. How do we handle such situations? Do we continue to provide them individual projects or what do you suggest to help them deliver results when working in a team? Ajay Balamurugadas, Bengaluru Area, India

Selena: Several things you should consider before making any decisions:

  • How do you define productivity? Is it a function of the number of test cases they write and/or execute, or do you have a different measure? There are lots of helpful and not-so-helpful (dangerous) ways to discern someone’s productivity. Make sure your focus is on value adding contributions, not just making numbers happen.
  • How do you know that the two testers are good individually? What information do you have to support that? Is output related to the number of test cases they can write and/or execute? Or is it related to something more tangible and valuable? Again, ensure your focus is on value adding contributions, not just making numbers happen.
  • What do you see happen when these two testers are working with other team members? Maybe they spend more time talking than they do working. Perhaps they slack off because there are other people to carry the load. Maybe they struggle in collaborating and making decisions with others? Or maybe they are spending a lot of time mentoring, coaching, and answering questions for other team members.

Spend some time to figure out exactly what is going on before deciding that the two testers are a problem. Understand the information you are using to decide that they are not performing while working with a team.

If after doing this analysis you discover that there is a problem, ask yourself what is more important for the organization: The few successes of individuals, or the many successes of the team? Projects, teams, and companies succeed when people work collaboratively, critically, and creatively together. You need to decide whether they are worth keeping on board, so consider whether their contributions are significant enough to invest the needed effort to coach them to become strong contributors in a team environment.

Question: When transitioning to Agile testing, specifically the whole team approach where testers and programmers constantly collaborate, many organizations find that their testers’ manual testing skills are not adequate. At the same time testers may feel that that they are being pushed into a less technical and prestigious role and are resisting the Agile transformation. What is the best way to empower the testers to enjoy their new role and interest them in test design and exploratory testing skills? David Vydra, San Francisco
Bay Area

Selena: I don’t often hear about testers who feel that their new role on an Agile team is less technical; more often I hear about testers who are concerned about having to become more technical. In both situations the tester needs to be supported and coached through their changing role so that they can gain the skills and confidence necessary to be strong contributors on an Agile team. A few ways to do this:

Talk to them about what the responsibility changes mean to their role. Listen to their concerns and try to alleviate them. For instance, if they think their job will be less technical, explain that on many Agile teams testers gain scripting and programming skills so they can contribute to the team in different ways. If they think that exploratory testing and thoughtful test design is boring and a waste of time, do an exercise with them using a simple program or fun simulation to illustrate otherwise.

Help them devise a learning program to succeed through the Agile transformation. Provide learning and training opportunities to support them through the transition. Help them gain the skills they need to succeed. Interactive workshops in particular can be a fun and engaging way to do this.

  • Focus on how the new interaction model benefits their personal growth, the project, and team success. Explain why communication and collaboration models are important. Highlight how they can have a bigger impact on the project because they are involved in the project early, often, and deeply. Help them see that they have an opportunity to be more visible in the organization and contribute to the company success on a broader scale.

About the Author

Selena Delesie I am a consulting software tester and agile coach, and run my own company, Delesie Solutions. I have more than 10 years of experience testing, managing, and coaching in software, testing, and agile practices for leading-edge technologies. I facilitate the evolution of good teams and organizations into great ones using individualized and team-based coaching and interactive training experiences. I am also an active speaker, participant, and leader in numerous industry-related conferences and associations. View my blog at, and my business-facing website at