development

Articles

Fish jumping into bigger bowl 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
Stacked rocks: work not done 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
Two birds: pair programming 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
Agile Development Conference West logo 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
Thinking Critically about Software Development 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
No Estimates Making Sense of #NoEstimates

A couple of years ago, the Twitter hashtag #NoEstimates appeared. Its purpose was to start a discussion about alternatives to estimations, but the idea of a project without explicit estimates is odd to most people in software development. However, if you start exploring it, you may find better sources of information to rely on.

Gil Zilberfeld's picture Gil Zilberfeld
Using Your Tools Always Read the Label: Getting the Most from Your Tools

It is possible to find a new, innovative use for a tool, but it’s much more likely that you’ll do better using the tool in the way its creators intended. And whenever you reach for a tool, check that it’s actually going to help solve the challenge you’re facing. This article explains why first and foremost, conversation is more important than a shiny new tool.

Seb Rose's picture Seb Rose
Value and Innovation Team Assembly and Its Impact on Value and Innovation

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.

Michael Rosenbaum's picture Michael Rosenbaum
Mob Programming Getting Started with Mob Programming

Mob programming is a software development approach where the whole team works on the same thing at the same time, in the same space, and at the same computer. Collaborating like this can have great benefits for everyone involved. Here, Woody Zuill details some practices his team uses to make this collaboration work for them.

Woody Zuill's picture Woody Zuill
Don't Shoot Agile in the Foot How to Plan and Execute Programs without Shooting Agile in the Foot

Program planners in IT organizations have a dilemma: On one hand, their agile teams tell them that if requirements are defined up front, agile teams cannot operate; but on the other hand, the program’s budget and scope need to be defined so that resources can be allocated and contracts can be written for the work. How does one reconcile these conflicting demands?

Clifford Berg's picture Clifford Berg

Pages

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.