Simply putting a handful of developers together and calling it a “team” doesn’t cut it. There’s a better, more analytical approach to team assembly that results in more cohesive teams, faster ramp-up times to peak velocity, and improved innovation, business outcomes, and value.
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.
Wondering why—with all the jobs you've applied for—you aren't getting noticed? Take it from Xojo CEO Geoff Perlman; it isn't just your programming or testing skills that will land you a job. Far from it. Geoff knows from experience that hiring the right individual is a careful blend of skill, fit, and passion.
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.
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.
To successfully lead “the nerd herd,” you’re expected to motivate your team to perform, encourage innovation, and produce software solutions that delight the customer. Prioritizing your time for what’s most important can be quite challenging—especially when you’re swamped with a...
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?