tag:blogger.com,1999:blog-15466608.post8942211607697602013..comments2008-09-20T21:17:53.929+10:00Ted Hardynoreply@blogger.comBlogger6125tag:blogger.com,1999:blog-15466608.post-80464478326362648332008-09-20T21:17:00.000+10:002008-09-20T21:17:00.000+10:00Josh - that's the model.<BR/><BR/>It's very similar to what happens when systems mnagers get all their stakehodlers to come together for a monthly release planning session.<BR/><BR/>Everything gets prioritised according to importance and what fits makes the next release.<BR/><BR/>What doens't waits until the next turn.Craig Brownhttp://www.blogger.com/profile/01210437173582289473noreply@blogger.comtag:blogger.com,1999:blog-15466608.post-28800521101331529152008-09-20T21:16:00.000+10:002008-09-20T21:16:00.000+10:00Glenn,<BR/><BR/>This is a question that is perplexing me. <BR/><BR/>I have asked around on the agfile forums and no-one has yet pointed me to any proper studies that show scrum/xp etc are better than any other model.<BR/><BR/>The surveys that do show up are obviously biased and you can't really use them as a comparison.<BR/><BR/>I'll continue to sniff around until I am conviced one way or another. My current position is taht good people can leverage any process, and experience counts. <BR/><BR/>(So many iterations helps because it gives you lots of full lifecycle experience.)<BR/><BR/>At the end of the day we all agree with the principles in the agile manifiesto (ie do what's best for your customer.)<BR/><BR/>Now - to your comment on the planned-adaptive axis. You've made me re-assess it.<BR/><BR/>You, Josh, me and about 16 other people in the world all know that planned does not mean you are not adaptive.<BR/><BR/>Change control does not mean change resistance.<BR/><BR/>So, planned and adaptive are not opposites.<BR/><BR/>So my model is wrong.<BR/><BR/>It should be stubborn v adaptive.<BR/><BR/>And in that light, maybe the other axis shuld be planned and not planned. <A HREF="http://www.betterprojects.net/2008/09/adaptive-is-not-opposite-of-planned.html" REL="nofollow">Let's see what that looks like...</A>Craig Brownhttp://www.blogger.com/profile/01210437173582289473noreply@blogger.comtag:blogger.com,1999:blog-15466608.post-11867240335816885122008-09-19T23:38:00.000+10:002008-09-19T23:38:00.000+10:00I think I see what you are saying. Tell me if my related experience below is what you are getting at.<BR/><BR/>A few years back I spoke with someone who worked in an organization where the projects utilized IT and development as a service. Requirements, ROI, and all the other necessities were done in the projects, then they fed these into the technology group.<BR/><BR/>In the scenario you describe, it would be features fed into the technology group instead of sets of features in a defined project.<BR/><BR/>What are the implications for communication amongst all the stakeholders of a feature? Does the idea of a sprint go away, replaced by a feature life cycle?<BR/><BR/>Josh Nankivel<BR/><A HREF="http://pmStudent.com" REL="nofollow">pmStudent.com</A>Joshhttp://www.blogger.com/profile/06798222298277681691noreply@blogger.comtag:blogger.com,1999:blog-15466608.post-78994814295699872902008-09-19T23:29:00.000+10:002008-09-19T23:29:00.000+10:00Craig,<BR/>I agree with one axis Planned v. Adaptive. But I'd like to see the evidence - rather than ancedote - on the other. <BR/>I work in environments where change is part of the product development process. Underly architecure, seperation of concerns, coupling and cohesion all provide a platform for changing the direction of the project. <BR/>Being adaptive seems sensable - as you say. But what are the units of measure of adaptive. I can see the units for Planned, Stable and Changing.<BR/>This is the age old question.glen.allemanhttp://www.blogger.com/profile/16167384494528348151noreply@blogger.comtag:blogger.com,1999:blog-15466608.post-37772727072529800052008-09-19T23:04:00.000+10:002008-09-19T23:04:00.000+10:00Josh,<BR/><BR/>Imagine you work somewhere that has a technical landscape that is all modern and SOA type flexible.<BR/><BR/>At this point the business doens need new systems, it needs new features.<BR/><BR/>So now you have an enterprise backlog rather than a product one.<BR/><BR/>And that backlog, or work request queue will never die.<BR/><BR/>So instead of addresing work in projects, tech team simply take the next most important feature in the list and get to work.<BR/><BR/>Uncertainty, risk and so on fade right away. Reliability, cost certainty, etc are amplified.<BR/><BR/>Projects will remain, but will be less about IT and more about transforamtion in the organsiation; business models, new customer offerrings, process re-engineering and organsaitional restructures.<BR/><BR/>Try checking out <A HREF="http://www.jrothman.com/" REL="nofollow">this website</A> for more on the idea.Craig Brownhttp://www.blogger.com/profile/01210437173582289473noreply@blogger.comtag:blogger.com,1999:blog-15466608.post-88145632069670998382008-09-19T21:04:00.000+10:002008-09-19T21:04:00.000+10:00Could you expand on this statement? I'm not sure I fully understand the implications you are pointing at.<BR/><BR/>"Once you start looking at an agile approach to portfolio management the development strategy even moves away from projectised work."<BR/><BR/>Josh Nankivel<BR/><A HREF="http://pmStudent.com" REL="nofollow">pmStudent.com</A>Joshhttp://www.blogger.com/profile/06798222298277681691noreply@blogger.com