|Risk-First Software Development: The Menagerie|
Author: Rob Moffat
This first volume of the Risk-First series, looks at managing software projects under an alternative perspective.
This book draws on the author's long lasting experience with software projects and is based on empirical rather than scientific evidence;
"Is it scientific? No. Is it correct? Almost certainly".
During his career, Rob Moffat came to the conclusion that things don’t match up with the way the books say they should be done. This view was formed when he observed that:
The alternative approach that this book adopts is that the core of building software is all about managing risk and while tools and methodologies help minimize the risk of the project failing, they differ in that they have different ideas about which are the most important risks to manage.
So Risk-First suggests that we should not be fixated on a certain methodology, but rather use the most appropriate for the task at hand. “Agile”,“Waterfall”, “Lean” or “Phased Delivery” all prescribe different approaches to running a project and are opinionated about the way they think projects should be done.Therefore Risk-First deciphers the most common methodologies and the risks they are more appropriate to deal with. It also builds a common risk-oriented language for the manager and developers to communicate in.
All that sounds very interesting but not yet clear.Fortunately not much later on we are given an example of what kind of risks and tools we are talking about:
Tools aside, there's also Methodologies which cater for different Risk profiles:
Having cleared this up, with Risk-First we can:
Already a lot to talk about and this was just the intro...
Chapter 1 then defines what constitutes Risk and introduces the Risk-First methodology's terminology by going through the metaphor of planning dinner for some friends. The terms explored include:
The chapter continues by breaking away from the metaphor and applying those concepts to software projects.
Chapter 2 is about minimizing Risks. I relay the book's text as is because it makes the concept very clear:
1. We have a business analyst who talks to users and fleshes out the details of the feature properly. This is to minimize the risk of building the wrong thing.
2. We write unit tests to minimize the risk that our code isn’t doing what we expected, and that it matches the specifications.
3. We integrate our code to minimize the risk that it’s inconsistent with the other, existing code on the project.
4. We have acceptance testing and quality gates generally to minimize the risk of breaking production, somehow
5.User Acceptance Testing (UAT) is where our new feature meets another reality: actual users.
Chapter 3 is on the actual Reality vs our Internal Model of reality and how they interact with each other:
we take action based on our Internal Model, hoping to change Reality with some positive outcome
which, of course, comes with associated costs. Obviously, these costs of meeting Reality are correlated to the Payoff expected as in:
"do the work if there is a worthwhile Payoff":
So, it’s a trade-off: continue adding logging statements so long as you feel that overall, the activity pays off reducing overall risk.
I don't think that what's been covered so far is unbeknown to project managers; it's just common sense diffused by experience. What the book tries to do is to formally describe and codify that experience.
Chapter4 is a reminder that everything you do on a software project is mere risk management:
and closes up with defining what constitutes "Failure".
Chapter 5 is on evaluating Risk, the Probability of it actually happening and its Impact having happened.In order to formally flush risks we use a tool called the "risk matrix" which presents a graphical view of where risks exists. We see an it applied to the Dinner party example.
The rest of the chapter suggests that you can't measure Risk scientifically, that is with numeric precision, but instead:
"You should, with experience, be able to hold up two separate risks and answer the question, is this one bigger than this
Chapter 6 is about Feedback Loops.In order to manage risk effectively we should aim for as many as possible. For example, Unit Tests have a faster feedback loop so we aim for more Unit Test,.
So what do we do? Do we Mitigate,Avoid,Transfer,Ignore, Accept, Contain or Exploit risk? Chapter 7's single page re-cap does a really good job of conveying the message of what we've read thus far.
Chapter 8, A Risk Conversation, is a real world example of two developers working on the same project who have a conversation in order to identify emerging risks in the project and Chapter 9 is an overview of the most common project methodologies and the ways they differ.The caveat is that although Methodologies are good in surfacing hidden risks, the act of adopting one means that you are trusting something other than your own judgment to make decisions.That itself introduces new risks in that the methodology opted for might not be the most appropriate for the task at hand.As such it could include activities which waste time or money, hence it is important to look into each methodology's suitability.
This marks the end of the first part of the book which introduced the notion of risk and the methodologies that deal with it.
Part II deals with categorizing risk by dedicating the rest of the chapters in uncovering those risk categories:
as well as:
The book concludes by presenting a chapter, "Estimating", from the next and upcoming title in the series, which is about how to succeed in managing a software project.
All in all, this is an original title that looks into managing software projects under a novel perspective, that of managing risk, which despite being underrated and having a tendency to be ignored, lies at the very core of any such project.
As a member of teams building software I have to say that reading it has certainly widened my horizons, made me more aware of hidden risks and ways of uncovering them, but ultimately taught me that being fixated on a certain methodology is not the way to go. The motto "use the right tool for the right job" applies here too.
Saying that, Menagerie painted half the picture so I'm looking forward to the next part in the series in order to absorb Risk-First's full wisdom on the business of managing software projects.
|Last Updated ( Monday, 04 March 2019 )|