Tag Archives: Agile

Scrum is a World View

Guest post by Jim Kinter

I’ve been thinking about how to help a colleague get his arms around a Scrum implementation that seems to be out of control and rife with what my friend Ken Schwaber refers to as “ScrumButs”.

During our conversation, I cringed several times when reference was made to their “version” of Scrum as well as their version of “TDD”.


I think that this is a common trap that managers fall into when trying to adapt their organizational culture to become more “Agile”. The bottom line is that if you’re adopting Scrum because of business value motivators like profitability, product turn rates, cost control, or to compress/reduce feature release windows then I would tell you that your heart is in the wrong place and that you really need to re-assess what the value proposition is for implementing Agile software development methodologies/techniques. In my opinion, being successful at Scrum requires more of a change in personal and managerial philosophy than it does any type of technical or procedural change.

You see, I really struggle when I use the term “methodology” in the same sentence as Scrum because it’s not really a methodology…nor is it a technique….framework…technique…bleh. It’s all of those and none of them at the same time.

Scrum is a Philosophy

It’s a world-view relating to managerial interaction with those involved in production.

If you want to know how to succeed at implementing Scrum, I would recommend that you start with a read of Ken Blanchard’s book titled “The Servant Leader”. Once you have your heart in the right place, you’ve put aside the “command and control” mindset, and embraced the TPS/Lean concepts of empowering and enabling the team to make “management” decisions, and finally resolved to give them the power to make those decisions, now you’re really ready to tackle Scrum.

Now it’s time to take on the hard stuff like finding, training,and getting on the same page as the Product Owner(s) and really getting on down the Scrum road. Much like political or religious world-views, If you can’t put aside, or your organization isn’t structured to let you put aside these fundamental beliefs and opinions about people, roles, and responsibilities, you really need to abandon the idea of implementing Scrum/Lean/Agile until you can come to terms with what it means to lead people versus what it means to manage them.

Scrum Tune-up

Guest post by Jim Kinter

In my previous post I referenced a conversation with a colleague about a Scrum implementation that hasn’t produced the results he expected. His expectations from the outset seem to be primarily focused on productivity, but motivation and drivers for choosing Scrum is for another day. As I was mulling this over I kept coming back to the variations in the Scrum technique and what seem to be gaps in the technical practices that are mandated in other Agile methods. When I compiled the list I was wondering if this list might be of value to someone else. if so, here you go. I also need to make sure that you know that this is by no means a comprehensive list, but just some things that, in my opinion, every team using Scrum (especially in the. NET realm) should be doing.

  • Be SOLID – Learn the S.O.L.I.D. principles. Practice them. Take no prisoners.
  • Get DI – make sure that you and everyone on your team REALLY gets Dependency Injection and uses it where appropriate. If you do it right, you’ll thank me later. If you don’t you’ll probably curse me. If you find yourself cursing me, re-read that.
  • List, List, List – Really, really, really know the product backlog. Know where the Product Owner wants to take the product. Get behind that. Give the team whatever they need to succeed and then get out of the way
  • Be debt free – Perform an HONEST Technical Debt assessment. Identify it, put together a plan to either abandon it, call it legacy (thereby putting in a plan to abandon it), or fix it. Before doing anything else, do something to prevent it from happening again. The best thing to do is the next item.
  • Invest in the team – People are your your greatest asset. Treat them fairly, hold them accountable, expect them to hold each other accountable. The best, and most important way to do this is to foster a safe haven environment, implement code reviews as a means of avoiding technical debt as well as a learning tool. Discourage/punish anyone/anything that violates the safe haven.
  • Get TDD – If your standard development practice does not include unit testing [which dovetails nicely with the SOLID principles], you’re missing out on the opportunity to take advantage of the benefits provided by the Single Responsibility Principle or the Liskov Substitution Principle. The idea is pretty simple, write the code once and then test it every time something changes.
  • Get CI – If you already have a Continuous Integration environment, props to you. If you don’t and are writing unit tests, don’t walk but rather run to get a jenkins or some other CI solution running. Chances are if you’ve embraced TDD and don’t have a CI solution, you’re leaving most of the value of TDD on the table.
  • Bigger is better – Make an honest assessment of the team’s communications. Look at the tools, protocols, frequency,etc. This is especially important for teams that are not colocated. If your team is relying on any type of asynchronous communication (email, IM, twitter, LCS, etc.) you’re penalizing yourself. Preferred modes of communication: 1) face to face 2) telephone or Skype 3) Instant messenger or twitter 4) Email 5) Snail Mail.
  • Embrace Legalism – Follow Scrum by the book for a while in order to figure out where it doesn’t work. When you find something that doesn’t work for you, try it again the original way, and if that still doesn’t work, keep trying until you are absolutely sure that there is no alternative. If you change something, consider yourself warned.
  • Evangelize – Put forward a concerted effort to gain product owner investment. If the person you identify as the Product Owner wants to delegate the responsibility, you have a sales job to do and will likely require some convincing to the “real” PO (not a proxy PO) in order to to take away the cya/escape hatch (aka finger pointing/plausible deniability) that business people are so accustomed to when dealing with software projects.
  • Be a mechanic – Inspect and adapt the technical/engineering practices in order to continue leveraging value. Think outside of the box and try new ways of investing in the skills of the team. For example, if you’ve never done it, try pair-programming for a couple of sprints to see if it helps or hinders the team’s performance.

Agile Project Management: What’s Up?

There is a great new site in town about Agile project management.

They are running a series of interview/guest posts on The State of Agile.

To my surprise, Peter from AgileScout.com reached out to me and asked me to be one of the interviewees.? It’s pretty amazing to be included in this list of Agile thinkers and practitioners!

The Questions:

  1. Your (author) background?
  2. How Agile has changed (from authors perspective) in terms of methods, philosophies, ideologies, pragmatic applications, etc.?
  3. Where is Agile going (in the future)?

Being of the contrary nature that I am, instead of responding with a blog post format I recorded a video with a mindmap on my whiteboard instead.

Click the image below to go to AgileScout.com and view the video.? Check out the rest of The State of Agile while you are there.

Tuesday 10/26 ? Tobias Mayer

Wednesday 10/27 ? Derek Huether

Thursday 10/28 ? Ken Schwaber

Friday 10/29 ? Josh Nankivel (Video!) and Sara Broca

Monday 11/1 ? Lisa Crispin

Tuesday 11/2 ? Mark Levison

Wednesday 11/3 ? Marcin Niebudek

Thursday 11/4 ? ?Matthias Marschall

Friday 11/5 ? Vincent D?Amico

Agile Project Manager Confessions, Pecha Kucha Style

What the heck is Pecha Kucha?

That’s what I asked the first time I heard about it too.

Check out this guest post from Dave Prior and find out, even if you’re scared of the sound of “Pecha Kucha”.? It’s actually kinda cool.? I’m looking forward to viewing the entries!

By Dave Prior, PMP, CST

Whenever I tell people that I am both a PMP and an Agilist, many look at me as if this had to be some deep, dark secret.

by by Anonymous9000 via Flickr

How could one study and practice a formal project management methodology and also use Agile?

The first time one of my coworkers and I went to go speak before a PMI Chapter about Agile, we were led to believe the audience may throw tomatoes. But a funny thing happened, not only was almost everyone receptive, but many people told me, “yeah, we’ve been using some of this for years!”.

Indeed, I have been surprised with the number of PMI members who have run Agile projects – perhaps not in name – under the radar of some large organization. This was very similar to some of may earliest experiences using Agile project? anagement.

by Anonymous9000 via Flickr

I recall when working with a large financial firm, we were told we have a very strict process if we were doing projects of over 400 hours. But if we were below that threshold, there was a much lighter process. You wouldn’t believe how many “396 hour” projects that team executed.

Working with the PMI Agile Community of Practice (CoP) has been a validating experience.? So many project managers are committed to the profession of project management and interested in using Agile practices to improve their craft. In fact, over the past year we within the virtual community have been thoroughly impressed with the number of people using Agile practices in spite of circumstances.

It is with that in mind that we would like to let you know you are not alone, and we want to hear from you. The Agile CoP is hosting an online video contest, “Confessions of an Agile Project Manager”.

Submit your own video in a Pecha Kucha format telling us your story.?? Perhaps it was a guerrilla project conducted quietly so as to deliver value without attracting too much attention, or maybe it was an organizational? transformation. Whatever your experience, we want to hear from you, the community, about your experiences using Agile.

by Anonymous9000 via Flickr

We will be asking the community to provide their stories and evaluate those that they like most. Most importantly, we will have cash prizes for the three best submissions!
Submissions can be made to the PMIAgile YouTube group.

– March 5th: Contest officially begins
– May 10th: Last day to submit videos
– May 17th: Last day to vote on videos
– 1st Place: $1000
– 2nd Place: $750
– 3rd Place: $500

Anyone is eligible to submit and vote on videos

Video Format
Submitted videos should be in formatted as pecha kucha presentations. This is a power point (or similar presentation capability) showing 20 slides that auto-advance every 20 seconds, for a video that is 6:40 in length. Videos that deviate from this format significantly, while impressing us with their creativity, will not be considered for the competition.

Chaos and SCRUM

Josh asked me to write about some of the challenges and obstacles that we face in our environment. In order to do that I should explain a little about that environment.

Over the past 36 months we have transformed ourselves from being a software development team in crisis to a strong team that is focused on delivering on it’s commitments. In 2005 we determined that the current approach to writing software wasn’t working. We were the poster child for “garage-band” style of software development, having inherited?1 million+ lines of classic (poorly written) ASP code [aka 1MLOC – I’ll let you guess what the “C” stands for], and having very little recognition from corporate management that anything was wrong with the way things had been done.

When I came to lead the group in early 2007, I had put in countless hours trying to lead the business toward? implementing a PMO. While we actively maintain the 1MLOC, we have been working closely with a third party partner to replace the application. In parallel, we have a number of other small LOB applications that we have written using accepted best practices and design patterns. Needless to say, this means that there is a significant amount of churn and chaos when it comes to determining what’s going to be worked on and by whom. Enter SCRUM.

In early 2008 I approached the IT leadership and explained that an iterative and incremental approach to developing software was far superior, in our environment, to the code-and-fix triage approach to project management that had been promoted in the past and that this would be well suited to supporting the behemoth 1MLOC application while still allowing us to be agile enough to respond to the business’ needs in a timely manner. They bit.

So, what is our environment like, how do we handle some of the obvious gotchas, and what are the advantages/disadvantages to how we do business? Well first, I’ll say that this is what works for us, in our environment. I can’t speak to your situation, although if I can help, please drop me a line. Well, we currently have over a dozen product backlogs that are somewhere in the development/grooming workflow. We have roughly half that many Product Owners [none have been “officially trained”, all have gone or are pending admission to the school of hard knocks] and the expectations of what it means to be a Product Owner are communicated loudly and often.

Some gravitate toward the role, others are a little thicker and require some additional coercion encouragement.

Regardless, we do the classic planning poker estimating that I described here and then, based upon our standing team velocity we let the Product Owner how much of the backlog we will be able to knock out during the next sprint. At that point, for any one of a couple reasons [the Product Owner needs more functionality than can be delivered in a single sprint/the team has some groundwork to lay in one sprint in order to deliver the key business deliverable in a second or third sprint/etc.], the team may decide that they need to deliver the next increment of work over several concurrent sprints.

In this case, the backlog of backlogs is queried and the next product owner is queried for budget and schedule requirements [we may even look at the current state of that PO’s product backlog] and a reasonable determination is made [by my boss and the IT Steering Committee] whether it’s acceptable to the business for the subsequent?development to:

  • be delayed
  • be preempted or
  • be split [deliver Sprint 1-Product A, then Sprint 1-Product B, then Sprint 2-Product B]

From the team’s point of view, this decision is somewhat irrelevant as long as the sprint backlog is ready to be loaded into the SCRUM Dashboard [which is integrated into the Microsoft Team Foundation Server – our source control and overall ALM solution]. Once the tasks are entered into the Scrum Dashboard (which is a lot like SCRUMY except that it’s tied to coding tasks, time tracking, check-ins, build events, etc.) the team tracks their own progress daily which automatically updates the Sprint Burndown, Product Burndown, BurnUp, and a hundred other reports that are hosted in the Microsoft SQL Server Reporting Services site that comes out of the box.

The daily stand-up meetings are usually run by the team, as the ScrumMaster?I sit in on them regularly; however, my prime directive is really just to make sure that they’re happening and that there are no discovered impediments that are/have not been communicated to me that come up as an outcome of the meetings. We have a weekly code review meeting for the whole team to see where we are, and we usually use this meeting to demonstrate the application state to the product owner. As part of our development team, we expect for the business to provide?testing and QA resources so that we can be sure that the feedback loops are as short as possible.

So, you ask, what are the gotchas in this environment? That’s an easy list to start, but a very difficult one to call complete…so here’s my “easy list”…the hard ones will quickly become evident in your environment.

  1. Training Product Owners – especially in a “Command and Control” environment, it’s difficult to convey the concept and importance of servant leadership. Similarly, it’s hard to get “busy” business folks to commit their time to things that are commonly deemed to be unproductive
  2. Training Product Owners- getting them to understand the concepts of story points, estimating, life without requirements documentation and use cases, life without earned value, and ultimately the fact that the ROI and the “fit for purpose” functionality is their #1 responsibility
  3. Death by meeting – herding all of those backlogs, training all of those Product Owners, daily stand-ups, retrospectives, code reviews, “demo days”, Planning Meetings, not to mention the other “normal” meetings that one usually gets pulled into [weekly staff meetings, employee meetings, annual reviews, etc, etc, etc]…leads to about 80% of your time being tied up in one meeting or another…it really is hard to do a lot more than manage your schedule and check your business card to make sure it matches your driver’s license
  4. Leadership & Management – if your management doesn’t back you up and get out of your way, you will be tripping over one another. They MUST support you and then get out of your way. The proof is in the pudding…deliver a few times and they’ll get it.
  5. Tools & Co-location – We are one team, in one location. We tried the distributed team thing for a while and, to be honest, the requirements for the team to be available to meet to review something on very short notice makes co-location extremely difficult. Likewise, much like there isn’t really a “SCRUMBOK” because SCRUM is prescriptive as far as Engineering Practices, there are hundreds [if not thousands] of electronic tools for the team to use…a definite gotcha is the temptation to jump into the midst of the tools arena before you really understand the process that needs to be supported by a tool. We found TFS and SCRUM Dashboard….it’s what works for us….that means squat to you….make your process work analog, and then digitize it….I can’t say this any more clearly…learn to love the whiteboard, post-it, and index cards…worry about the business now and worry about the rest later [it might actually take care of itself].

OK. So there’s a start. That list could go on for a while. So, to wrap up, you’re probably interested in understanding?what are some of the pros and cons?

  • PRO: We deliver working software, and we do it pretty frequently. This means that our Product Owners are pretty happy. Happy PO = Happy Business = Job Stability = Happy Employees = Better Software
  • PRO: We get to deliver at a sustainable pace and we LOVE what we do. I hope that the?death marches of 2006 are gone for good. We value people over process. Happy Employees = Better Software = More Projects = Job Stability = Happy Employees
  • PRO: We get to be honest and transparent. With the PO on the team, there are no secrets about something taking longer than planned, or something not working as expected. The PO and the team get to figure out how to work thorough these challenges rather than worrying about doing damage control.
  • CON: Estimating is really difficult, especially at first. Then, to make matters worse, budgeting is even more vague. For some organizations, this may be too much to overcome. I hate budgeting season…to ask me how much something is going to cost is to ask me for a complete and estimated product backlog, which isn’t terribly different than a preliminary project plan and schedule. Ugh. Budgeting Sucks.
  • CON: If you are a “Command and Control”, “Do first, ask questions later”, “take the bull by the horns” kind of manager, you will really struggle with Agile. The CORE of Agile is in empowering the team, transferring that control to them, and settling into a support role….for a lot of folks, this will be impossible.

Implementing SCRUM…the basics – part 2

implementing scrum part 2

via Flickr by drewgstephens

In this post, I explained that SCRUM is not a silver bullet and?that there some significant barriers to entry for organizations wanting to adopt SCRUM. In this post, I’m going to introduce Agile estimating, planning poker, fibonacci, and velocity.

Let’s say that your organization is ready to go, you’ve turned command and control on it’s ear, you’ve identified the Product Owner and you’re going to be the ScrumMaster. You’ve put together a team of seasoned developers, a creative designer, and a QA Lead, but the designer and QA Lead have never worked on an Agile project and they also have never worked with this team of developers.

Let’s say that the Product Owner has put together a pretty comprehensive list of User Stories [let’s say that for argument sake that these have been validated and prioritized and you have verified that they follow the INVEST principles…more on that in another blog post]. What now?

First, you need to work with the “Team” to make sure that they understand what their responsibilities are, this includes the talk about being a self-organizing team, that they’re responsible to one another, the?Product Owner,?and ultimately to the organization to do what they say they’re going to do.

The next step is for the SCRUM Team [that’s the development team, the Product Owner, and the ScrumMaster] to decide which items in the Product Backlog you’re going to deliver in the upcoming Sprint. In order to accomplish this, you need to be able to quantify how much time or effort each item on the Product Backlog will require.

This quantification of the Product Backlog is called estimation and is commonly accomplished?by having the development team play a game called Planning Poker.

Game playing? Man this SCRUM stuff is wierd. OK, let’s talk about Planning Poker.

The idea behind User Stories is to collect the requirements in bite-sized pieces. The size of those bites will inevitably vary. The Agile solution to this problem is to rate each User Story according to relative “size”.

The best analogy I’ve heard is to compare the stories to dog breed…compared to the other stories, if the current User Story a Toy?Chihuahua or a Great Dane? Where in the middle…Jack Russel Terrier? Labrador Retriever? Once each person?has an idea for the relative “size” of the item, each person has to play their hand, and the group consensus wins…highest and lowest have to explain why they think the feature is larger or smaller than the rest of the team.

When?I do this, as the ScrumMaster, I intentionally don’t play a hand because I don’t think I should influence the team’s collective insight into how big or small a feature is. To each their own. The planning poker deck we use was purchased from Mountain Goat Software and was well worth the few bucks it cost. There are online versions and of course with a pair of scissors, some index cards, some markers, and a little free time you can make your own.? The important part is that you understand the notion of the relative scale of accuracy and the variability that is introduced as a feature gets larger.

You’re probably familiar with the Fibonacci series of numbers. We use this series of numbers to incrementally scale the “size” of a feature. Why do this at all you ask? Well, if I ask you to estimate in inches, the distance from the tip of your index finger, where it currently is, to the tip of your nose, you will probably be able to estimate with?better than 85% accuracy. Now if I ask you to estimate using the same criteria the distance from the tip of your index finger to the middle of the letter “O” on the nearest Stop Sign [depending where you are right now] you might be able to estimate with a significantly smaller degree of accuracy, and finally if I ask you to estimate, in inches, the number of inches from the tip of your index finger to the tip of the Empire State Building in New York City, you are likely to have an accuracy approaching 0%.

With this in mind, we use the Fibonacci sequence because as a feature increases in size, our inherent ability to accurately estimate it’s size diminishes. After all of the items on the backlog are estimated, the next step is to determine the Sprint Backlog…the estimated subset of product features that will be addressed in the Sprint. We had a hard time understanding how much we could bite off in our first few sprints [in other works, how many “story points”…or Fibonacci values we could consistently complete in a sprint].

In order to get around this, we took two decisive steps.

First we committed to?micro (one week) sprints and second we intentionally rigged the sprint backlog with items that we knew were small enough to complete in a week, yet big enough to validate [one way or another] our estimates. This process allows us to determine our “velocity”. Velocity is the average rate at which a team can complete story points for a unit of time. Once we were able to determine out weekly velocity, we were able to extrapolate our bi-weekly velocity.

Once we were able to determine the velocity for a “normal” sprint, we have become increasingly confident in our ability to deliver on that velocity. I will put in a big caveat…the velocity statistic is only a general guide, and as you adopt SCRUM, the accuracy of the velocity is only as good as your ability to limit the variability of external change within the team. In other words, if you determine the velocity for a specific team, that velocity will be affected by making changes to the team, and even in some cases by changes that the team may make from within.

For more information on these topics, there is a great book on this topic written by Mike Cohn called “Agile Estimating & Planning“. I highly recommend it.

Three Ways to Stand Out as a Project Manager in Today’s Economy

Guest post by Erika Flora

With the current economic conditions, an increasing number of people are either afraid of losing their jobs or desperately searching for work. Just like it?s a buyer?s market for housing, it also seems to be a buyer?s market for employers. Those who are hiring can be extremely selective in whom they choose. That?s why smart Project Managers plan today for tomorrow?s ?what if.?? We need to be smart about managing our own career ?risks? and have a mitigation plan firmly in place now.? There are three simple, cheap, and super smart things you can start doing now to avoid any unneeded worry and panic if you do, in fact, find yourself looking for other career opportunities.

1. Invest in yourself. First, make time to invest in yourself. No more excuses! If you do not currently have your PMP? certification, now is the time. You don?t have to spend a lot of money. A PMP exam prep course can range from about $800 for a PMI? chapter sponsored course up to $3,000 for a professional training course. All told, your total required investment is small compared to the rewards (significantly better pay and more visibility as a job candidate). Further, if your current company pays for training, you really have no excuse; that?s a benefit you can?t afford to pass up. Nothing in life is guaranteed, and that includes the job you have today. Take the time to invest in your career now, so you do not end up having to scramble if things take a turn for the worse.

If you already have PMP certification, look into some advanced training that is complementary to project management. There are a number of niche areas that employers are starting to look for (i.e. Six Sigma, ITIL, CMMI, Agile/Scrum, etc.). There is a strong emphasis on ?doing more with less? these days, and employers are looking for people who can help improve how they run as a business.? Broaden your skills, and differentiate yourself by being a project manager who understands the world outside of just managing projects.

2. Create a buzz. Now is the time to start making a name for yourself! Start a course of action to position yourself as an expert in your field. One way to create a buzz is to write articles on what you know. You can do this a number of ways. First, try submitting articles to your local chapter of PMI or another local professional organization.? Groups like this are always looking for new content and will often be more than happy to publish your work in an online newsletter.

Another way to get your ideas out there is to start a blog (or even just start posting your thoughts on this site).? Also, WordPress,?offers free blogs that take only a few minutes to set up. You can write as often or as little as you like. Write about whatever you are passionate about, and you may be surprised at how many readers you end up with!

Consider joining a local Toastmasters club in your area. If you?re feeling adventurous, book a speaking engagement or two! This will provide you with credibility in your industry, and you will undoubtedly become a better speaker as a result. Plus, it?s a great way to meet influential people in your industry.

Demonstrating your communication skills, both written and verbal, is a good way to make you a better project manager and get the word out that you are an expert in your field. Start building your reputation by putting your thoughts and ideas out there.

3. Make a difference. If you are busy making a positive difference in this world, you will be rewarded.? Volunteer your time! If you are not doing so already, get involved as a volunteer with your local PMI chapter, or work with another non-profit organization in your area. By giving of your time and talents, you will likely find you get tremendous satisfaction in mentoring others around you. You will also strengthen your own skills and maybe even pick up a few new ones. It?s also another great way to meet good people in your area. I personally know a lot of people who have found wonderful new jobs as a result of becoming a volunteer.? Make a difference in the lives of others, and your life will positively benefit as well.

If you focus on developing these three areas, you will undoubtedly have an amazing road ahead of you, both personally and professionally, regardless of the ups and downs of our economy.

Erika Flora, PMP, ITIL Expert
Principal, Beyond20
[email protected]

Scrum Revisited: Video Edition

I’ve been crazy again about Scrum recently and wanted to share these great videos with you. ?All are entertaining and relatively short, and good for Scrum newbies.scrum_video


Scrum Basics

This is one of the best “intro to Scrum” video I’ve ever seen! ?The first minute is a little slow, but it gets better after that.

Agile Developement with Scrum: What they don’t tell you

This is a promo and very short.

A Day in the Life of a Scrum Team

Excellent snapshot to give you a feel for what this kind of team is all about!

Irrational Loss Aversion

Recent events allowed me to catch up on some reading and I found myself going through “Sway – The Irreresitable Pull of Irrational Behavior” by Ori and Rom Brafman. The book is a generally enjoyable light read, but it delved into one topic I found very fascinating: irrational loss aversion.

The authors first introduced the topic with a simple economic study, the impact the changing price of eggs had on sales. The researchers found that consumers were more sensitive to prices increasing than decreasing. The impact of a loss – in this case due to price increases – was 2.5 times more profound than the impact of a gain (Putler, 1992) . Quite simply, people do not rationally weight losses properly and as such this leads to irrational behavior.

This concept was then applied to numerous examples such as one of KLM’s premier captains flying his 747 down a foggy runway into another plane because he was facing a flight delay and didn’t yet have tower clearance or a financial adviser explaining how many of his clients are unwilling to sell a poor performing stocks once it is below the price they bought it at, even if the most likely outcome is that the given stock will continue to drop (Brafman, 2008). Individuals fear of REALIZING a loss that has already occurred causes them to take on additional risks that are not rational. Perhaps the best, example offered was the $20 bill auction conducted by professor Bazerman at Harvard. At the beginning of each semester he offers an auction for a $20 bill starting at $1. There is a twist; the 2nd highest bidder must honor their bid, but gets nothing. As the price moves closer to $20, two bidders will become locked into a bidding war as each person hopes to outbid the other, thereby avoiding the $20 loss. Professor Bazerman has indicated that the bidding has gone as high as $204. This idea of risking more to make up a loss is not uncommon. In your own life, think of the last time you were driving somewhere and were running late. Did you drive faster or more aggressively than you would normally?

While the authors did not explicitly apply this dynamic to large projects, I can certainly see how this dysfunction has played out in projects I’ve been on. In fact, it seems the nature of a traditional waterfall project would be quite prone to this irrational loss aversion. Imagine for a moment a project broken evenly into three major toll gates for requirements/design, construction and testing. Now imagine for a moment that the first phase is coming to a conclusion, but the design is not quite nailed down, or an extra week is required. Traditional project management would say that one would communicate the schedule slippage and move the date out. My own real-life experience has been that people will say, “we’ll just make up the time!”

One of my friends in QA has frequently pointed out that the nature of his job as a QA professional means that he’s “the last one to go and the first one to be cut” implying that that traditional projects generally run longer through their earlier phases, in turn placing extreme pressure on QA to make an original date. I would like to say that when I used to work on waterfall projects I was strong enough to resist this dynamic, but sadly I was not. On several occasions, the siren call of “making the date” lured me too close to the treacherous rocks that have shipwrecked many vessels.

Somewhere deep in our psyche is a fear of loss, and with the modern large-scale waterfall development projects we have put together a system for delivering projects that basically plays to this fear. Is it any wonder we see massive projects go way over budget and yet continue to go forward? Like the ambitious MBA student looking to avoid the $20 loss, there are too many examples of companies throwing good money after bad to avoid ending what has already become a disastrous project. One client I recently worked with had just concluded a massive, two and a half year project only to realize that the cost to maintain this newly developed product was so high it could never be sold at a profitable margin.

The iterative nature and value of frequently delivering production ready code certainly help to mitigate this dynamic in an Agile environment, but I would not pretend that the same pressures don’t exist. I know I have seen business executives simply assert, “we must get everything done by this date”, expecting the team to find a way. Just because one works in an iterative way, doesn’t mean we are really open to evaluating our progress and make adjustments. From a project management point of view, we can refer to the triple constraint and inquire what is the lowest priority: cost, schedule or scope? In the unfortunate case where project sponsors are not willing to entertain such a trade off, then one must move to a discussion about risk – or reduced quality – and how much the program is willing to take. The best course of action is to surface these subconscious tensions that may be playing out. While we may not want to be the bearers of bad news, it is far better to escalate an issue when people still have options than when it is too late to do anything. Also, if we accept people are inherently adverse to realizing a loss, the team may be much more willing to walk away from a small train wreck of a project, rather than a larger one they would be even more invested in. Unfortunately my experience has shown that the most likely, and worst, possible option is to shoulder the risk oneself and subscribe to the fallacy that it is our job as project managers to manage risks like this. Of course, now the stakes become higher as we continue to bid more and more for that $20 bill.

This entry was originally posted on BigVisible.com