As almost all posts on this blog, this was a true cooperation between Chris and me. So, the credits go as much to him as to me.

[ And thanks for noting my blog post "Agile Requirements: Not an Oxymoron" at http://ebgconsulting.com/blog/agile-requirements-not-an-oxymoron/ and also referencing my first book, Requirements by Collaboration (http://ebgconsulting.com/Pubs/reqtcoll.php ]

Chris: i appreciate you pointing out the agile business analysis, while an evolving practice, rests on good analysis and blends a)domain knowledge b) technology knowledge and c) business analysis skills.

i really like the term “Business Coach” (and that alternative role name has been picked up in the draft Intro section to the IIBA BABOK agile extension) — so thanks!

For your readers interested in more: going to http://agileba.pbworks.com/ and joining in on conversations on the yahoo group you moderate could be of interest.

Also, agile analysts interested in helping with our efforts to build agile extension to the IIBA BABOK: please consider contacting Dave Morris (our “scrum master” for the effort) via “david.morris AT theiiba DOT org — we can use more volunteers!

with warm regards,
~ ellen

P.S. oh, it’s spelled Gottesdiener (a mouthful, to be sure!)

I am of the thought that Agile is about building software that comprises or is part of a solution. It is very possible, doubters aside, to define clear, correct and complete requirements in a short time frame, before even deciding if you are building a solution, and that Agile is the approach you might use to do that.

So,we don’t need to worry about this issue…sorry.