Allow People To Do What They Think Is Best

To find out that the programmers in the team are seeking out product owners, stakeholders, and teammates on their own to ask clarifications and start meaningful discussions is a positive thing for me, to notice them initiate communication to whomever they need to talk to is always a major confidence booster about their ability to work on problems on their own. They never need my authority or permission to do what they think is best, they manage their own tasks, they own the responsibility to do the right thing as they see fit. I’m just there to help them perform the best work they can, in the form of suggestions and testing.

That’s why it’s bewildering to see someone get disappointed over a behavior that I deem to be on the plus side. Why would letting developers talk directly to stakeholders make you feel overstepped, if they think it supports better work? It seems to be, at least for me, a shallow use of a leadership position, a certain level of being clingy to power that’s not serving the team mission. It’s an upsetting, controlling reaction that I feel does not do any good.

Focus on empowering the team.

Advertisements

Takeaways from Janet Gregory and Lisa Crispin’s “More Agile Testing”

If I am to be asked to name female software testers who I look up to, I’ll probably say I can only name two so far: Lisa Crispin and Janet Gregory. Why them? Because of the many software testing lessons they’ve shared to the testing community through the books they’ve written, especially ‘More Agile Testing‘, which is a treasure trove. Some favorite excerpts:

About software testing:

  • Testing expertise is a lot more valuable at the beginning of any project.
  • Testers need T-shaped skills. To be effective on any given team, we need both deep and broad skill sets. Deep knowledge and extensive practice in a single field make sure that we bring something essential to the team. On the other hand, broad knowledge in areas other than our own specialty helps us collaborate with experts in other roles.
  • Abilities such as communication, collaboration, facilitation, problem solving, and prioritization can be the most difficult to master, yet they are the most crucial for success in agile testing.
  • The most useful thinking skill is to know how to help your team address its problems, rather than going in and fixing the symptoms. And you don’t have to be in a management position to provide leadership for your team and help them improve their problem-solving effectiveness.
  • It’s possible to automate lots of tests and still fail to deliver what the customer really wants.
  • Testing does not produce quality; it produces information about quality. At a high level, the outcome we want from testing is confidence in our decisions to release software changes. Better testing produces greater confidence in those decisions. Therefore, the valuable product of effective testing is confidence.
  • Testing is more than just testing software. It is about testing ideas, helping business experts identify the most valuable features to develop next, finding a common understanding for each feature, preventing defects, and testing for business value.

About being a test manager:

  • The role of a test manager extends beyond the scope of the day-to-day work of the agile team. Much of his work involves looking outside of the iteration activities and more at the cultural and strategic needs of the testing operation. A test manager can also be a type of coach for the communities of practice within an organization. The test manager is not there to prescribe but can facilitate learning sessions where interested parties can discuss new ideas. Management and Leadership is the ability to hire and inspire great people, to remove or overcome organizational constraints and impediments that hinder them from doing their best work, to see and exploit the opportunities for people to excel, and to motivate individuals to achieve what is best for the team.

About learning, and agile:

  • Our real goal isn’t implementing agile; it’s delivering products our customers want. And when we start asking why the customers want the feature (the problem they are trying to solve), we’re more likely to build the right thing.
  • In the software profession (as in many others), people seem to forget that it takes time to learn and practice a new skill.
  • Learning is itself an agile process. Learning is not a big bang process: you know nothing, read a book, and two days later you’re an expert. Learning, like features, is something you do in iterations, adding a bit more knowledge at a time, and then building on it the next iteration. It’s not a race to the finish, and there is always something more to learn.
  • Empathy is essential for providing good feedback.
  • Changing an established culture is difficult.