tag:blogger.com,1999:blog-6081361780079434787.post2424191002393603622..comments2018-03-19T23:50:31.686+01:00Comments on Business or Pleasure? - why not both: No Agile Gospel please, just give me EnlightenmentMartijn Linssenhttp://www.blogger.com/profile/00573419401627232560noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-6081361780079434787.post-70155234727477047462011-01-29T00:06:39.364+01:002011-01-29T00:06:39.364+01:00Aha... So I get where you are coming from... This ...Aha... So I get where you are coming from... This is how I set up my teams<br /><br />I have testers as part of a 6 person scrum team, normally to a ratio of 3 devs, 2 testers and a scrum master... However I also then have a separate system/integration test team that don't work as an agile team... I've found this to produce great results for larger complex products<br /><br />As for maintenance I don't use agile for that either.. I have a separate sustained engineering team that are dedicated to respond to any field issues quickly and efficiently.<br /><br />So as you can see I do see agile as being a good thing, but it's not for everything... and on that point I think we agree.Stuart Lynnhttp://www.stuartlynn.co.uknoreply@blogger.comtag:blogger.com,1999:blog-6081361780079434787.post-53301508171543497712011-01-28T23:46:57.519+01:002011-01-28T23:46:57.519+01:00Thank you very much Stuart
I think I do get it. M...Thank you very much Stuart<br /><br />I think I do get it. My beef with Agile is that it delivers projects, not products. Narrowing that down, I think Agile only delivers software builds - it is a very narrow-minded approach to the entire Application Life Cycle<br /><br />we don't need to deliver projects in IT, we need to deliver perfect products: well described software that are traceable back to the business needs, ergo having a fully described functional requirement, same as technical design. From those documents, the testers can distill their test cases, and of course the product is fully prepared for transition into the operation and maintenance phase<br /><br />You name project, dev, but not test, nor maintenance. Let me tell you something: I have been asking all Agile lovers whether they have experience with testing and / or maintaining products delivered through Agile projects, and the silence has been deafening<br /><br />With regards to that, can you help me out? I don't care for projects, I care for productsMartijn Linssenhttps://www.blogger.com/profile/00573419401627232560noreply@blogger.comtag:blogger.com,1999:blog-6081361780079434787.post-26040796467885857812011-01-28T23:28:41.365+01:002011-01-28T23:28:41.365+01:00Hi Martijn,
I'm not sure from reading this th...Hi Martijn,<br /><br />I'm not sure from reading this that you actually get agile.. Whilst I agree its not for everything it can be a highly effective way to deliver software (and even commercial business) projects.<br /><br />What it isn't is throw all control in the bin and fly by the seat of your pants... What it is is a model whereby accountability lies with the dev team and not some project manager miles away from reality of day to day decision making.<br /><br />The controls are very adequate and persoanally I've used it on dev teams of 80 or so people.. Based around scrum of scrum hierarchy ... However, that said I also like a high level governance in place for really complex implementations.<br /><br />This overview is really good, and just about says all you need to say.<br />http://agile.dzone.com/news/scrum-under-10-minutesStuart.Lynnhttp://www.stuartlynn.co.uknoreply@blogger.comtag:blogger.com,1999:blog-6081361780079434787.post-47722190544557223772010-06-28T20:20:21.568+02:002010-06-28T20:20:21.568+02:00Great Lee! and thank you very much for your length...Great Lee! and thank you very much for your lengthy and interesting comment.<br /><br />I absolutely agree with you on the situational approach for Agile. Here's what is called the Agile home ground:<br /><br /> * Low criticality<br /> * Senior developers<br /> * Requirements change often<br /> * Small number of developers<br /> * Culture that thrives on chaos<br /><br />and I would certainly agree with that. Heck that's how I start my own pet projects<br /><br />I love the way you guys fusion the post-merger project(s). That's natural, almost like languages converge along state and country borders<br /><br />I agree with the reasons for failure and the false expectations, but from other points of view there is what I call the monocultural aspect. Let me elaborate: I studied Languages and Cultures of Latin-America (http://www.martijnlinssen.com/p/my-drive.html) and learned among others The Law of Monoculture. Cuba with its sugar, Central America and Brazil with coffee, dating back long ago. Today, Costa Rica is the top global producer of pineapples, Brazil is the main producer for ethanol<br /><br />Of course everybody in those countries tried to run along as much as they could, even when the monoculture proved to be failing due to bad crops, harvest or sinking prices<br /><br />Evangelisation does that. This is not as much a post "against" Agile as it is against evangelisation in general, beit IT or non-IT. The world is diverse, the world changes. We get wiser, because we fail. We gain insights, that lead to change. That change leads to new ideas<br /><br />Or it doesn't, and you'll keep paroting 2,000 year old ideas ;-)Martijn Linssenhttps://www.blogger.com/profile/00573419401627232560noreply@blogger.comtag:blogger.com,1999:blog-6081361780079434787.post-56926866355922572812010-06-28T18:37:17.717+02:002010-06-28T18:37:17.717+02:00Hi Martijn. Good observations and in general I agr...Hi Martijn. Good observations and in general I agree with them. Why? Because I've seen too many times that people / companies see agile as the holy grail that will solve all their problems and "agile-ify" everything. Wrong.<br /><br />Agile can be extremely useful in certain domains and scenarios. It's definitely not something you will apply to everything.<br /><br />Based on the talk I gave on the SAP conference and that Dennis Howlett recorded, I argue that agile fits quite nicely in the interaction part when you are making the distinction between interaction and transaction. I do believe that agile isn't necessarily the best fit when you are planning and implementing a strategy around an ESB that links several legacy systems together. <br /><br />I do believe that it fits very nicely in developing people facing and interaction focused web applications. Also in combination with a platform that fits naturally (like Ruby on Rails) and a mindset that follows with it (bit more the startup-like team approach with product owners and quick iterations). <br /><br />This does also fit nicely in a wider larger program. Currently executing this for a post-merger IT integration where we have several agile development teams working on several client portals with their product owners, whilst it fits in a more tradtional program management and works together with a more waterfal type backend systems workstream.<br /><br />It does require a certain design authority that guards the design and architecture principles and can coordinate work and dependencies between the different teams. <br /><br />The reason why it fails so often is the lack of culture and understanding. Being a product owner requires delegated authority (which is often not there) and dedicated time for the product owner role (often they do it next to their full time day job). Clients usually like the advantages of agile, but don't want to accept the insecurity that comes with agile because you are not committing to a set of features, only to a set of sprints.<br /><br />I've had several interesting discussions with people that basically ask us to specify up to sprint 25 the deliverables, well that just doesnt work obviously. <br /><br />Also we need to be honest here. In the situation where clients come with vague requirements to us and don't know themselves what they exactly want. These type of clients often tend to ask for a fixed price / fixed time project. It just doesn't make sense to engage in such way. Agile fits the bill better.Lee Provoosthttps://www.blogger.com/profile/00140718646644263342noreply@blogger.com