“Methods over Madness…” – Presentation to the Chicago Rational Users group October 2009 – I identified the payback of standard patterns borrowing from the OPENUP method, and demonstrated the ROI value potential of the patterns and then show how patterns can be applied to projects utilizing the Rational Method Composer tool to generate project schedules from individualized patterns for Requirements, Project Management, Governance, Development and Testing.
6. 11/03/09 The Nimblestar Group, Incorporated copyright - 2009 all rights reserved 5% to 15 % NEW Development 10% to 30% Enhancement Maintenance 20% to 35% Repair Maintenance 65% To 20% KTLO (Keep the lights on) Support %
7. 11/03/09 The Nimblestar Group, Incorporated copyright - 2009 all rights reserved NEW Enhancement Repair KTLO Requirements complexity Vision, Use Case Model, Use Cases, Declarative Requirements StoryBoard, Data Model etc… Issues, Updated Use Cases, Declarative Reqs, Glossary Issues, Declarative Reqmts. Maybe Use Case updates Issues
Source: http://www.worldwidewords.org/qa/qa-mad2.htm Few people who use the phrase today realize that there’s a story of human suffering behind it; the term derives from an early industrial occupational disease. Felt hats were once very popular in North America and Europe; an example is the top hat. The best sorts were made from beaver fur, but cheaper ones used furs such as rabbit instead. A complicated set of processes was needed to turn the fur into a finished hat. With the cheaper sorts of fur, an early step was to brush a solution of a mercury compound — usually mercurous nitrate — on to the fur to roughen the fibres and make them mat more easily, a process called carroting because it made the fur turn orange. Beaver fur had natural serrated edges that made this unnecessary, one reason why it was preferred, but the cost and scarcity of beaver meant that other furs had to be used. Whatever the source of the fur, the fibres were then shaved off the skin and turned into felt; this was later immersed in a boiling acid solution to thicken and harden it. Finishing processes included steaming the hat to shape and ironing it. In all these steps, hatters working in poorly ventilated workshops would breathe in the mercury compounds and accumulate the metal in their bodies. We now know that mercury is a cumulative poison that causes kidney and brain damage. Physical symptoms include trembling (known at the time as hatter’s shakes ), loosening of teeth, loss of co-ordination, and slurred speech; mental ones include irritability, loss of memory, depression, anxiety, and other personality changes. This was called mad hatter syndrome . It’s been a very long time since mercury was used in making hats, and now all that remains is a relic phrase that links to a nasty period in manufacturing history. But mad hatter syndrome remains as a description of the symptoms of mercury poisoning. 11/03/09 The Nimblestar Group, Incorporated - copyright 2009 all rights reserved
11/03/09 The Nimblestar Group, Incorporated - copyright 2009 all rights reserved
This varies from shop to shop 11/03/09 The Nimblestar Group, Incorporated - copyright 2009 all rights reserved
In our sample, we suggest that waterfall patterns are good for low complexity projects, with short to moderate timeframes. We also suggest that since waterfall patterns do not do a good job of mitigating risk, they are also best suited to projects with low management complexity – these are usually good indicators of low to moderate risk. Highrisk, high complexity projects are NOT good candidates for waterfall patterns. In genera, waterfall patterns do NOT address appropriate risks early enough to make it useful. High complexity, high risk projects are usually large in duration, and costly to kill.
For Scrum, you can have low to high complexity from a technology aspect assuming you address the technology risks in early sprints. However, for management complexity we recommend that you want to stay in the low complexity space – reduced management risk is a better option. There is a HIGH reliance on people who know what they are doing and can act in a leaderless situation to accomplish significant goals in a short time period.
Iterative patterns adopt more of a systems engineering approach to adoption patterns. Again there is a HIGH reliance on staff who know their jobs, but this time are directed by a fairly rigorous set of methods and measures, and by staff in leadership roles like PMs, tech leads and Architects.