SALT LAKE CITY — Agile is still growing, the principles are strong, and there is conflict among certain teams who try to be perfect in an imperfect world. Those three principles are what the analysts from Forrester, Gartner, IDC and Ovum discussed at a roundtable talk at Agile 2011 on Tuesday night.

Michael Azoff, Melinda Ballou, Thomas Murphy and David West gave their views on the “park bench” Agile Manifesto presentation, as well as answers to some of the questions from the conference’s attendees.
West said the manifesto actually held up better than the United States Constitution: There haven’t been any amendments. He believed, though, that including the term “teams” in the Manifesto might have been interesting, an idea one of the Manifesto’s signatories mentioned in the park bench session.

Azoff felt that the most important takeaway from the Manifesto and the agile movement is that “agile” should no longer be a buzzword, but simply the way things are done.

The biggest question, he said, is, “How do we build software?” Agile has gone a long way to answer that question.

“Waterfall came from manufacturing, and so the problems with software manufacturing were thought to be a technical issue, but software development is very much about how teams work and solving those issues solves the problems with development,” said Azoff. He added that this way of looking at software development allows psychology to be considered in decision-making, positive emotions and how teams work—something that was the subject of many sessions at the conference.

The term “ScrumBut” is one of the main contention points among conference attendees, thought leaders and analysts. Henrik Kniberg, agile and Lean coach at Crisp and part of the Scrum Alliance, said, “I wish the derogatory term ScrumBut would die. Sometimes ScrumBut is a problem, sometimes ScrumBut is a solution.”

ScrumBut refers to teams using the Scrum methodology, but also including elements of other processes with which they are comfortable. The analysts described this as part of the growth and maturation of agile adoption; it is a philosophy, not a strict process.

Thomas Murphy cited Ivar Jacobson and the Rational Unified Process as his example for how software processes evolve. “RUP evolved to talk about the philosophy, much like agile will grow and change to evolve,” he said, adding that it will begin to include other processes, some of which may be old but may be best for a given company.

Working with what you have in your company is something Melinda Ballou and West said is an important thing to remember.

If everyone waited for a perfect Scrum environment, there wouldn’t be an Agile conference,  West said, explaining that perfect doesn’t exist in the real world, and that it is important for developers, managers and business teams to understand this.

Often, in the real world of development, teams are limited by already developed (and planned) constraints. Business teams are beginning to adopt agile principles—something all analysts agree with—in order to combat these predetermined issues.

For example, if a development team is given a software project, the business team will have already decided when certain features will be released to the market (in order to beat a competitor, for instance). So, the agile ideal of allowing a team to determine what features to deliver per iteration or sprint doesn’t always apply.

However, as West said, it’s better to start building software with the methodologies and get the teams humming along than it is to wait for a perfect environment, which would be one that allows the developers to determine a timeline for feature release cycles.

The mislabeling and focus on the buzzword aspect of the process is something that bogs down teams worldwide, according to Azoff. He said it is more important to focus on delivering software, and that is what has pushed agile mainstream, even if some teams don’t realize they’re doing it because they’ve adopted the processes associated with agile and Scrum without formally adopting the titles.

Ballou said that an important part of learning what process works for developers is the conversations, much like the ones the analysts have observed at Agile 2011. Getting developers outside of their comfort zone and talking to someone they don’t talk to every day gives them a certain degree of understanding, she said.

West agreed, adding that talking to different types of developers doing different processes can help you evaluate your own work, and how your work can be changed by a different process or method.