StickyMinds

Coaching Agile Teams is a guide for agile team leaders. In many ways, it acts as a mentor and, borrowing a part of the subtitle, a companion.

When Mary Gorman and Ellen Gottesdiener facilitated a game called The Backlog Is in the Eye of the Beholder for the Boston chapter of the International Institute of Business Analysis, both the players and the facilitators learned some important lessons in organizing a project requirements backlog. In this article, they describe the game and what it revealed, including the value of truly knowing your stakeholders.

At the start of a new year, Michele Sliger looks back across the recent decades of information technology advancement—from the dawn of the personal computer to the abundance of social networking websites—and (with some pointers from Ron Jeffries and Linda Rising) ponders how those advances have impacted our view of change, software, and ourselves.

Fuzz testing, or “fuzzing,” is an approach to test automation that attempts to uncover weaknesses in a system using tool-generated data. In this article, Jonathan Kohl recounts how he used this technique on a published web services interface to test “through the side door”—those testable, in-between areas like messaging APIs.

If you've been involved in software engineering for any length of time, then you've probably heard of Capers Jones. He is well-known for all his work on the software engineering process, so it's not surprising that he's put together a collection of best practices for software engineering.

Large, internal development projects often engage in paradoxical spending, investing the lion’s share of staff and other resources in system development and testing while treating end-user training as an afterthought often accomplished through the least expensive means possible. In this column, Payson Hall crunches the numbers to help you get the most value out of your application training.

In May 2010, the first Writing About Testing conference brought some of the top minds in the field together to discuss the current state of public discourse on software testing and areas where testing is evolving within the realm of software development. In this column, Chris McMahon, who designed and launched the conference, continues his mission to advance the discussion by sharing ten of the most interesting frontiers for software testing.

If you've ever hired someone, been a new hire, or was asked to "show someone the ropes," Steve Trautman’s book serves as a useful guide to the practicalities of peer mentoring. Trautman, a former program manager at Microsoft, explains the techniques that he recommends for efficient mentoring success.

Defect counts are often considered as measurements of product quality. However, the most important defect count in that respect is by definition unknown; the number of undiscovered errors. Defect counts can be used as indicators of process quality. In doing so, one should avoid assuming simple causal relations. Defect counts can provide useful information but have to be presented with care.

In this second half of Steve's article, he prepares for a product release through branching strategies. Here you'll learn how and when to create a release branch to help your team code and test what's needed for a timely release.

Unlike many of today's fashions, Watts S. Humphrey’s book is not likely to be out of style or past its shelf life any time soon. The information provided here comes from years of practical experience and all relates to a recurring theme: quality must be a part of everything you do. Mr. Humphrey's take on the theme relates quality to processes and "soft" skills, such as leading, being led, and being part of a team. Quality never goes out of style. The advice provided today by Mr. Humphrey will be just as important ten years down the road.

Testing is often seen as an effort to determine the quality of the product at the end of a project, so it needs to be executed when development has finished instead of being a means to deal with risks at the earliest stage possible. Therefore, project budget, is in most cases spent on the processes that actually produce tangible products, at the expense of the testing budget. Whatever budget is left for testing will be spent on people rather than on test tools.

This book is a comprehensive resource and provides a wealth of information regardless if the reader is a beginner or an experienced information architect. An asset on any bookshelf, this book delivers an impressive amount of information in the form of tables, diagrams, and insights about enterprise information architecture (EIA).

t's a special skill to be able to terminate disputes amicably. In this week's column, Naomi Karten offers suggestions for how to resolve disputes so that none of the parties suffers from black eyes or bruised egos.

In addition to the efficiency improvements you expect from automated testing tools, you can—and should—expect them to provide valuable metrics to help manage your testing effort. By exploiting the programmability of automation tools, you can support the measurement and reporting aspects of your department. Learn how Jack Frank employs these tools with minimal effort to create test execution status reports, coverage metrics, and other key management reports.

You'll nod your head in agreement with what author Sam Lightstone writes in his book on the career and personal knowledge Lightstone’s gained over the years. Lightstone looks at all stages of a career in software development, from getting the best education, landing the job, working within an organization and team, attaining prominence in your field, to sharing and mentoring others.

Tired of guesstimating your estimation process just to create a completion date management will accept? Jonathan Kohl takes the guess work out of estimations by focusing on uncertainties. It may sound counterintuitive, but the idea is to focus on the fact that all projects face unforeseen delays. The rigorous estimation process Jonathan describes here provides your team a way that ensures enough time is scheduled for development and a date for completion management can agree upon.

This book is all about product owners, whom the author sees as a role encompassing the duties of a traditional product manager, a strategic product planner, some duties of a traditional project manager, and the duties of a release manager. Yet, in my experience, most agile teams have a product owner whose role is often poorly defined, vague, and more likely contained in the duties of several people. The author addresses these issues in an engaging and interesting manner.

High on a mountain twenty years ago, a wise man shared secrets of problem solving that have served Payson Hall ever since. In this article, Payson passes along a simple definition that offers insights into problems and potential solutions.

Many of us have our personal identities wrapped up in our jobs, which can make change hard, particularly in agile environments. Recognizing the power of storytelling, Michele Sliger started collecting first-person stories about how adopting agile affected individuals and what their “light bulb moment” was like. Find out how agile adoptions have changed individuals—their perceptions of agile, their leadership styles, and even their personal lives.