Home
Scrum, Waterfall, Lean, Prince2: what do they all have in common?
One perspective is that they are individual software methodologies, offering different approaches on how to build software.
However, here, we are going to consider a second perspective: that building software is all about managing risk, and that these methodologies are acknowledgements of this fact, and they differ because they have different ideas about which are the most important risks to manage.
Hopefully, after reading through some of the articles here, you'll come away with:
- An appreciation of how risk underpins everything we do as developers, whether we want it to or not.
- A framework for evaluating software methodologies and choosing the right one for the task-at-hand.
- A recontextualization of the software process as being an exercise in mitigating different kinds of risk.
- The tools to help you decide when a methodology is letting you down, and the vocabulary to argue for when it's a good idea to deviate from it.
This is not intended to be a rigorously scientific work: I don't believe it's possible to objectively analyze a field like software development in any meaningful, statistically significant way. (For one, things just change too fast.)
Neither is this site isn't going to be an exhaustive guide of every possible software development practice and methodology. That would just be too long and tedious.
Neither is this really a practitioner's guide to using any particular methodology: If you've come here to learn the best way to do Retrospectives, then you're in the wrong place. There are plenty of places you can find that information already. Where possible, this site will link to or reference concepts on Wikipedia or the wider internet for further reading on each subject.
Lastly, although this is a Wiki, it's not meant to be an open-ended discussion of software techniques like Ward's Wiki. In order to be concise and useful, discussions need to be carried out by Opening an Issue.
If you feel something important is missing, or you spot a mistake, we need help.
You can get a flavour for where all this is going by reaading this: Executive Summary
There are basically five parts to this work:
- Parts 1 and 2 really need to be read in sequentially, as they'll explain the concepts you need to digest the rest.
- Parts 3, 4 and 5 don't have a linear structure, you can dive in anywhere after reading the first two.
Some easy-to-digest ideas that will set the scene for examining the practices later.
- A Simple Scenario
- Development Process
- It's All Risk Management
- A Software Project Scenario
- Some Risk Theory
- Meeting Reality
- Cadence
- A Conversation
Part 2: The Risk Landscape
Risks are often very similar across different software projects. And, if you know about them, you can look for them. This section attempts to break them down for you:
- The Risk landscape
- Feature Risk
- Complexity Risk
- Communication Risk
- Dependency Risk
- Schedule Risk
- Software Dependency Risk
- Process Risk
- Boundary Risk
- Agency Risk
- Coordination Risk
- Map And Territory Risk
- Operational Risk
- Staging And Classifying
Part 3: Practices
This part is a discussion of the different practices within Software Development, and how they mitigate and accentuate the different risks.
- Practices
- Analysis
- Coding
- Contract
- Delivery
- Design
- Documentation
- On-Site-Customer
- Prioritisation
- Requirements Capture
- Review
- Standards
- Support
- Terms-Of-Reference
- Testing
- Training
Part 4: Methodologies
A more in-depth look at software methodologies and how their chosen practices reflect their position on what the most critical risks are.
- Introduction
- Waterfall
- Extreme Programming
- Scrum
- Lean
- PMBoK and Prince2
- Programming, Motherf
- DevOps
- 12 Factor
A more light-hearted collection of blog posts related to the software development process, aiming to use what we've learnt in real-life contexts.
- Case Study
- Regression Testing
- Minimizing The Downside
- Issue Tracking
- Surfacing Risks
- Silver Bullets
