For any agile-based operation, you can introduce the concept of "velocity values." Depending on the organizational culture, these values may come as monetary rewards, recognition, or other incentives. This can go a long way toward helping management understand how their respective teams work and can provide great insight into mentoring at both the individual and team levels.
The death spiral supersedes the death march in that the death march is a singular event, whereas the death spiral is systemic. It is the result of organizational dysfunction where teams march toward deadline after deadline without reflecting on or questioning if there is a better way to deliver software. There is! Take these positive steps.
Using metrics such as cumulative flow to monitor throughput and quantitative thinking may not seem very humanistic, but by depersonalizing the work being done, we can focus our energies on solving actual problems instead of conducting a daily witch-hunt and shaming people into high performance.
Hiring is difficult to do well, Johanna Rothman writes in her latest management myth piece. Because everyone who is looking to hire has a job, they think they know how to hire. But it’s not easy. You want to hire the best people you can who fit the team and the organization.
Thomas Wessel presents how T-shaped and pi-shaped teams based on each member's span of knowledge, ability to collaborate, and depth of expertise play an important part in how effectively your team performs.
What can happen over a game of golf? You learn what you don't know, you learn more about what you do know, and you learn to listen to what others know. See how two managers and a caddy team up for some valuable lessons about staying out of the rough.
People often point to requirements documents and process manuals as ways to guide a new tester. Research into knowledge transfer, as described in The Social Life of Information, suggests that there is much more to the process of learning. Michael Bolton describes his own experiences on a new project, noting how the documentation helped ... and didn't.
In this interview, Mike Trites, a senior test consultant, talks about his upcoming presentation at STAREAST 2014, the future of metrics, the importance of improving the efficiency of your metrics, and even an interesting take on the old phrase that numbers never lie.
Pat Arcady is an agile and executive coach with FreeStanding Agility. In this interview, Pat discusses ways conflict manifests itself in an organization, the importance of nonviolent communication, and a useful four-step protocol for achieving positive outcomes for all parties.
Companies often go to great lengths to collect metrics. However, even the most rigorously collected data tends to be ignored, despite the findings and potential for improving practices. Today, one metric that cannot be ignored is customer satisfaction. Customers are more than willing to...
One principle architects employ when designing buildings is "form follows function." That is, the layout of a building should be based upon its intended function. In software, the same principle helps us create an integrated design that focuses on fulfilling the intent of the system. Ken Pugh explores congruency-the state in which all actions work toward a common goal. For example, as Ken sees it, if you form and promote integrated teams of developers, testers, and business analysts, then personnel evaluations should be focused on team results rather than on each individual’s performance. If you embrace the principle of delivering business value as quickly as possible, the entire organization should focus on that goal and not the more typical 100% resource utilization objective. If you choose to have agile teams, then they should be co-located for easy communication, rather than scattered across buildings or the world.
When testing a system, one question that always arises is, “How much of the system have we tested?” Coverage is defined as the ratio of “what has been tested” to “what there is to test.” One of the basic coverage metrics is requirements coverage-measuring the percentage of the requirements that have been tested. Unfortunately, the requirements coverage metric comes with some serious difficulties: Requirements are difficult to count; they are ideas, not physical things, and come in different formats, sizes, and quality levels. In addition, making a complete count of “what there is to test” is impossible in today’s hyper-complex systems. The imprecision of this metric makes it unreliable or even undefined and unusable. What is a test manager to do?
In many organizations, management demands measurements to help assess the quality of software products and projects. Are those measurements backed by solid metrics? How do we make sure that our metrics are reliably measuring what they're supposed to? What skills do we need to do this job well? Measurement is the art and science of making reliable and significant observations. Michael Bolton describes some common problems and risks with software measurement, and what we can do to address them. Learn to think critically about numbers, what they appear to measure and how they can be distorted. Improve the quality of the information that we're gathering to understand the relationship between observation, measurement, and metrics. Evaluate your measurements by asking probing questions about their validity.