Now Or Later: You Must Decide How To Manage Software Project Risk

Monday, 25 July 2011 15:16 Written by AdventureTech 3 Comments

Post written by Troy Tuttle, Project Leader and Software Process Coach at AdventureTech

Risk management is nothing new to the project management community. But in software projects, the traditional approaches to managing risk are far from ideal. Traditionally, we have produced project documents with nice-looking risk matrices that are neatly categorized by severity and impact. This is nice to look at, but how does it help us manage real project risk? We seem to be good at identifying risk, but we give little or no guidance to project stakeholders on how to make decisions based on this information.

In software projects, effective risk management is about the process of making decisions—specifically, deciding the optimal time to execute a decision. The Lean software movement provides us with much better guidance in the form of principles and decision frameworks.

Take, for example, starting a large software project at your company. How do we insure we are not throwing this money away? In a traditional software project, we would come up with a “Grand Plan” that represents the project from A to Z and we would present that to decision makers for funding approval. With funding secured, we start that project boulder rolling down the hill.

When will we know we are building the right thing?

In this Grand Plan approach, we do not typically know until the very end, when the money is all spent. There is no actionable risk mitigation.

Defer Commitments
Grand Plan projects have little opportunity to manage risk along the way because most or all the the commitments are made at the beginning. For example, if we estimate our project cost to be $1 million, we secured that much funding from the overall budget and committed it all to the project at the beginning. What if we changed our strategy and decision making process? Would we better manage financial risk if we fund the first phase, say $200,000, then decide if it would be worth spending more? If so, then we are deferring the commitment of our entire funding amount until we know the project is succeeding.

Think about the same problem in our specifications. A typical Grand Plan will specify the product in total, to a high degree of detail. If we apply a preference to defer commitments in our specifications, what would our project plans look like? They would be a lot smaller, take less time to generate, and would be more meaningful. Instead of detailing precise requirements months in advance, we can defer that commitment until we have better information about the marketplace, our team, or the product itself.

Real Options
Real Options, as applied to software development, gives us a nice decision framework for determining when to defer commitments. The model is described as:

Options have value.
Options expire.
Never commit early unless you know why.

This approach is not complicated, but it has big implications. For many organizations, better risk management could save precious project funds. It could also be the difference between the next great product and something much less useful.

What do you think? How do you handle risk on projects?

Did you like this? Share it:

Open Mouth, Insert Software Toolbox

Monday, 25 April 2011 11:42 Written by Troy Tuttle 0 Comments

Image via Wikipedia

So often we hear the phrase, “I have many tools in my software development toolbox, and I like to use the correct tool for the job.” It sounds good. It appears to be a responsible approach. After all, why wouldn’t we want someone to have multiple tools at their disposal?

The whole toolbox metaphor is fine on the surface. My problem with it stems from the incidentals in the discussion. In my experience, most people who reference having a “software toolbox” are really hiding from a more direct questioning or discussion of specific practices or methods. Instead of advocating for those methods they believe work, or more importantly, listening to others advocate for their methods, many in our field throw up the “toolbox” as a defense mechanism. It makes for a clean exit too. The problem is this mechanism limits learning for everyone involved. The “software toolbox” is a conversation ender, not a conversation starter.

With that said, I am going to put my toolbox where my mouth is.

First, my obligatory disclaimer: Individual results will likely vary. Past performance does not guarantee future success. Your specific context and corporate culture are critical factors when deciding which tools are best for you. This is not intended as a comprehensive list.

Troy’s State-of-the-Art Software Toolbox:

Small Iterative Development Cycles: Software work is knowledge based. Knowledge in software is best improved by frequent feedback cycles. Early information feedback allows the team and customer to learn and improve at a much faster rate than when iterative approaches are not used.
Source: Extreme Programming, Scrum
Explicit Work-In-Progress Limits: Even when working iteratively, teams will often have too much WIP. Ever observe a Scrum team start every single user story by the first day? I have, and without an explicit policy limiting work-in-progress, teams and managers will try to push too much work into the system. WIP limits allow a team to begin finishing work instead of starting more work. Team context switching is minimized, giving the team the opportunity to improve quality.
Source: Kanban for software
Just-In-Time Planning: Plan just for what you can do, and nothing more. There is no waterfall-style comprehensive requirements document with this approach. Nor is it the heavy backlog grooming practices frequently seen in some Agile teams where user stories are analyzed and specified in detail months before they are implemented. Just-in-time planning also means no commitment-based time-boxed iterations. Optimal planning occurs when the the team is provided with the best thing to work on next, no more and no less.
Source: Kanban for software
High Discipline, Low Ceremony Engineering Practices: Emphasize practices that encourage collaboration and short feedback cycles. TDD/BDD and a continuous integration server are a great start. After-the-fact, formal code reviews are typically too late to add anything other than rework. Code metrics are fine, but be careful what you measure. Are your code metrics making the code easier to understand and change, or are you happy just to apply “standards” to your code? Covering code with tests is a good thing. But higher code coverage doesn’t automatically mean your code base is functioning the way your customer wants.
Source: Extreme Programming
Kaizen: Continuous improvement may come from inspect and adapt, PDCA, or other methods. It doesn’t matter if you prefer one over the other as long as you build an information feedback loop into your process. At the basic level, provide enough oxygen to the team to reflect, share ideas, and improve. Some teams may require regularly scheduled retrospectives, others may perform mini retrospectives or spontaneous Kaizen events during the project.
Source: Extreme Programming, Scrum, Kanban for software

I’m hoping this is valuable information for you. This is my toolbox, and these are some of the more valuable tools to me. If I show you mine, will you show me yours?

Will these work for you? I don’t know, that’s for you to decide. I just know that they work for me today. If I were a part of a brand new software team tomorrow, this is where I would start our discussion. And hopefully we grow to an even better place.

“Merely having an open mind is nothing: the object of opening the mind, as of opening the mouth, is to shut it again on something solid.” — G. K. Chesterton

Did you like this? Share it:

Agile Fundamentals: Follow The Knowledge

Tuesday, 15 March 2011 10:48 Written by Troy Tuttle 0 Comments

If you spend some time in our AdventureTech office, you will undoubtedly hear a significant amount of discussion around agile software development. Depending on your familiarity with the world of software, you may have heard of agile. For those not as familiar, it may just seem like more industry jargon and hype from the I.T. sector.

The good news?

With more than a decade of practice and experience, agile is well beyond the hype stage and continues to prove its worth one project at a time. A good starting place for agile education is the Agile Manifesto and the 12 principles that support the manifesto. True to the philosophical roots of agile, the substance of the manifesto is quite simple:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

The underlying theme across these value statements is knowledge; or more specifically, how to improve knowledge acquisition and flow in a software development project. Agile emphasizes the importance of information feedback loops–the shorter the better.

All software projects have feedback loops. The problem with traditional software methods is the lengthy feedback loop. Take, for example, a traditional waterfall project where all the requirements and analysis are done at the beginning. The coding and testing are not performed until the very end of the project. So on a nine month project, the customer does not benefit from an information feedback loop until the ninth month!

Contrast the traditional approach with Agile, where software is built incrementally and iteratively. An agile team will demo working software in a matter of weeks. The customer benefits from early feedback and the knowledge gleaned from the initial software testing. After one iteration, there is opportunity for improvement. The customer is able to ask: How does the software compare to our expectations? Are there defects? What should we do different in our next iteration? Agile teams typically conduct frequent project retrospectives to assess the information from the feedback loop, and take action to improve. The goal is to foster a culture of Continuous Improvement.

The benefits of feedback loops are not exclusive to the customer role. On a daily basis, agile team members learn from their experiences of working closely with each other and the customer. Through the iterative and Continuous Improvement process, they learn and improve. Even at the technical level, agile software developers employ coding techniques and automated tests that provide a feedback loop as short as a few seconds.

Ultimately, the key to quality software development is knowledge. And the best way to acquire knowledge in any software project is short feedback loops that allow the customer and provider alike to make the changes necessary to achieve success.

At AdventureTech, we proudly spend time and resources educating the community on a regular basis about agile software development. We would be happy to share our agile experiences with you. Contact us today if you'd like to learn more!

Did you like this? Share it:

Code Metrics as a Project Introduction

Tuesday, 15 February 2011 01:55 Written by Troy Tuttle 1 Comment

I recently started some analysis work for a new client at work. As we began our work, we were quickly confronted with a legacy codebase that would be the subject of our proposed work.

We need to give the client some technical feedback on the code. The obvious and common approach is crack open the solution and take a look. That approach usually results in anecdotal recommendations at best, so I turned to code analysis tooling.

In the .NET space, a popular code analysis tool is NDepend, so we gave it a try. NDepend generates a ton of metrics on your codebase and it is easy to get overloaded with data. So, it is important to remember what your goals are with code metrics. Do we need raw data or actionable information that can be presented to a client?

In our case, we need to report to our client the state of their codebase. Specifically, we need to convey how hard it will be to make changes to this legacy code. A nice visual cue is the Abstractness vs. Instability diagram provided in the NDepend analysis report:

NDepend defines “abstractness” as the percentage of abstract types (interfaces, abstract classes) to concrete types. Instability is defined as the ratio of efferent coupling to total coupling. Coupling at the assembly level is an interesting metric, but I am mainly concerned with the level of abstraction here. As the diagram shows, this client has two assemblies with good scores (orange arrows), but one assembly with a very poor score (red arrow). This would normally be a good sign, except that about 90% of the code is contained in the low scoring assembly.

Assembly level metrics are fine, but the metrics I am most interested in are at the type level. Assemblies can easily be manipulated by moving code around with any decent refactoring tool. But types are the building blocks of code and tell the true story of code quality. NDepend provides a matrix of scores for types as shown below:

The pink cells identify the worst 15% of offenders. I am most interested in CC (cyclomatic complexity), Ca (afferent coupling), and Ce (efferent coupling). If you are unfamiliar with the terms cyclomatic complexity and coupling in software, I suggest a little more reading on the topic. For our purposes, definitions are provided by the NDepend website:

CC: Cyclomatic complexity is a popular procedural software metric equal to the number of decisions that can be taken in a procedure.

Ca: The Afferent Coupling for a particular type is the number of types that depends directly on it.

Ce: The Efferent Coupling for a particular type is the number of types it directly depends on.

Once the analysis report is generated, a quick glance through the type metrics will give you a good indication of the relative health of the code. Lots of pink cells mean a more difficult journey ahead for the team.

NDepend provides some overall application metrics as well. Nothing earth-shattering, but it is interesting to know things like total number of lines of code, percentage of code comments, number of types, and percentage of public methods.

This is the type of information I find useful when starting a new codebase. I hope it’s helpful when you start your new project!

Did you like this? Share it:

Category: Troy Tuttle

Now Or Later: You Must Decide How To Manage Software Project Risk

Open Mouth, Insert Software Toolbox

Agile Fundamentals: Follow The Knowledge

Code Metrics as a Project Introduction

Connect With Us

Contact Us

Upcoming events

Recent Blog Articles

Blog Categories

Recent tweets