http://gorillajawn.com/wordpress/2008/04/27/agile-within-a-complex-domain/ Enterprise Software Consultant Mon, 15 Mar 2010 20:02:48 +0000 http://wordpress.org/?v=2.9.1 hourly 1 http://gorillajawn.com/wordpress/2008/04/27/agile-within-a-complex-domain/comment-page-1/#comment-14628 Patrick Logan Mon, 28 Apr 2008 14:23:47 +0000 http://ectropic.com/wordpress/?p=31#comment-14628 "Agile" does not assume either (1) or (2). Being agile is a way to do a small thing, get feedback, and adjust. Therefore it seems perfectly suited to your situation. Everyone gets to learn a little about the domain, a little about the older system, and a little about the new solution, and then iterate on a little more. "Agile" is not a "methodology" - rather it is a way to continuously improve. When a domain specialist is thinking in terms of a full report then it is challenging to help them think in terms of small pieces. It does take practice and some cooperation on their part. But I've yet to come across a domain where this is not possible, even when everything seems monolithic at the outset. Calculations in and of themselves have "business value" - there's nothing about "agile" that says all business value is visual - actually agile approaches emphasize the opposite. Competent people - yes, I absolutely agree this is the key more than anything else, but I fear you are looking at "agile" as a set of required steps (a "methodology") rather than as a philosophy of working small and communicating effectively. This is a typical problem in the software world today - and a big impediment from becoming a continuously improving organization. “Agile” does not assume either (1) or (2). Being agile is a way to do a small thing, get feedback, and adjust. Therefore it seems perfectly suited to your situation. Everyone gets to learn a little about the domain, a little about the older system, and a little about the new solution, and then iterate on a little more. “Agile” is not a “methodology” – rather it is a way to continuously improve. When a domain specialist is thinking in terms of a full report then it is challenging to help them think in terms of small pieces. It does take practice and some cooperation on their part. But I’ve yet to come across a domain where this is not possible, even when everything seems monolithic at the outset. Calculations in and of themselves have “business value” – there’s nothing about “agile” that says all business value is visual – actually agile approaches emphasize the opposite. Competent people – yes, I absolutely agree this is the key more than anything else, but I fear you are looking at “agile” as a set of required steps (a “methodology”) rather than as a philosophy of working small and communicating effectively. This is a typical problem in the software world today – and a big impediment from becoming a continuously improving organization.

]]>