Need a checklist to decide if that new project should be done using Agile ?
So far the Scrum Agilitists that I've met seem to be a very pragmatic bunch, a bit like myself. They realise that Scrum isn't a silver bullet, quick fix or guarantee of sucess for every project. As part of the CSM course that I recently took, we covered when to choose Scrum and importantly when not to.
Scrum makes reference to the Cynefin Framework (developed by Dave Snowdon, the KM guru and pioneer in the application of complex adaptive theory) around leadership decision making and complexity.
You see, Scrum work best for complex projects where the scope is not well understood or agreed and the technology is far from certain - two huge areas for contention in traditional waterfall approaches. For the complex domains, 'probe, sense and respond' is prescribed by the Cynefin Framework which matches the 'apply, inspect and adapt', that Scrum uses.
So far the Scrum Agilitists that I've met seem to be a very pragmatic bunch, a bit like myself. They realise that Scrum isn't a silver bullet, quick fix or guarantee of sucess for every project. As part of the CSM course that I recently took, we covered when to choose Scrum and importantly when not to.
Scrum makes reference to the Cynefin Framework (developed by Dave Snowdon, the KM guru and pioneer in the application of complex adaptive theory) around leadership decision making and complexity.
You see, Scrum work best for complex projects where the scope is not well understood or agreed and the technology is far from certain - two huge areas for contention in traditional waterfall approaches. For the complex domains, 'probe, sense and respond' is prescribed by the Cynefin Framework which matches the 'apply, inspect and adapt', that Scrum uses.
Even then, if you have worked out that you have a set of suitable project, which ones are likely to have a successful outcome and are ripe to use Agile techniques. Kane Mar, a well known Scrum Trainer and Coach, has published a simple score card to get started. Agile Project Selection from a portfolio of projects, it might help to identify which projects are good candidates. Although, he notes that as you become more experienced you'll be able to identify which projects to choose without a scorecard.
Here is a bit more about the scorecard.
The Scorecard is simply a list of criteria that can be uses to assess the characteristics of a particular project. A numeric value is associated with each question, so that scores can be simply tallied up based on the total value and then used to determine if the project is suitable for “the Agile treatment.”
Lets also consider some stats.
EMA research conducted in mid-2008 determined that 80% of companies surveyed had custom software in production, a higher percentage than Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), or any other application type.
They also determined that over 60% of the time, software development projects fell short of expectations which means that only 40% of budget dollars invested in software development yield business value and therefore the conclusion is that reversing this trend can yield very rapid ROI.
The CSM course cites the Standish CHAOS Reports to determine that 64% (I'm not sure the date of which report) of features are seldom or never used and therefore the case for deciding on features based on value.
So if the EMA and Standish data is right (some may disagree) then adopting a software development methodology that reduces waste and has an emphasis on value is going to be a wise choice in the current environment.
So it's hardly surprising then, given the numbers, that you will be hearing more about Agile (and Scrum) as this rapidly becomes the standard approach for complex projects - which includes software development.
Hey Tony,
ReplyDeleteGreat information....
I am beginning the think SCRUM can also be applied to simpler projects in cases where the customer is somewhat flexible about what changes/enhancements are included as part of a given release. A non-trivial part of software development costs seems to come from the effort consumed constantly changing project plans each and every time a single project slips. Because SCRUM works on the principal of fixed goalposts it is much easier to plan across multiple projects if there is a lesser chance that any one project will slip. e.g. a project meeting to review requirements with the customer can be set for every 4th Monday if we are doing Sprint cycles in 4-weekly blocks. The meeting will probably be in the same meeting room because it is booked well in advance. Budgeting is much easier because we pretty much know exactly how much development time will be consumed on a Sprint. Resources can be allocated between projects based upon Sprint cycles making demand management a lot easier. The only thing that needs vary is exactly how much content gets delivered with each sprint cycle.
You give me that flexibility and I can reduce your overall software development costs by reducing overheads.
Peter,
ReplyDeleteYes, simple projects where the requirements (changes/enhancements) are not understood or agreed would benefit from the Scrum treatment. There is a lot of cost savings from delaying the decomposition of the project goals until you are committed to the features you are about to build. In Scrum the constraints are cost (# developers) and Schedule (Sprint Length) which are fixed and estimates are on the scope which can change. In traditional projects scope is the constraint, the least flexible or which costs more to change (and hence less flexible). Estimates are in cost and schedule based on previous projects. The scope shouldn't be fixed (or bound by change processes that cause scope change to be see as something bad). It should be something that can be changed to accommodate changing requirements, better knowledge or changing objectives. Even the content of what gets into a sprint (in theory) should get better and more consistent as the team gets more accurate in predicting their velocity based on actual historical throughput - rather than a guess.