Discussion on: It’s Not Easy to be Agile http://itknowledgeexchange.techtarget.com/customapps/its-not-easy-to-be-agile/ Fri, 05 Sep 2008 17:25:27 +0000 http://wordpress.org/?v=wordpress-mu-1.2.1 By: LadyRatri http://itknowledgeexchange.techtarget.com/customapps/its-not-easy-to-be-agile/#comment-13 LadyRatri Thu, 04 Oct 2007 17:48:14 +0000 http://itknowledgeexchange.techtarget.com/customapps/its-not-easy-to-be-agile/#comment-13 I've been working on long-term "Agile" projects for almost a year. I agree that the choice of tools has a large influence on ability to deliver working software quickly. Other overwhelming factors in my experience have been one-man bottlenecks on a team. Every project has required skillsets to get a functional requirement through design, development, testing and released to an audience of users. When my teams have had problems delivering, it's often due to a required skillset posessed by only one member of the team. Most often, this came down to UI design or technical QA tasks. Part of the team being "Agile" is each member being agile -- lower case 'a'. The ideal seems to require a whole team of jack-of-all-trade tech superstars. To speak to your remarks about the "latest and greatest" technologies -- I think this is more an issue of convincing the business, or whoever "owns" your agile project, that small amounts of research budgeted in throughout a project can bring significant rewards in terms of getting these newer technologies involved when and where they are needed. Then, rather than working outside of your planned tasks, this research into new technologies becomes another task that someone does during each development cycle of the project. My current project has delivered working new functionality every 3 weeks since mid July. And you're right -- It most definately hasn't been easy. After each release, we've discussed improvements to our process and our planning to make these iterations go more smoothly. But, we have a working product out to the public and are providing a constant stream of small improvements and new functionality, as well as maintaining the ability to respond to the suggestions and feedback of our users. I’ve been working on long-term “Agile” projects for almost a year. I agree that the choice of tools has a large influence on ability to deliver working software quickly. Other overwhelming factors in my experience have been one-man bottlenecks on a team. Every project has required skillsets to get a functional requirement through design, development, testing and released to an audience of users. When my teams have had problems delivering, it’s often due to a required skillset posessed by only one member of the team. Most often, this came down to UI design or technical QA tasks. Part of the team being “Agile” is each member being agile — lower case ‘a’. The ideal seems to require a whole team of jack-of-all-trade tech superstars.

To speak to your remarks about the “latest and greatest” technologies — I think this is more an issue of convincing the business, or whoever “owns” your agile project, that small amounts of research budgeted in throughout a project can bring significant rewards in terms of getting these newer technologies involved when and where they are needed. Then, rather than working outside of your planned tasks, this research into new technologies becomes another task that someone does during each development cycle of the project.

My current project has delivered working new functionality every 3 weeks since mid July. And you’re right — It most definately hasn’t been easy. After each release, we’ve discussed improvements to our process and our planning to make these iterations go more smoothly. But, we have a working product out to the public and are providing a constant stream of small improvements and new functionality, as well as maintaining the ability to respond to the suggestions and feedback of our users.

]]>