In the absence of done... there is risk.

Agile methods put a high premium on what it means to be done. But if done is so valuable to our projects... just what exactly does done mean? Is there one universally accepted definition of done... or are there varying definitions of done depending on your circumstances? Personally... I have used and coached several definitions of done and am pretty much cool with all of them.

My favorite definition of done was something that I used back in my CheckFree days. We defined done as a feature that was designed, documented, developed, tested, accepted, ran on the UAT server, could be run from the Product Owner's laptop, and that the Product Owner was proud to show to their customer. We did not specify 100% test coverage or that the software was released to production... were we done?

What about the situation where a team is transitioning to agile and trying to iterate through a big up-front design document to ultimately get ready for a big back-end test effort after all the code has been written. That team defined done as working software with 100% test coverage and deployed to the alpha environment. Were they done?

Here is a situation I was talking through today. What if you are developing a feature that has dependencies with several component teams across a large complex enterprise. If one of the component teams delivers an API that is fully designed, documented, developed, tested, meets the specification, and is ready to be integrated with the other components into the larger feature... is the component team done? What about the feature team?

Done can mean lots of things... and the definition of done needs to be defined by the team doing the work and the organization receiving the work. To me... it is a matter of risk. How much risk are we absorbing leaving the code in it's current state?

While not perfect, I felt pretty good about the definition of done on my CheckFree team. The transitioning team I mentioned is actually absorbing quite a bit of risk with that big back-end testing effort... but given their circumstances... I would accept that definition of done and work to mitigate the risk. In the last scenario... the component team is done but the feature team is not until the code is integrated. Does the component team absorb some risk... absolutely.

The definition of done should be driven by the potential impact to the project. We are assessing the risk that we think ourselves done but really aren't. We are assessing the risk that we have to go back and fix something. We are asking how much risk we're absorbing if we allow partially completed work to move forward in the development process. That could be as little undone work as allowing less than total test coverage or as much as allowing a component team to move forward before their work has been integrated into the larger, customer facing feature.

In the absence of done... we have risk. I am okay defining done differently as long as we address the risk and have a solid strategy for mitigating that risk.

Subscribe to Leading Agile

Agile is Risk Management

There was a great question last week in the comments of one of my blog posts. The reader asked if agile offered any unique proposals for managing risk on a project? I've been blending my traditional background in project management with agile for several years now and sometimes I have to remind myself of what I've taken from what sources.

After reviewing the PMBOK section on Project Risk Management, I had to conclude that Agile doesn't really offer anything new. Surprised? The PMBOK has processes for developing a risk management plan, identifying risks, performing qualitative and quantitative analysis, conducting risk response planning, and monitoring and controlling risks.

You can clearly make the case the agile might take a lighter approach to risk management, maybe rely less on documentation, but fundamentally you are doing many of the same activities on an agile project as you might on a traditional project. Why are agile methodologies so good then at identifying and mitigating risk?

Agile is so effective at managing risk because risk management processes are built into the very fabric of how we run the project.

There is an implicit understanding that risk is EVERYWHERE on a project. Risk cannot be contained in a risk list. Risk cannot be mitigated in a team meeting or a periodic risk review session. Dealing with risk has to be an obsession. Our mitigation strategies don’t live outside the project, but influence the very nature of how we structure and plan our work.

Many project managers take a boiler plate approach to risk management. They deal with the easy stuff, the obvious risks that could be assigned to almost every project. Are we going to run out of money? Are we going to lose a key contributor? What happens if the project is late? While these are all important, they only represent a small slice of the kinds of risk we need to consider.

As project managers, we tend to assume that the business vision is accurate. We assume that if we deliver to the spec we'll satisfy the market needs. We gloss over technical uncertainty because the technology guys are responsible for making all the code work. More detailed planning and designs do not mitigate risk. The only thing that really mitigates risk is delivering product.

Agile mitigates risk by building project frameworks that encourage frequent delivery, constant inspection and review, and allow us to adapt when things are not going as you expect.

In short, agile is risk management.

Subscribe to this blog Subscribe to Leading Agile

Agile Risk Management - Logistical Risk

This is the final installment of a three part series on Risk Management. Part one discussed how I think about business risk. Part two dealt with how to think about technical risk. This post will address some things to think about when considering logistical risk.

Logistical Risk

Logistical risk deals timing and team member availability. These are your people and money risks. Once the business risks are mitigated and we have proven there is a viable solution, this is where the team can really scale the project and build out the bulk of the solution. Here we are answering questions about having the people to do the work. We are monitoring to see if we are making the progress we expected at the beginning. Are we going to have to make any tradeoffs to hit our market date?

Logistical Risks deal with people. Do we have enough people to do the work and are our original assumptions about their capacity going to hold?

In reality, you are dealing with all three types of risk all through the project. The focus becomes logistical risk once you have tackled the other high risk areas of the project and are ready to get down to the business of building out the product. On a large team, you have probably broken your core team up to seed other small teams on the project. As the project scales, you are working to make sure the interactions between the teams are running smoothly. You are concerned with establishing a stable team velocity, grooming the backlog, and making sure that you are regularly delivering business value.

You are working to make sure that the team has everything it needs to be successful. You are actively removing impediments, and interacting with other parts of the business to prepare for your final product delivery. You are probably coordinating the availability of extended team members, managing external dependencies, and possibly dealing with unexpected departures. Logistical risk is about managing the team through the life of project execution.

In Conclusion

I have witnessed too many Project Managers dealing with risk as something external to the project. It is as if the project is on one track and risk management is on another. Risk management is not a separate process that lives outside the way we build software. Risk management needs to be built into the very fabric of the project itself.

Delivering product to customers mitigates all kinds of risk, let's do that a lot. Continuous integration mitigates risk, let's do that too. Continuous testing mitigates risk, let's test all the time. These are not things that the technical team just does, they are things that project managers need to make sure is happening. We need to make sure they are built into the foundation of our project management approach.

Subscribe to this blog

Subscribe to Leading Agile

Agile Risk Management - Technical Risk

This is part two of a mini-series on risk management. Part one discussed how I think about business risk. This post will address some things to think about when considering technical risk.

Technical Risk

Technical risk deals with those unproven assumptions in your emerging design that might significantly impact your ability to deliver the solution. Are we planning to use any unproven technologies to build the solution? Have we exercised the significant interfaces between systems? Can we demonstrate a working skeleton of the system? What about performance? What about security? Any technical decisions not validated by working software count as technical risks.

Technical risk deals with feasibility. In other words, have we proven there is a solution that can be delivered within the time and cost constraints of the project?

Technical risk is also dealt with early in the project immediately after you have a handle on the critical business risks. This is where the team really gets engaged for the first time. You bring your resources to bear to build out the system and validate any assumptions you made during planning. The backlog should be prioritized with an eye toward technical risk. Build out those features early that are most likely to validate your architectural assumptions and stabilize your emerging design.

It is worth emphasizing here that technical risk should always be mitigated in the context of working software. We build features to mitigate risk. Proving interfaces, or that one system can talk to another, outside the context of delivered business value does little to prove anything or mitigate any real risk. Testing is an integral part of risk mitigation. Untested features deliver no value.

As we build features, we will certainly learn more about the architecture and more about what it is going to take to build out the proposed solutions. Stay open to this new information. Re-estimate the backlog if necessary. Share this information with your product owner. Allow them the opportunity to learn along with you and adjust their plans and expectations accordingly. Look for technical tradeoffs that will allow you to deliver within the agreed upon time and cost.

What happens if you prove there is not a solution that can be delivered within the time and cost constraints of the project? Sounds we've just identified a pretty significant business risk. Mitigate your technical risks early and ensure feasibility while your overall investment is still relatively low.

Click here to read my previous post on Business Risk. Next post we'll address Logistical Risk

Subscribe to this blog Subscribe to Leading Agile

Agile Risk Management - Business Risk

As project managers, we must understand how to identify risk and how to put strategies in place to mitigate their effects. To put an effective strategy in place, it is necessary to consider what factors are leading to the risk and when these factors are most likely to impact your project. Over the next few posts we'll talk about three common categories of risk, how we distinguish them from each other, and what we can do to make sure they don't negatively impact our project.

Business Risk

Do we have reason to believe the features we've scheduled for the upcoming release will deliver the value we have planned? Do we have reason to believe the team can deliver that value within the time and cost constraints we have established? What about our customers, have they weighed in that we are building the right product? Is everyone on the team organized around a clearly articulated product vision? Answering these kinds of questions is what it means to mitigate business risk.

Business risk deals with value. In other words, can our project deliver the value we have promised to the business?

Business risk is one of the first kinds of risk to consider on a project. This is often addressed before the entire team really gets going on the project. In this stage, you are setting goals, chartering the project, and getting the project funded. Once the vision is set, make sure that the features you define in the product backlog are focused on delivering that vision. Weed out requirements that are not necessary to deliver that vision, keep things as simple as possible.

Establish a high level architectural approach for the product and use this common understanding as a baseline for estimating and planning. Estimate your backlog, keep it prioritized, and work on the highest value features first. Measure the throughput of the team and assess progress against your backlog. If your team's throughput is less than expected, deal with these issues immediately. Give your product owners the opportunity to adjust the scope of the release or negotiate detailed feature functionality.

Constantly reevaluate the product backlog in light of what we are learning from the emerging solution. Don't assume that the original features are the right features to deliver the vision. Stay open to new information and be willing to learn. If you find that what you are learning is moving you away from the original product vision, ask the hard questions about the project and help the business decide if this new direction is consistent with the organizations goals. If not, what does this mean for the product?

Dealing with business risk involves balancing the product vision, market needs, and the emerging solution. Maintaining the right balance between these three factors is how we guide the project into a successful outcome.

Next post... Technical Risk

Link to my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/05/agile-risk-mana.html

Subscribe to this blog

Subscribe to Leading Agile