One characteristic of agile development is continuous involvement from testers throughout the process. Testers have a hard and busy job. Jeff has finally starting to understand why testing in agile development is fundamentally different.
Do you manage a team or a group? How can you tell the difference, and is it important to differentiate the two? In this column, Esther Derby explains that identifying your associates as one or the other is paramount to how they should be managed.
Geographically Distributed Development (GDD) is a common strategy in the software world today. Organizations are gaining experience in developing software globally and are discovering that the competitive demand for best-in-class, high quality applications requires greater agility in quality management. Unfortunately, IT budgets are not keeping up with the staff required for quality management and the response is to accelerate quality management by leveraging global teams. This article compares and contrasts agile GDD testing strategies for affecting quality management.
There are no best practices for creating a productive, global development organization, just a few good ideas to think about and tailor around your particular objectives. Consider three universal issues every organization must grapple with to make a global agile team successful: data considerations, communications needs, and a company's agile readiness. How you handle each of these issues will vary widely, and there is no one-size-fits-all solution for every organization.
Esther Derby has noticed something lately, namely that when people write about collaboration, they discuss facilitated meetings. Well-run meetings that encourage participation and building consensus are certainly valuable, but there's more to collaboration than just well-run meetings. Esther explains that true collaboration assumes shared responsibility and shared ownership and boosts creativity and learning.
Michele Sliger uses a simple exercise to exemplify the changes self-organized teams cause in any company, especially with the project manager. In this column, Michele explains how to conduct this exercise and how to review and use the results to improve work relationships and communication. Above all, this exercise should help your whole organization understand how everyone's knowledge of a project's initiatives and goals affects the project's success.
Decision making should be approached just like a software project: You have to map out what you want and how you're going to get it. Payson Hall tells the story of a team that set out to find the perfect product—without an official plan. Learn how to avoid the mistakes they made.
You can't get far in your career if people don't trust you. Yet trust is such an elusive concept. It's not tangible. It's not concrete. It's not something you can point to and say, "That's what it looks like." In this column, Naomi Karten ruminates about the concept of trust and offers some ideas about what you can and cannot control in earning the trust of others.
Retrospectives are a great way for teams to inspect and adapt their methods and teamwork, and they're a great way for teams to build on success and learn from hard times. Retrospectives take a critical look at what happened during an iteration (or part of a project) without being critical of people. But not everyone realizes that, says Esther Derby, so in this column she outlines how to approach retrospectives in the most productive way.
Successfully persuading others to adopt your point of view is a matter of neither magic nor luck. It's a skill and like any skill, improvement takes know—how, opportunity, and practice. In this column, Naomi Karten offers pointers to help you strengthen your persuasion skills.