Listening to conversations between designers and developers is an endless source of amusement. Contributors and visionaries from both camps will always have expectations and frame questions from the view of their own professional specialty.

It gets even better, when a programmer and a designer discuss working Agile methodologies, and gets even better when they have varying appreciations of what exactly agility is.

Designers love to have an open canvas to paint on. They hate to define requirements if it’s going to constrain their designs in any way. They seek agility so they can say “well, we’ll through some stuff up now, and refactor it later.”

Programmers of course see the aspects like “stories are agreements between business and production” ideal places to get formal definition of what they should spend their time on. They do need that… we all need that. Spending your time on low value things isn’t pleasant for anyone, and one of the big contributors to dissatisfaction.

Business folks tend to think of agility as the ability to add and change requirements whenever they want with little to no impact on dates, quality or resource commitment… the eternal “pick any two” triangle. Nothing’s changed.

Of course, there’s a balance to this. Those who have balanced agility with structure have done so after hard knocks in dealing with the different perspectives of business, design and business. One of the inevitable benefits of Agile Methods is getting these all too often separated groups talking together, sharing goals and speaking in English together earlier in the process, before it comes to blows at QA time!