Articles

Please enter an article title, author, or keyword
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
DOC West 2015 Keynote: Why DevOps Changes Everything

The first keynote of the Agile Development, Better Software & DevOps Conference West was Why DevOps Changes Everything, by Jeffery Payne. There are definitely tools and processes that can help streamline a DevOps shift, but Jeff said that fundamentally, building a culture where everybody can communicate and collaborate effectively is key.

Beth Romanik's picture Beth Romanik
Using the Definition of Done to Promote Continuous Improvement

The definition of done is much more than just a checklist for completeness—it can be a mechanism for determining where your product increment can be more complete by the end of your sprint. By using a discussion board with quadrants where you can sort sprint items, you can challenge yourself to see whether a task could be moved earlier in the lifecycle.

Charles Suscheck's picture Charles Suscheck
How Do You Recruit Team Members with Agile Mindsets?

The traditional ways of finding employees are changing. If you want to get a role that will make you happy to contribute to the team, you need to rethink the way you apply for roles. If you are the resource manager, change how you recruit. This article focuses on the qualities you should be exemplifying or looking for if you want to form a team with an agile mindset.

Leanne Howard's picture Leanne Howard
User Story Points versus Man-Hours: Estimating Effort Better

Effort estimation is a major challenge for all the stakeholders of a project. Most people generally underestimate situations that may block progress and consider only the best-case scenario for a project. Your choice of estimation method may not be helping, though. Which would be better for your team: estimating by man-hours or by user story points?

Nitish Tiwari's picture Nitish Tiwari

Pages

Upcoming Events

Sep 21
Sep 27
Oct 19
Nov 08