AGILE IN ACTION

The PM Boulevard has posted 5Qs on Agile with Gerald M. Weinberg . Here are the answers to a couple of questions (the emphasis is my own): 1. Why use Agile methods?

Via Agile Advice .

I've been doing XP since 2000 and Scrum since 2004. I've never done Scrum without XP and, these days, I don't think of them separately anymore. I guess over the years they've merged into one for me and matured into my own concoction of principles and practices, still largely based on the Manifesto , enhanced by lean thinking , and extended with my own bag of tricks devised through tough commercial experience. I have to agree with Jeremy Miller, Scrum is fine but don't leave the XP practices at home . Actually, I think Scrum is great but, to be honest, I'd feel very nervous doing Scrum without the XP practices because I care about software . In many teams, doing Scrum without the XP practices would just produce crap code more effectively. If you want to do Scrum, I strongly recommend that you do the XP practices too. I do think Scrum's 30-day Sprint duration is too long. In my experience, I always saw Parkinson's Law and Student Syndrome set in during the 30 days. If you're new to iterative development , by all means start with monthly iterations but make it a top priority to achieve weekly iterations (as used in XP). If you're using weekly iterations but it's not possible to 'ship' working software to your production environment every week, try using Scrum's monthly cycle as a release cycle containing four 1-week iterations. Obviously it's preferable not to queue the output of iterations but the queue is manageable at 4 weeks worth of working software, and releasing monthly drums out a release rhythm and allows you to establish at least some incremental flow of valuable marketable features to customers. This is better than releasing sporadically based on marketing dates and having to use much larger queues while delivering zero value to customers for longer periods of time.

Short posts with deep wisdom from Jason Yip: Over-specialisation leads to over-sized teams . Over-specialisation means that there is no small team that has enough knowledge to accomplish any project. Prioritise to maintain options . Every feature implemented before its time removes an option to defer that feature to protect schedule. Customers aren't disappointed when you don't meet your commitments ; they're disappointed when it means they can't meet theirs.

The Wikipedia definition for magnetism is:

Jack Vinson recently posted 10 tips on Knowledge Management strategies . You should be thinking of these if you want to achieve lasting agility (the strikethroughs and [text] are my editions): Manage the change People before technology [and process] Behavioural change Organisational culture Strategic alignment KM [Agility] in the wild Technology is an enabler [so are tools] Adopt KM [agile and lean] principles Don't stop at the first solution [Intrinsic] motivation