After decades of talking about test automation, the agile movement suddenly seems to be taking it seriously. You might be wondering what all the buzz is about. Sanjay Zalavadia talks about why test tooling is suddenly so critical, when teams should think of automating, and how to bring the change so that your team will embrace it.
Some teams only work with stories, but it can be difficult for a team new to agile to write stories that are easy to understand and provide value every time. An alternative is to add epics and tasks. Understanding the differences between each level and knowing what size story to use for each situation will improve the accuracy of your sprint planning.
As agile principles and practices receive greater organizational exposure, business teams are embracing certain aspects of agility that were traditionally reserved for technology teams. This article details the experiences of a group of people with business roles who have adopted some agile methods and how their teams have benefitted.
In this article, a developer shares his personal experience with the transition from a waterfall environment to an agile one. He compares what it was like for him coding, learning, and communicating using each methodology, and he shares what it was like making the change to agile—and why he's never looking back.
Too many user stories begin, "As a user …" Who is your user? Or, more accurately, who are they? Improving your understanding of the types of customers who use your software lets you see multiple products where previously, there was only one—and identifying dedicated products will help you prioritize and accelerate delivery.
There are two practical goals for user stories: Each story should be beneficial to the business, and each story should represent a small piece of work. However, there is tension between these rules, and they often push in opposite directions. This article discusses how to keep stories small and tasks manageable, while ensuring they retain business value.
One of the twelve principles behind the Agile Manifesto is “Simplicity—the art of maximizing the amount of work not done—is essential.” Why is this principle called an art, while the others aren’t? And why should we maximize the amount of work "not" done? This article analyzes the importance of simplicity in agile projects.
This article details a team’s experience in implementing pair programming as a way to get work done as part of its agile transformation. It delves into the many positive results from the pairing experiment, as well as some of the negatives that were encountered, and weighs whether developers think pair programming is a worthwhile endeavor.
Usually noise has a negative connotation, but in this sense, noise means something that increases the team progress (i.e., velocity) and output (i.e., quality). Chaos is the negative side of noise and decreases velocity. Teams should know the importance of agile noise and handle the chaos in a right way at the time of transformation. Let’s explore agile noise and its benefits.
Of course, all companies would like to reduce their budgets. But cutting back in the IT department can have unintended consequences. This article looks at two of the more well-adopted cost-cutting approaches, the software factory and distributed teams, and goes into how they can help and hurt your company.