Distributed Thinking

Development Services have a new blog.  We are using this as a place for members of the section to share information, experience and thoughts relating to our work.  Anyone in the section can contribute posts.  We expect most of the posts to cover technical material, such as useful coding techniques, experience from particular projects, and so forth. See http://www.appsdev.is.ed.ac.uk/blog/ .

Following from my previous post , this is my response to a second thought-provoking article that criticises a codification of agile software development into rigid project management frameworks.  In that article, Mike Hadlow asks why agile has come to mean just management practices (stand-ups, retrospectives, two-week iterations and planning poker), divorced from any base in technical practices.  He bemoans projects in which non-technical people are given the role of Scrum Master, enforcing agile rituals without understanding what the team are actually doing. I can see that Mike's scenario would be problematic.  I have seen examples in our organisation where some non-development staff may have thought they could control an agile team (e.g. as a business analyst) but the structure of the agile team has (correctly) worked against them.  In general, it is certainly easier to explain daily stand-up meetings and two-week iterations to non-technical people than it is to...

In the last week I've seen a couple of blog posts that bemoan a codification of agile software development into rigid project management frameworks.  Both are interesting and caused me to reflect on our own adoption of agile - because to a fair extent we are doing exactly what these posts criticise. The first such post is titled The Dark Side of Scrum .   Thomas Scranz asks why, if the first principle of the agile manifesto is that we value individuals and interactions over processes and tools, have people adopted Scrum as a dogmatic codified interpretation of agile?  I will note my thoughts in this post. (I hould clarify that we're not following Scrum per se; our process started nearer XP and has adopted some notions from Scrum and DSDM along the way). Thomas first argues that with continuous integration and automated testing tools, we can move beyond fixed two-week time boxes to a faster and more flexible delivery cycle .  Well, that may be true for an organisa...