2008/2/13, W Evans <[EMAIL PROTECTED]>: > Manifestos are beautiful - and I can't argue with these - but it's the > practice and process of any methodology carried out by real people that is > all that matters.
What that manifesto really means in practice: *1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. * Customer satisfaction is definitely the aim of anything, no arguments against it. Nevertheless, of all the things that could be chosen as satisfaction factors how come this one in specific became the glorified foundation of Agile development? Did we give up educating customers of the value of planning, researching and prototyping and are trying to make our lives easier by just conceding to the fact that many projects are built on reaction and firefighting? *2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. * - Thank God for all those hard-working Indians and Pakistanis working 18 hours a day to satisfy every unplanned turn of direction for two pennies an hour. *3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.* - Again, thank God for the Indians and good riddance we are not manufacturing cars, although the level of complexity can be the same some times. *4. Business people and developers must work together daily throughout the project. * - This is a good and logical principle although it transpires that Agile is still a glove too small for graphical designers and front-end developers. *5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. * - Does that include signing off hardware upgrades and software necessary to get the job done straight away, or just tell developers and designers to use a demo version until it expires whilst the accountancy team goes through the process of signing off the expenses? Does motivation mean a willingness to deliver the best of your potential or just accumulate unpaid overtime? *6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. * - That is great when you are developing a Contact Us form or everyone is in the same cosy room and the workload is distributed fairly and evenly amongst the members of the team. What I have seen is that this kind of environment generates a good amount of lack of ownership and misunderstanding. Information doesn't get transferred evenly in all corners of the organisation and one spends most of the time repeating the same thing to every person they meet. Kudos if you work on the go or in an office in some unknown dark corner of the room adn your face can only be seen every 10 days. What is with Agile companies asking you to use your own mobile phone to take and make calls? *7. Working software is the primary measure of progress.* - Definitely, it doesn't matter that in the inital phase of your project, half of your team already left the company whilst the overall turnover is as high as the rate the planet's natural resources are being depleted. Once again, thank God for India for providing all those young graduates every year. *8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.* - This is cute, but what does it mean? *9. Continuous attention to technical excellence and good design enhances agility.* - What??? Dude, first of all, thanks for restricting the excellence bit to the *technical* realm, I am also taking it that we are talking about *technical* design, but unfortunately I know one too many graphical designers, usability engineers, front-end developers that wish their excellence also shone amidst this technical paradise Agile seems to be (and by the way stop telling the HTMLer that he can repurpose or refactor his CSS as quickly as the overworked Java remunerated slaves, coz' Java is platform independent whereas CSS and HTML are still not). Secondly, in the real world this doesn't happen, mostly when we overworking them to death, if you don't believe me then produce your benchmark showing how much more usable, fast, accessible, standardised applications built with Agile are. *10. Simplicity--the art of maximizing the amount of work not done--is essential.* - Yeah, ok, it is a millennium old Zen principle. Knowing how hard developing with Agile is, believe me, maximizing the amount of work not done goes down very well. *11. The best architectures, requirements, and designs emerge from self-organizing teams.* - If you manage to have the whole Apple engineering team or similar, yes definitely. Nevertheless, this used to be called "virtual teams" and it was out there even at the age of waterfall development. *12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.* - Unless it is something that is outside the scope, in this case if the darned thing works that will do. Most of the time, the team reflects how their lives have become a sleep-deprived journey, wondering how their kids are and how to make the current project look good in a CV. Sometimes they will reflect on why the IA is delaying them with those wireframes and user c**p. Luis ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
