Articles

Please enter an article title, author, or keyword
Welcome to Agile: A Developer’s Experience

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.

Kris Hatcher's picture Kris Hatcher
Know Your Customers: They Can Help You Write Better User Stories

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.

Allan Kelly's picture Allan Kelly
Relieving Agile Tension: How to Write Small Stories That Still Have Value

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.

Allan Kelly's picture Allan Kelly
User Story Heuristics: Understanding Agile Requirements

Agile emphasizes just-in-time requirements rather than upfront preparation. The requirements person—be it the product owner, business analyst, product manager, or someone else—embodies the understanding of what is needed, and the user story represents the work that needs doing. This article details what user stories are (and what they are not).

Allan Kelly's picture Allan Kelly
The Art of Maximizing Work Not Done

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.

Ledalla Madhavi's picture Ledalla Madhavi
Help Your Team Understand Its Iteration Burndown

A good key indicator for measuring how well your agile team is performing is the burndown chart. It’s a simple concept—as time passes, the amount of work to do decreases. Of course, there will be days when progress is not as expected or tasks end up larger than originally estimated. A burndown can help your team reset and keep stakeholders in the loop.

Dave Browett's picture Dave Browett
Are You Ready for Go-Live? Eight Essential Questions

As real and daunting as scheduling pressures can be, they have to be balanced with the consequences of a potentially disastrous premature go-live. Don’t let all the reasons a system simply "must" be implemented by a target date overwhelm compelling evidence that it is not ready. Consider these eight questions honestly first.

Payson Hall's picture Payson Hall
The Benefits of Pair Programming

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.

Tim Groven's picture Tim Groven
ADC West 2015 Keynote: Lean UX: Turn User Experience Design Inside Out

When developing products, features, and enhancements, you have to have your customers’ best interests at heart. “We’re not just creating software,” speaker Jeff Patton said. “We’re changing the world.” You need to better understand the people you’re building things for, and the only way to do that is to spend more time with them.

Beth Romanik's picture Beth Romanik
BSC West 2015 Keynote: Better Thinking for Better Software: Thinking Critically about Software Development

Software developer Laurent Bossavit delivered the second keynote presentation, about why we need to think more critically about software development. He began his presentation by saying his intention was to make you question what you know—or what you think you know.

Beth Romanik's picture Beth Romanik

Pages

Upcoming Events

Sep 21
Sep 27
Oct 19
Nov 08