Creating a Risk-Adjusted Backlog

This article explains what a risk-adjusted backlog is, why they are useful, how to create one and how teams work with them. What is a Risk-Adjusted Backlog? A risk-adjusted backlog is a backlog that contains activities relating to managing risk in addition to the usual features associated with delivering value. Agile projects typically prioritize the backlog based on business value or perceived needs. The Product Owner or business representative prioritizes the backlog elevating the highest value features to the top, so they get delivered first. Taking an Economic View of Decision Making Prioritizing based on business value is an example of the lean concept of ‘Taking an Economic View of Decision Making.’ In deciding which feature to develop first, those […]

Read more

Estimating Agile Projects…Or Not

Project managers generally like plans and estimates so we can forecast when things should be done and how much they may cost. It helps manage client expectations and answer the type of questions they ask, such as "When will it be done?" and "How much will it cost?" So, when project managers hear about ideas such as "let's stop estimating," it can trigger a knee-jerk reaction. It sounds lazy and avoiding the hard work of having to estimate. It can seem like people want to shirk their responsibility and accountability. First, those lazy agilists wanted to stop doing documentation; now they want to stop estimating too! There has been a debate raging since 2012 about the use and value of […]

Read more

Playing in the Gray of Hybrid

Gray areas occupy the transition from one world to the next. Neither black nor white, predictive nor agile, project managers are increasingly finding themselves in the gray area of hybrid project management. This can make us feel uncomfortable since we are neither faithfully following either approach—instead living a compromise between seemingly different value systems. We could get uncomfortable, guarded and hesitant to embrace the reality we face. Or, we could welcome it, use it to our advantage and share the benefits/trade-offs with anyone willing to listen. This second option of embracing, using and sharing is “playing in the gray area,” a term I learned at a recent workshop I was giving. It nicely summarizes the idea of accepting and making […]

Read more

Review of Product Development Books

Now that a software “Done” Milestone is more like a Tombstone If you work in an industry that has digital products and services then the Product Development trend will impact you. As software becomes more critical to business operations and product offerings we are seeing that software projects do not end. Many organizations are transitioning to become software focussed organizations that offer specialized services. Amazon is a software company with retail (and cloud) offerings. Banks are increasingly digital companies with financial services. The same with insurance, travel, music and even commercial goods. The cost of developing the software in new vehicles is now greater than the cost of the engine. It has become the single most expensive component, even in […]

Read more

What’s in your Backlog?

Let’s explore what you do and do not put in a backlog. How do these sound? Features and non-functional requirements – Absolutely Bug fixes and change requests – Yes, probably Risk avoidance and risk reduction activities – Sure, maybe Opportunity exploitation activities and marketing ideas – Now you’re just getting weird! Team building and social events – Erm, no! Yet, if it’s all just stuff for the team to do, then why not put it in the backlog? Maybe because the customer has not asked for it and the product owner has to own and order it, but let’s look further. If we used a backlog metaphor for prioritizing backlog work items. It may look like this. I am not […]

Read more

They are “Lessons to be Learned”, not “Lessons Learned”

The suggestions, observations and ideas we capture at retrospectives are not Lessons Learned. That would imply we have already learned from them and will not make that mistake again. Instead, they are Lessons-to-be-Learned which is subtly different but stresses the most important part, which is we now need to learn something. Learning involves several steps. David Kolb, an educational theorist, describes a 4-step learning process: Concrete Experiences (What we already know) Observation and Reflection (What our retrospectives help us identify) Abstract Conceptualization (Thinking about the problems and designing potential solutions) Active Experimentation (Trying something new) These stages act as part of an experimental learning cycle. The last step, Active Experimentation, creates new concrete experiences and builds on what we already […]

Read more

New PMI-ACP Workbook

I am pleased to announce the availability of my new PMI-ACP Workbook. This new workbook focusses on a smaller subset of 50 key topics.   My original PMI-ACP Exam Prep book distilled all the relevant content from the 11 books on the PMI-ACP recommended reading list in a common voice. The workbook is also different by providing lots of exercises and many situational questions like you will find in the exam. So, while my PMI-ACP Exam Prep book covers all the background and theory – ideal for a comprehensive coverage of everything in the exam, the new PMI-ACP Workbook is a practical, hands-on study tool that focusses on the core topics needed to pass the exam. If you already have your […]

Read more

Agile Risk Management

This article aims to dispel the myth that agile projects somehow magical manage risks for us, and outlines a couple of practical tools that can be used to start improving risk management approaches.  Agile is Not a Risk Management Approach Some people believe agile approaches with their short cycles and regular feedback have a risk management approach naturally built into the process.  It is easy to see why, the building blocks and attachment points for plugging in an effective risk management process are undoubtedly present, but unfortunately, just building something iteratively or incrementally does not ensure risks are managed. It is all too easy to develop iteratively, missing opportunities to actively address threats or exploit opportunities. Many agile teams also […]

Read more

When Outsourcing Makes Sense

Disclaimer: This article is based on my personal experience of software project development work over a 25 year period running a mixture of local projects, outsourced projects and hybrid models. The data is my own and subjective, but supported by 1,000’s of industry peers I question while delivering training courses for the PMI. I do not work for a local based or outsourcing based company, I have nothing to gain from favoring either approach, but I hope these thoughts are useful for determining some of the pro’s, con’s, true costs and circumstances when outsourcing is better or worse than local development. To the uninitiated, outsourcing seems like a great idea. Software engineers are expensive in many countries but much cheaper […]

Read more

Agile Benefits Management

Benefits are why we undertake projects. Projects are expensive to undertake and have a risk of failure. So, we need to get benefits from them, or at least think we will get benefits from them, to start projects in the first place. Often the benefits of a project are not fully realized until after the project is finished. This is why benefits management is usually the domain of program management. Sitting a level higher than individual projects and operating over longer timelines, programs are better positioned to identify, track and transition benefits from individual projects or groups of related projects. Agile approaches place strong emphasis on delivering business value. Work is prioritized with the highest business value items done early […]

Read more