« Outlook New Mail Responder | Main | Reforming Project Management »
October 24, 2002
Agile Manifesto
I forgot this existed, but was recently reminded of the Manifesto for Agile Software Development. These concepts are excellent and I have used them on projects (admittedly in a more accidental way, rather than as a planned approach. But seeing these principles in black and white is refreshing. There is a book about Agile Software Development, which I own and have read at least part of. It's very interesting and asks some important questions right off the bat. The answers are important to the understanding of the way communication and knowledge play an important role in understanding the domain for which software is developed, understanding the problems to be solved, conveying the proposed solution, etc. All of these are recurring problems on all software development projects and everyone has their own methods for dealing with these issues (some better than others).
I will share a couple of things that I like to do:
1. Ask questions that box-in the knowledge I am seeking. This involves learning something of a requirement and then testing the variations of that fact (including the antithesis) to determine that you truly understand that fact. For instance:
A vendor can have one contract for every commodity, region and market type.
You might now want to ask, "If a vendor delivered two different commodities to the same region and for the same market, must both deliveries be covered under the same contract? Can there ever be a situation where those two deliveries are governed by two different contracts?" This is just an example, and you can see that there are two problems with it:
a) It's exhausting
b) You sometimes look like a dumbass asking all of these idiotic questions. So be sure to prepare your team for this type of discovery.
2. UI It is very important to show users a navigable prototype. I can't count how many times a signed off use case or requirements document has the UI walkthrough and the number of changes is in the double digits. Users just can't get a good feel for what the proposed solution is unless they have (at least) a view of how they use the system (UI) accompanied by the business rules, restrictions and behind the scenes processing that happens while they are using the UI (use cases, process definitions, etc.). You should probably also share other artifacts with them during this walkthrough, but do at least these two.
3. Attempt to discover missed requirements early and often. Everyone wants to prevent changes from occurring once they get sign-off and development begins. The problem with that is that change management is not the practice of preventing change. Some change is good. I remember a story about the introduction of the minivan with dual sliding doors. I don't remember who introduced that first, but the other major companies had to halt production and add that feature. It was a worthwhile change for them, lest the be killed in the marketplace. So attempt to seek out changes (missed requirements, desired enhancements, etc.) with the notion that they will surface and you are in the best position if you learn about them early and have a structured change management process (which is really about communication, authority, and trust) to handle these issues. You will end-up with a much better solution.
Posted by Chris at October 24, 2002 09:44 AM
Trackback Pings
TrackBack URL for this entry:
http://www.christulino.com/cgi-bin/mt/mt-tb.cgi/25
Listed below are links to weblogs that reference Agile Manifesto:
» Outsourcing (Rebellion within Corporate America) from Thinking Out Loud: Thought Leadership from an Enterprise Architect
To many enterprise architects allow their bosses to let American IT jobs to be destroyed by sending them offshore to places such as India. Maybe they should focus on what works in practice, not on paper...... [Read More]
Tracked on March 11, 2005 03:12 PM