Author: Rob Moffat
Publisher: CreateSpace
Pages: 248
ISBN: 978-1717491855
Print: 1717491855
Kindle: B07MK9LTHN
Audience: Those working on software projects at intermediate level
Rating: 4
Reviewer: Nikos Vaggalis

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: 

• Development Teams put a lot of faith in methodology. Sometimes, this faith is often so strong it borders on religion. For some, this is Prince2. For others, it might be Lean or Agile.
• Developers put a lot of faith in particular tools too. Some developers are pro-or-anti-Java, others are pro-or-anti-XML. All of them have their views colored by their experiences (or lack of) with these tools.

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: 

• If we do a Code Review, we are partly trying to minimise the risks of bugs slipping through into production, and also manage the Key Person Risk of knowledge not being widely-enough shared.
• If we write Unit Tests, we’re addressing the risk of bugs going to production, but we’re also mitigating the risk of regression, and future changes breaking our existing functionality.
• If we enter into a contract with a supplier, we are mitigating the risk of the supplier vanishing and leaving us exposed. With the contract in place, we have legal recourse against this risk. 

Tools aside, there's also Methodologies which cater for different Risk profiles: 

• Agile methodologies prioritize the risk that requirements capture is complicated, error-prone and that requirements change easily.
• Waterfall takes the view that development effort is an expensive risk, and that we should build plans up-front to avoid re-work.
• Lean takes the view that risk lies in incomplete work and wasted work, and aims to minimise that. 

Having cleared this up, with Risk-First we can:  

• Talk about the types of risks we face on our projects, using an appropriate language.
•  Anticipate Hidden Risks that we hadn’t considered before.
•  Weigh the risks against each other, and decide which order to tackle them.  

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:

• Internal Model of the world
• Reality
• Attendant Risks
• Hidden Risks
• Taking Action

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": 

• Logging statements are good, because otherwise, you’re increasing the risk that in production, no one will be able to understand how the software went wrong.
• However, adding them takes time, which might introduce Schedule Risk. 

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: 

• Every Action Attempts to Mitigate Risk 
• Every Action Has Attendant Risk 
• Every Decision is About Payoff 

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
one?”

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:

• Feature Risk, i.e when you haven’t built features the market
  needs, or the features you have built contain bugs, or the market changes underneath you
•  Communication Risk, risk that is associated with getting messages heard and understood.

as well as:

• Complexity Risk
• Dependency Risk
• Scarcity Risk
• Deadline Risk
• Software Dependency Risk
• Process Risk
• Boundary Risk
• Agency Risk
• Coordination Risk
• Map And Territory Risk
• Operational Risk

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.

For more recommended titles on methodology, see Reading Your Way To Agile on Programmer's Bookshelf.