]]>I should also mention that my 3rd technique in these slides is similar to Todd Little’s model which appeared in the recent book, Stand Back and Deliver! The model uses four classifications of projects that Todd calls Sheep Dogs, Colts, Bulls and Cows. The Cows are analogous to my Cash Cows, Bulls to Major Growth Market and Colts to Innovative/New. If there is a difference it’s that my model is entirely market driven / external while Todd considers a complexity a dimension in the classification. These models are so similar that I will consider merging mine with Todd’s with full attribution.
Chris Matts’ believes that my first technique, previously published here in 2005 is similar to but less useful than Neil Nickolaisen’s model also published in the recent book, Stand Back and Deliver! Neil’s model maps projects at a portfolio level into 4 categories via a 2x2 matrix or dimensional assessment of market differentiation and alignment with corporate mission. He calls the segments: Don’t Care; Partner; Differentiating; Parity. While this model is certainly compatible with my model they are not the same. Neil’s model works at the project and portfolio level and assumes that the corporate mission is somehow correctly aligned with a strategic position and the market demands. My model works at the individual feature level and is again directly market facing insuring that the feature mix chosen for a project or iteration are aligned with the strategic positioning of the business and the allocation of types is aligned with the propensity for risk in the business plan or prospectus. Neil’s model is certainly compatible with mine. If for example, a project initiative assessed as “Parity” but the product owner was picking a lot of “Differentiator” class features for the product mix then there is clearly a miss match. So I believe that Neil’s model could be added as a fourth technique to the three presented here.
However, it’s worth noting that these are tools that can be used as choices and are not necessarily all designed to be used together. My 3rd technique, like Todd’s and Neil’s are designed to allocate resources to control commitment to projects across a portfolio. To spread risk effectively. It may not make sense to use more than one of these techniques at any one company or division. Choose the one that resonates best with your organization. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management, Risk+Management, Risk, Portfolio+Management, Program+Management
]]>Download New Approaches to Risk Management PDF
Here is the original session submission…
Presenter: David J. Anderson
Title: New Approaches to Risk Management
Background
—————
For almost a decade the agile community has claimed that agile development is a risk-driven approach. Yet there is very little published material on agile risk management. A survey of the transactions of the Agile conference over 4 years reveals no explicit presentation on risk management. An online search reveals a number of blog entries and articles on agile risk management(of which more later.)
Traditional risk management (defined in the PMBoK, Prince II, CMMI and other frameworks) takes an event driven approach to risk. It seeks to model external variations that affect schedule, budget and scope on projects. Traditional risk management focuses on what Walter Shewhart called “assignable cause” variation [Deming renamed this “special cause”.] The model is simple: try to build a list of external events that might occur; assess the impact and likelihood of occurrence; assess the cost of mitigation options; decide whether to mitigate (reduce chance of occurence) or create a contingency plan (to recover in the event of occurence.)
Most of the agile risk management articles surveyed look at how to implement traditional risk management in a more agile way. They address how to fit risk management into iterative, incremental development and how to assess and manage risks in a collaborative, transparent manner. There appears to be no literature that discusses how to apply agile and lean ideas that revolutionize risk management.
Meanwhile, traditional (non-agile) project scheduling techniques treat all tasks homogeneously from a risk management perspective. Elementary scheduling techniques do not account for variance in task completions, e.g. the Gantt chart technique. More advanced techniques (PERT, Critical Chain, Last Planner) account for variation and provide some risk mitigation against chance (or common) cause variation through time buffering. However, these techniques still tend to treat all tasks homogeneously from a risk perspective.
Project risk management literature does not appear to have advanced much in the last 30 years.
New Approaches
———————
The application of Lean pull systems (kanban) and Real Options Theory in agile methods is providing new sophisticated means to manage overall business risk in technology projects and software delivery.
This tutorial will describe in detail 3 techniques that have evolved in the kanban community that provide improved project flexibility and business agility together with increased sophistication in risk management.
(1) Using classes of service based on cost of delay/failure functions
Classifying customer-valued deliverables according to the cost of delay (or failure) function allows for different prioritization policies to be implemented on the fly by self-organizing teams significantly reducing the business risks of late delivery. This scheme classifies customer deliverables such as user stories heterogeneously according to the loss incurred due to late delivery. Assigning different colored sticky notes, or index cards according to the classification allows team members to quickly assess risk and pull the most important item through the system in a self-organizing manner
Four example classes of service will be discussed along with their related pull system policies (for prioritization and scheduling) will be presented. The examples are: expedite; fixed delivery date (unit step cost of delay function); quantitative value delivery; and qualitative value delivery. Other classification schemes are possible and would be domain specific.
(2) Iteration Backlog selection based on market risk
This scheme allows for classification of customer-valued deliverables into 4 categories that are aligned with strategic planning and marketing objectives, namely: commodity (or table stakes); differentiator; spoiler; and cost saver. Features or user stories in each category exhibit different risk of change (deletion from scope, or change in definition) due to market conditions during the lifetime of the project, prior to release. The variance in market risk can be used to quickly prioritize iteration backlogs and target backlog items for iterations within an overall project schedule. The scheme mitigates the risk of rework (or waste) caused by changes in scope associated with changing market and business conditions.
(3) Risk-based Portfolio Management
This scheme allows the balance of resources and funding across a portfolio of projects or business initiatives based on the alignment of a project or development initiative with the strategic positioning of the business and its desired risk exposure.
Projects can be classified in to 3 categories: cash cow; mainstream developing market; and emerging market. Portfolio management is conducted similar to investment portfolio management by balancing investments and risk according to the risk preference of the investor. Hence, cash cow is analogous to bonds in an investment portfolio, mainstream developing market, is analogous to large cap stocks, and emerging market to small cap stocks. Resources and funding are allocated according to desired risk profile and kanban systems established for each line of business (or business initiative). Market releases (or projects) are defined to release value optimally based on transaction and coordination costs of making such a release.
Summary
———-
These three techniques combine elements of Lean Thinking and Edwards Deming’s New Economics (cost of delay/failure functions, waste (transation and coordination costs, rework or scrap)), Real Option Theory and Decision Tree analysis to provide methods that enable simple, fast, and often self-organizing approaches to maximize business value and manage risk throughout a portfolio and the project lifecycle.
Notes
——-
Most of this material has been previously presented anecdotally as part of presentations on kanban. Some of it has been documented at agilemanagement.net as blog posts. However, this tutorial will pull it all together, formalize it as a risk management approach and refine and develop some of the ideas.
The material is therefore new in this format but based on work and presentations given over the last 2 years.
The presentation will likely be trialed at various smaller venues prior to Agile 2009. In the first instance at the kanban conference in Miami in February 2009 to an audience of perhaps 50 people. Other opportunities of rehearsal performances will be available at local events such as the San Diego XP Users Group in May 2009.
I intend to submit a formal paper for the transations.
Reference Material
—————————
Survey of online articles on agile risk management
Appelo, Jurgen, http://www.noop.nl/2008/06/agile-risk-management.html
Cottmeyer, Mike, http://blog.versionone.net/blog/2008/05/agile-risk-mana.html
Cottmeyer, Mike, http://blog.versionone.net/blog/2008/05/agile-risk-ma-1.html
Cottmeyer, Mike, http://leadinganswers.typepad.com/leading_answers/2007/09/agile-risk-mana.html
Fitzgerald, Donna, http://www.cutter.com/research/2006/edge060711.html
Griffiths, Mike, http://leadinganswers.typepad.com/leading_answers/2007/09/agile-risk-mana.html
Rangaswami, JP, http://confusedofcalcutta.com/2007/07/06/how-risk-management-affects-agile-approaches/
Smith, Preston and Roman Pichler, http://www.ddj.com/architect/184415308
Thomas, Steven, http://www.itsadeliverything.com/articles/agile_risk_management.htm
]]>
For now the existing Agile Management blog will continue to aggregate all the content. Later I will reduce it to Management topics only. However, I will maintain the existing RSS feed for both the home page and the Agile Management blog. The RSS feed will continue to aggregate everything that is posted to this site. The new RSS feeds should enable aggregators to be more focused. Kanban sites can pull the Channel Kanban RSS feed while CMMI sites can pull the Channel CMMI RSS feed.
As a result of these changes, some content in the site has disappeared the navigation or the archive search. The articles specifically about the Agile Management book are no longer available through the site navigation. However, they are still in the content management system and still available on the Internet via direct links. Older news articles that do not appear on the front page will also not be navigable but again they have not been deleted and are still accessible via direct links.
I hope that these changes provide a genuine improvement in utility for users of the site and those who value its content. There are yet more changes to come as I prepare my web presence for the next decade and modify it to accommodate my newer interests in Kanban, CMMI, and other newer areas like Real Option Theory, Management, Decision Making, Decision Bias, Neuro-psychology and Risk Management.
]]>After some initial market research via my Agile Management Yahoo! group and Hillel Glazer’s Agile CMMI LinkedIn group and Twitter, it looks like we are targeting early December or mid-January somewhere in Florida.
Please leave comments indicating which dates you would prefer, which location (a) Tampa, (b) Orlando, (c) Miami, and please recommend anyone you feel should be an invited speaker at such an event. Would you like 1.5 days or 2.5 days and how much of that time should be dedicated to open space?
[Current voting as of 6/17 - will try to update this daily for a while]
Your comments and commitments to attend are vital if this event is to go ahead. Without sufficient interest we won’t run the event. Technorati tag: David+Anderson, Agile, CMMI, SEI, Hillel+Glazer
]]>
]]>Meanwhile, Jeffrey Palermo picks up on my piece for Borland on why you should just say “No!” to an formal Agile transition initiative, Why Agile Transition Initiatives Might Fail!
Margaret Rouse highlights Kenji Hiranbe and I and observes that Kanban is a way to visualize bottleneck in a software development project.
Keith Henry’s been researching how to tailor agile to your organization. While he cites my work on Agile+CMMI he might enjoy my series for Borland more: Agile Transition Initiatives - Just Say No!; Creating an Agile Culture!
Jason Yip rediscovered one of my older gems identifying that liberal versus conservative culture is a bigger influence than high trust versus low trust in driving Agile adoption.
Pascal Van Cawenberghe asks “Why Estimate?” and cites several leading thinkers on this space including Amit Rathore, Joshua Kerievsky and me.
Richard Veryard tickled me with his wittily titled Restaurant at the End of the Universe over at his Demanding Change blog.
Defense Industry Daily was so impressed with my Top 10 rated talk at the SEPG conference that they suggest it’s time to Sharpen Yourself a Kanban System for Software Engineering. Yes indeed! :-D We already have a Kanban implementation with the Danish Department of Defense. I’m hoping for more traction in the defense sector in the next year. I really do hope that Kanban becomes the unifying force that brings the Agile world and the big software and system engineering firms together.
Hillel Glazer noted that my SEPG session on high maturity metrics and Agile was packed and locked out and no one left early. I wonder who I impressed? His notes from Wednesday tell the tale of the Agile + CMMI open space with a super picture of how many people we had at that session and then with another wonderful picture of one of my slides we get Hillel’s take on my Agility & High Maturity talk - naturally Kanban is at the heart of it but Hillel calls it correctly - set high maturity behavioral expectations early and choose metrics and data wisely. His Tuesday notes cover the CMMI + Agile: Why not embrace both talk given by Mike Konrad and supported by Hillel, Jeff Dalton and I.
The folks at Enthiosys (Luke Hohmann et al) have been thinking about Agile maturity models and comparing my work on Agile + CMMI with Bas Vodde and Jeff Sutherland’s Nokia Test.
Allan Kelly gives us a list of 10 Things to Know About Kanban Software Development. Very handy! Allan also helps us to Make Sense of Kanban.
Meanwhile, Boris Gloger describes my use of Kanban as “harmful for software development.” 
How many people actually doing it believe that? I wonder if Boris has ever tried it? Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, CMMI, Software+Engineering, Project+Management
It’s occurred to me that in aggregate these articles would a great little book or pamphlet on enterprise scale agile transition. I’ve been greatly impressed with the work Wordclay did on the Lean & Kanban 2009 proceedings book, so I’ll have a discussion with them about publishing these in a book format. Technorati tag: David+Anderson, Agile+Management, Agile, Borland
]]>My first post is titled Agile Transition Initiatives : Just Say No! And is the first in a series where I’ll be talking about organizational maturity and capability along with the notion of a kaizen (continuous improvement) culture of innovation facilitated from the top, but led from the bottom.
These days Borland is a very different business to the old developer tools IDE business that they spun off as Code Gear. A few years ago they acquired Terraquest, a firm run by ex-SEI and CMM expert Bill Curtis. We became friends while I was working on MSF for CMMI Process Improvement at Microsoft. Bill provided me with guidance on CMMI Level 4 metrics and we talked a lot about Deming and whether “common cause systems” approach could be applied to knowledge work problems like software development.
Meanwhile, as Borland has evolved these past few years, their interests and mine have converged - on Enterprise Scale Agile Tranformation. It turns out that the folks there share my opinion that organizational maturity is a vital part of the mix to institutionalizing Agile development at scale and to creating an _agile_ business. While I’ve been advocating Agile+CMMI they’ve quietly been building traction around their own maturity model concept. I’ll be contributing 3 or 4 blog posts per quarter specifically focused on large scale Agile adoption and business agility over at the Agile Transformation Forum. Check it out! There is some really great community content there with some true experts writing it. Technorati tag: David+Anderson, Agile+Management, Agile, Borland, CMMI, Stephen+Palmer, Peter+Coad, Bill+Curtis
]]>Israel Gat also posted his thoughts on Continuous Deployment (or Customer Driven Testing) following an interesting Twitter discussion mainly between James Shore and me. What’s interesting about this one is the consideration that even if the technical team is capable of continuous deployment it is undesirable if the end customer is incapable of absorbing such frequent releases or the economic cost to that customer is unacceptable.
And Dave Nicolette’s been in on the action too, explaining how Kanban is an Agile method. This post from Dave was prompted by my Kanban & Planning and Estimation post to which he posted a comment.
And Eric Willeke spotted this blog with lots of Kanban posts… WingingIT Technorati tag: David+Anderson, Agile+Management, Agile, Lean, kanban, Software+Engineering, Project+Management, Israel+Gat, Dave+Nicolette
]]> Technorati tag: David+Anderson, Agile+Management, CMMI, Hillel+Glazer, Scott+Ambler, Mike+Konrad, Jeff+Dalton, Sandra+Shrum, Software+Engineering, SEI, Carnegie+Mellon, Dr+Dobb’s
]]>http://agile2009.agilealliance.com/node/96
If you intend to submit a proposal yourself please do so as soon as possible. Let’s make the open review system work properly. Folks who submit early should be most likely to succeed. Technorati tag: Agile+2009, Agile+Alliance, David+Anderson, Project+Management, Portfolio+Management, Risk+Management, Real+Options, Kanban, Lean
]]>This is a stage for pioneering Agile thoughts, practices, models and questions. It is a place to share emergent, intriguing, minority interest and innovative ideas. It is a home for unfashionable concepts, unpopular ideas and dissenting voices.
It is fertile ground for slow burning, long term ideas, where they can grow and thrive. Ideas like Agile Contracting, which appeared in Breaking Acts last year but is still a minority interest activity very much in its infancy.
The Agile Frontier stage accepts proposals that are new and do not fit into the existing categories. It is the home of every idea for which “people” say “it is not Agile” or “it is just wrong”. It is the double black run for your new ideas as a speaker where the audience will challenge you on every aspect. Performances on this stage may illuminate new approaches that will make you question your beliefs or inspire you to try something new. Whatever the specific content is, each session will challenge you to think hard about what you do, whether you’re presenting or attending.
Performances on this stage may or may not impact the future direction and maturity of Agile processes. At the same time, it is the place to visit to see what could become hot in the next five years. Technorati tag: Agile+2009, Agile+Chicago, Agile+Alliance, David+Anderson, Eric+Willeke, Olav+Maassen, Johanna+Rothman
I find Ahmed’s attitude to be academic and unrealistic. It relies on the process and removes focus from the people. His argument that all the submissions for Breaking Acts in 2008 could have been accommodated on other stages might be valid in theory but in practice they would never have been accepted. In the agile community we should know better than this. We value individuals and their interactions more than we value processes and tools. Ahmed is asking me to put my faith in the review process and the online review tool. I prefer to put my faith in human nature. [...]
First let me state that Ahmed has been a keen innovator in our field and a true supporter of innovation and protector of those ideas. He was involved in our agile model evolution discussions at Agile 2008. He truly understood and supported the idea that we needed a more expansive and scientific definition of our agile values that would allow us to recognize new innovative practices as aligned to our underlying agile values. I have every faith that Ahmed wants to see innovation in our community and that it should be present at the Agile 2009 conference.
So moving on to my remarks about people versuses process and tools. These remarks were prompted by this paragraph from a private email from Ahmed to me, Olav Maassen (and others.) I am reprinting this with Ahmed’s permission.
I really have a lot faith in our peers that they can spot innovation when they see it. If you look at committees that are in place for each stage - you will see that these are competent professionals who I don’t believe have hidden [...] agendas. I believe that if a group of 10 of our peers look at a submission and say it is not suitable for the conference - then that means quite a bit to me. Why would I think that only those handling the Breaking acts stage could “spot” innovation.
There are really two established interpretations of the Agile Manifesto statement that we value “Individuals and Interactions over Processes and Tools.”
There is a simplistic interpretation. It is the interpretation that we simply must have good craftsmen and that tacit knowledge transfer will always work best. I feel this is an elitist interpretation. It’s exclusive in nature and suggests that only truly great craftsmen (developers) are welcome in the community. It also completely fails to scale beyond teams of 6 to 12. This view outlived its usefulness years ago. Applying the benefits of agile development to enterprise scale problems has been an active topic in the community for 6 years and it simply isn’t possible for every IT worker in every enterprise to be a truly great performer.
A second more useful interpretation is that individuals implies psychology and that interactions implies sociology. In other words, we believe that effects of psychology and sociology are much stronger than the effects of processes or tools in determining an outcome, and hence, processes and tools must be designed to accommodate human nature and work with, rather than against, recognized psychological and sociological effects. This is largerly the work we have been doing for the past decade. We’ve been throwing out old development processes and tools that denied the fundamental human nature of our work and did not adequately reflect the psychology and sociology involved and replacing them with more human friendly processes and tools. Feature Driven Development embraced the idea that we need a solution for large teams and adapt to the psychology of the people on the team. Jeff De Luca’s 1st law, “It’s 80% Psychology, and 20% Technology.”
While I have no doubt that Ahmed has a deep belief in people and their ability to do the right thing, I find his confidence in the correct outcome unrealistic. Ahmed believes that the people will overcome the process and tools (in this case the announced program and the submission and review system) that are by their nature designed to solicit submissions for the topics named in the announced stages, and uses a popular democracy mechanism (albeit an open flavor) to select the winners. He asked the stage producers and reviewers on a conference call recently, to watch out for innovative ideas and to protect and support them.
I have two problems with this. The first is that the system is designed not to encourage submissions about topics not listed in the announced program. Psychologically and sociologically there is nothing in the announced program to encourage submissions on other topics or dissenting viewpoints. The second is that while the reviewers may have heard Ahmed, understood him, and value his message, they will not as a group be able to advocate for and protect the innovative, or dissenting ideas that compete against other submissions that fit nicely with the envisaged stage. Again it is simply the natural effect of the psychology and sociology designed into the system. The popular democracy will tend the outcome to the safe middle ground.
Ahmed and I have agreed to disagree over our opinion on this.
Meanwhile, Ahmed is worried that folks in the community have formed the opinion that he doesn’t understand the Agile Manifesto and the principles that our community is formed around. If this is true, then I apologize for seeding that opinion. I am quite convinced that Ahmed does “get it” and that he has a valuable part to play in our community. I look forward to working with him on it in future. If I have a criticism it is simply that I feel he is putting too much faith in people. Too much faith that they will do the right thing and follow the direction that was provided as a bandaid because the Breaking Acts stage was dropped from the program.
[I hope that clears this up. It’s very difficult to articulate. Meanwhile, Ahmed has a proposal he is circulating that may lead to a satisfactory resolution of the matter. I want to give him the space and time to work this and I am confident of a satisfactory outcome.] Technorati tag: Agile+2009, Agile+Chicago, Agile+Alliance, David+Anderson, Ahmed+Sidky
]]>