Death of #Agile #PMOT

OK, so maybe Agile isn’t dead yet. But I think it is certainly starting to suffer from the same disease that ultimately claimed Waterfall and other methodologies. As usual, Steve Jobs saw the issues years ago:

Content over process

Process over Content

Once the focus is on process over content, the patient starts to decline. Process is supposed to improve content by providing guidance and predictability. But if the process is followed blindly and no autonomy is given to team members to customize process, we have placed Process over Content. This happened late in the Waterfall days with additional focus on CMMI ranking and achieving other process certifications.

Most troubling is a lot of the discussion is the Agile world lately is about process and not content. We are talking about who is more Agile than whom. We are talking about absolutes as to how estimating is bad and that estimates should NEVER be done. We are talking about absolutes rather than compromises. You are ignoring Content when discussions gravitate toward absolutes. Is it a key indicator that you are no longer evaluating what needs to be accomplished or what value is. The discussion now is darn it, come hell of high water, we will be doing User Stories, with relative estimating, or not estimating at all. And it doesn’t matter what the clients think or what success is.

I know this because people are writing books about absolutes and not about how to compromise.

But Terry, we do listen to our clients you’ll say. We wouldn’t be doing our professional duty if we didn’t promote our preferred approach. We then customize after.

Fair enough. But your preferred approach is all about process and not content. Process enables content, but process is not content. Your focus is on the process….

I’ll let that sink in…



My #Agile Breakup

So it has been 11 months now since I’ve seen Agile. How has it been? To be honest, I haven’t missed her. I really haven’t. What has been made clear is what Agile is and what she isn’t.

First Date

I guess Agile and I started dating in 2006. We both were interested in each other and then I was able to arrange for Yves Hanoulle to be the keynote at the Software Development and Evolution Conference I was helping to organize in 2011. Yves had a great presentation on the Agile Mindset that was brilliant. I must admit I only realized how brilliant in the last few months. I think I did what many people have done when they encounter an attractive person coming out of a bad relationship. I moved too fast and fell too hard after being with Waterfall for too long.

The Agile I met was a collection of interesting, valuable methods. There was the concept of the Agile Mindset that Yves and others were promoting with wisdom. But I fell into the same trap as many others. I was going to propose to Agile and she would be the only methodology for me. All projects would be Agile. If clients didn’t like my new girlfriend, then they could go elsewhere.

Agile was a Methodology. I was sure of it. I would exclude using all other methodologies while Agile and I were serious. I would create an Agile Methodology by combining methods and practices. I would read and author Agile papers and presentations where we routinely challenged and chastised each other for not being ‘Agile enough’. I looked for the Agile complement for all waterfall or traditional methods. No matter the project, I promoted the Agile method.

For those of you keeping score at home, the PMBOK isn’t a methodology as well. Similar to Agile, it is a listing of processes, procedures, and knowledge that can be applied. But it is not prescriptive and does not provide governance on how to apply the methods and practices. Many companies take the PMBOK components and create their own methodology from it though.

But what about Scrum you ask? I’d say Scrum is an incomplete methodology. Although it does provide a methodology for the iterations on a project, it does lack guidance and governance in relations to the business case and pre-project intake process. Scrum also lacks guidance for the larger portfolio and enterprise governance concerns.

My Agile Mindset

My mistake was trying to take a collection of methods and assume a methodology exists. A larger mistake was then losing my Agile Mindset of constantly questioning the Agile methodology for value. That is my biggest complaint about Agile now. Many proponents seem to have lost the Agile Mindset of constantly questioning the best method to use on each project. Everyone is just promoting more and more ‘Agile’ methods without confirming that the method returns the most value for the clients. See the No Estimates discussion for this. To blindly promote no estimates for all clients does not represent an Agile Mindset.

I was going to say I’m just as Agile now and I was before, but that statement shows a non-Agile mindset – Agile is not a methodology to achieve. Let’s just say, I feel my projects achieve the maximum amount of value for client by using the Prince2 Methodology using Agile methods and practices were appropriate. Everyone I’ve worked with sees the value in Agile methods and are eager to work with them. The concept that you have to buy the entire Agile Methodology to use an Agile practice is misguided.

I mention Prince2 because that is what we use at the University of Manitoba. You could replace it with whatever you use at your company and then search where you could use Agile methods to return more value. The more I use Prince2, the most I think it is one of the best methodologies I have used though. Highly recommended.

Use an Agile Mindset, Agile isn’t about the Methodology it is about getting better little by little.


#NoEstimates motivations

I thought it would to be interesting to discuss the motivations behind No Estimates rather than the argument as to whether they are required or not. The motivations due go some insight into why they are being provided as an option after all. As I see it there seem to be three primary motivations behind No Estimates:

We don’t want to be wrong

IT professionals are first and foremost caring people who honestly don’t want to let people down and have to inform them that they were mistaken. In this case, it is much easier to not have to give them an estimates which we know is probably wrong. No one ever likes to have the meetings where we need to request weeks of additional effort and thousands of additional budget. The business may think that IT doesn’t care as the dollars are not from the IT budget, but IT really does take these overages seriously and hate to make these requests.

We feel that estimating itself is a waste of time and effort

We also have been on projects where estimating has gone horribly wrong and estimates were way too detailed. Excessive time was spent on estimates in the thought that additional analysis would result in more detailed estimates and a better project plan. IT has learned that estimates should be less detailed, but still those memories seem hard to forget.

We feel bad estimates will led to bad projects and poor quality

Finally, we feel that once given, estimates will be imprinted on the clients and everything else will be sacrificed in order to abide by the estimates. Weekends, personal time, quality, documentation, everything will be sacrificed so we can meet the vastly inaccurate estimate provided at the start of the project when we knew so little.

Let us agree

So let us first agree that all these reasons are valid and noble reasons. We may disagree whether Estimates are valid, but I doubt believe there can be any disagreement that the motivations behind the No Estimate movement are true and valid.

Confessions of an #Agilist – Agile is dead #Pasunashi

Businessman at fork of stone pathway in water

So I’ve recently taken a job as the Manager of a Project Management Office, and I have a confession to make:

Agile is dead. I’ve seen the body.

All about perspective

When you are on the receiving end of funding, Agile makes perfect sense as it is optimizing the individual project. I give 10 projects $200K and they will deliver the best value they can individually. no problem.

But when I am on the sending end of funding, did I select the right projects? How do I decide which ones to select? If two fail, then what does that do to the company’s bottom line? Could I have used those people on more important projects? How do I justify how I selected the projects?

The Good News

The good news is certain things from how Agile lived his life has been incorporated. Iterative planning and execution is alive and well, as is User Story Mapping, and automated testing, and specification by example. A lot of the Agile practices have had a profound impact on the Software Development methods used. In some places, even Pair Programming is alive and well.

The Bad News

Sadly, the entire patient could not be saved. Now this is for a corporate environment and one that has more freedom than most corporate environments.

No Estimates is dead, Pure flow is dead, no design is dead.

Why? Predictability is king. There needs to be some business case for every project. it doesn’t have to be extremely detailed, but some analysis and design needs to be done. Some recommendation needs to exist for what the solution will look like and what the potential costs and benefits would be.


See the point isn’t about doing the project right, it is about doing the right projects. Any practice that doesn’t help us to pick the right project isn’t Agile, it is PasunashiPasunashi is Japanese for ‘Without Path’.

Selecting projects without a path and executing them without a path is not something I feel comfortable recommending.

But really Agile is not dead because once we pick the right projects, we can do them in an Agile manner and according to “Pasu ika” – Following the Path…




Would you like fries with your McApplication? #NoEstimates

There is a great difference between a fine meal and McMeal. The fine meal typically has been crafted with years of experience and training by chefs around the world. The McMeal is put together with years of experience based on what people want at 1:30 am in a drive-thru. The fine meal also places forethought as to how the components work together and play off of each other. With McMeals and other fast food meals, you are left to your own devices as to what you would like combine together at the last possibly moment.

Software Development

Similarly, Software Development can create solutions on which great experience and effort is expended determining how the components fit together or we can slap the functionality together for a McApplication. Agile can and has been guilty of creating too many McApplications over the years.

User Story Mapping

User Story Mapping is a great tool, but unless it is followed up by some analysis and design work to architect the solution, we are just visually drawing the new McApplication. While the concepts of delivering in iterations and visually planning the iterations is extremely valuable, jumping into delivering without architecting the overall solution is misguided and sub-optimizing.

If your first project work is cutting code after you have created a User Story Map, you are well on your way to creating the next McApplication.

We always need to remember we are professionals committed to creating, designing, and delivering the best solution to a business problem, Sometimes this may involve providing counsel to clients on why some stories should not be done, why some stories should be done later, why some stories need to be done now, and why some stories that they haven’t thought of need to be added.

Client priority rules the day of course, but if we just do what the client identifies without providing our expertise, we are no longer professionals. We are just order takers.

To avoid being just order takers we usually need to do some detailed analysis on what a story means and how it needs to be implemented. Just capturing the highest ‘placeholders’ to discuss functionality means you are creating your architecture as you go along. Yipes.


Which brings us to #NoEstimates.

No Estimates does not focus on creating a better solution. No Estimates has been created so that the project can be forecasted. It proposes nothing to help create a better solution to a problem. Even worse, when No Estimates is followed to the letter, it can even absolve the team of project leadership duties.

No Estimates proposes that we will just work on what the client wants, when the clients wants it and we will stop when the client wants to. It overlooks a key responsibility of project teams to save the client from themselves with our experience and expertise. Agile sometimes seem to shy away from tough discussions that should happen early on projects. Some projects should never start.

Agile proponents forget that not only should code to tested early and often, but incorrect client concepts should also be. If we are taking direction on a client priority that we know is wrong and will result in a lesser solution, and we haven’t done everything we can to change their mind, then we are not Agile.

No Estimates proponents will probably state that all those things should be done on a project in addition to No Estimates, but by not putting design and architecture front and centre it is clear they primarily value forecasting.

Due to this, the type of solution you will get out of a No Estimates projects will probably be a McApplication rather than a fine meal and you’ll probably be hungry for a new solution before long.

Solution Leadership and healthy adversarial discussions over difference in opinions is not valued highly on No Estimates projects. The focus is on  forecasting and doing whatever the client want to do next….

Would you like Fries with that?




Are #NoEstimates #UnCanadian ?


Yep, I’ve come to realize that part of my trouble to rationalize the No Estimates movement is that they are UnCanadian. There are some things that become a part of you when you live and Canada and especially in the Canadian Prairies. Let me explain.


As Canadians in the middle of the continent, schedules define our lives. It snows in late October and is bitterly cold December, January, February, and March. If I didn’t have a schedule that let me know spring will arrive in late March I am sure I would go crazy. In many ways, a schedule is the only thing holding our psyche together when we are shoveling 30 centimetres of snow with a windchill of -40. Like how can it possibly snow when it is that cold? We as a nation as obsessed with weather forecasts. If Meteorologists turned up tomorrow and said they were not forecasting anymore beyond today, I would go to some dark, dank corner of my mind in February.

I need a schedule. I need it to give me hope. 🙂


When you live in a country this vast, a map is a requirement. Trust me, the last thing you want to do is get caught in some small town with out a Tim Hortons in the middle of winter. So as a consequence, I have this inherent need to know where I am in relation to where I thought I would be. In all seriousness, getting caught in the middle of winter not making your destination is a matter of life and death. Getting caught out in the elements will get you killed. More than anything we respect the power of nature.

So I think this Canadian life has ingrained on me that I need a map of the projects I work on. I need it to guide me and in some very real way, I feel lost and vulnerable without it.


Canada is not a Soccer nation. Never will be. Oh sure we have some very talented players now coming up and we will continue to get better, but Soccer will never enthrall this nation like Hockey. Why? I’d hazard a guess is because part of the charm of Hockey is the combination of the skill, tenacity, and toughness. Hockey is the only sport that has a ‘diving’ penalty – where it is a penalty if you are trying to fake an infraction. Yes, I know that Soccer now has a ‘simulation’ penalty, but if you can’t even label the penalty as something shameful, how committed are you to changing the behaviour?

To be blunt, adopting No Estimates because estimates are hard to do and error prone, seems to be like falling down in the penalty area just to get a free kick. Yes, it might be easier and make projects go smoother for developers, but is it right?

No thanks. I’ll carry on, drink my Tim Hortons, fight through tackles and get better at estimating. I’d rather lose the right way than win on a penalty kick.

Why I hate and love #noestimates

I was watching a No Estimates video that someone tweeted recently and I was reminded why I hate and love No Estimates at the same time. The video in question is a No Estimates presentation by Allen Holub. You can find the video here.

I’d like to review the key points of the presentation and discuss the split personality of No Estimates.

0:20 – “We need to stop doing all estimates, now” – As much as some No Estimate proponents say it isn’t about not doing estimates at all, these extreme statements arise again and again. There much be some kernel of truth that they truly believe in this statement. It seems only when no options are available do they concede that you could do estimates if needed.

0:25 – “Estimation has no value at all” – Not your call. The only person that defines value is the client. If the client determines estimates have value, then the estimates have value.

1:01 – “Estimates are always wrong” – Not true. Many estimates are correct. In fact, I’ve had more correct estimates than incorrect estimates in my career.

2:12 – “Estimation leads to dysfunction. Estimation leads to working endless hours without needing to” – This is just bad leadership. Trust me, if you didn’t provide estimates these bad leaders would find other ways to set up a toxic environment. This is not the fault of estimates.

2:55 – “As soon as you have estimates you can’t have a sustainable pace” – Again bad leadership. Estimates are made to evolve and change. Just like other aspects of Agile, our estimates also need to have short feedback loops so we learn from estimates and then modify the future estimates for the project. It is curious how No Estimates proponents are well versed in Agile, but can only envision doing estimation in a waterfall method. It seems like estimates were the only item on their Agile projects that weren’t Agile. If they considered estimation with short feedback loops, I can imagine they would be less adverse to estimates.

3:06 – “As soon as you have deadlines you have people working 18 hour days” – See bad leadership mentioned above. If this is your environment, don’t blame the estimates. There are much deeper problems.

3:23 – “Your boss asks you how long something will take and you have no idea how long it will take, so you make a wild ass guess” – Really? If you have 3-5 years experience and have no idea how long something will take, you might want to find another career. Now there are some components that if you haven’t done before, you really may not know. But for the most part we are building things where we have some experience building similar items in the past. (I exclude from this Research and Development projects. I have been on these and understand they can’t be estimated easily. But those projects are not common.)

5:00 – “People don’t understand how estimates work” – This I agree with. It does take a lot of effort and communication to manage expectations.

6:12 – “CHAOS Report – Projects are late 80% of the time because of bad estimates” – Incorrect and oversimplification. I have been on projects where we were late but that was caused by people leaving, client needs changing, scope creep, and many other factors.

I really do like some of what Allen says in regards to Velocity, but it seems that Allen doesn’t even want to commit to a steady team velocity if nothing changes. In a sense, Allen proposes committing to nothing.

13:29 – “Estimating Software is like estimating Physics – How long will it take to create a Warp Drive” – This is a ill conceived argument. If you are creating something that hasn’t been done before, I agree you can’t estimate it. 95% of all Software Development is a variation on existing patterns and you can estimate it. Not perfectly, but adequately.

14:46 – “There is a disconnect from the people on the team. The catcher is disengaged and need to be engaged” – Again another bad analogy. The catcher and batter are not on the same team. So no, the catcher doesn’t not need to be engaged with the batter’s ritual. The pitcher’s ritual yes. This analogy is just totally incorrect and as a result, is not compelling at all.

15:15 – “There is no difference is estimating and locking your door 7 times” – I hear this from No Estimates proponents now and then. Comparing estimating to known Psychological disorders is dangerous, insensitive, and unprofessional.

15:50 – “Instead of a year long project, how about a month long project?” – Now we get into the part of No Estimates that I love! Enough about bashing estimation. Let’s talk about how we should shorten the feedback loops and minimize inventory. I would propose that we can also do this when we estimate. It just takes good leadership and management of expectations.

19:09 – “Mentally Deranged” – This is similar to my comment earlier about comparing estimating to true Psychological Disorders. This is just unprofessional and terribly insensitive.

21:32 – “The Business decides what to build and you decide how long it will take” – Agree 100%. Most of the previous bad examples seem to propose environments where the managers determine the estimates. I have never been on a project like that. Every project I have been on has empowered the developers with creating their own estimates. So we have taken 21:32 to get to how estimating can work. OK

22:35 – “Managers just manage schedule” – Great managers and leaders spend less than 10% of their time managing a schedule. The vast majority is working issues and helping to remove roadblocks for the team. Again the concept of manager is the Waterfall manager instead of the Agile Servant Leader manager.

23:25 – Never mind previous point. 🙂

24:27 – “Waste is whatever does not put valuable Software into the client’s hands” – Allen changes the definition of waste here to suit his point. Waste is whatever doesn’t provide value, not valuable software. Estimates may still provide value to the client even if it doesn’t create software.

25:48 – “estimates don’t help, because you don’t know you in trouble until later in the project” – Huh? If I have estimates I will get feedback very quickly on whether we are in trouble. Again, this seems to imply a waterfall approach where you are not running iterations that you learn from every week.

30:04 – “counting stories is enough, we don’t need to estimate” – Allen’s point is we only need to make two decisions. Either we kill the projects because the end date is too far out or we can add people. That assumes the only criteria is date. He ignores the fact that the cost of the project may need to be known to ensure it makes money for the company. Killing the project wastes money already spent, adding people increases the cost of the project. As usual, No Estimates is ignoring the need for budgetary decisions.

34:00 – “User Story Map is not a static document” – exactly like estimates. Both are not static documents and they change all the time. But it takes effort and expertise to manage that change.


As you can see, I disagree with much of the presentation. I align myself with the concepts and principles of No Inventory that you find in No Estimates. I believe that No Inventory is crucial to successful Agile Projects.

The No Commitment and No External Empathy part of No Estimates I patently don’t agree with. Can estimates have adverse effects? Absolutely. But we need to manage those and appreciate why estimates help others in the business and managerial roles. Software Development Projects are there to make the corporation more money. We need to be careful to balance what makes sense from a Software Development point of view with what makes sense from a business point of view.






Top three reasons why #NoEstimates is not a professional Software Development approach #Agile

In a recent post, I stated that some aspects of the #NoEstimates approach is not yet a professional Software Development approach. I believe it could become a professional Software Development approach, but it isn’t one yet. Some people raised an eyebrow to this statement and rightfully so. When you drop a bombshell like that you certainly should provide rationale and criteria as to how you ended up with that opinion.

Remember that this is also just my opinion, so do with it what you will. 🙂


Here we go!

1. The proposal and hypothesis should be clear, concise, and consistent

God help me, I really do have problem with knowing what #NoEstimates is proposing. Sometimes it is not doing any estimates – but do then again do them if you need to. Sometimes it is just working on a prioritized backlog and delivering in an incremental way delivering the highest priority items first. I find this ambiguity hurts the #NoEstimates cause more than it helps. If you believe in something, propose exactly what it is and stick to it. A lot of times we really don’t know what you are proposing that we should do. If you firmly  believe no one should do estimates, then say that and stick to it.

2. Don’t just criticize alternative theories

All the great ideas over time were able to stand up without criticizing alternative theories. Einstein never got on a soapbox and criticized Newtonian Physics. He simply proposed a new theory and illustrated why it described reality in a better way. The #NoEstimates proponents are actually hurting the acceptance by calling other methods ‘insane’ and ‘crazy’. It is almost the equivalent of swearing. Swearing is the easy way out of rationally describing your position to convince others of how it is a superior approach. To be clear, I don’t believe that a big-bang waterfall approach is better than Agile. But calling it ‘insane’ is intellectually lazy. I should be able to easily prove that to you. (and I can) Sometimes the discussions seem to resemble political attack ads more than anything else.

3. The facts should be available for peer review

Many times in discussions with #NoEstimates proponents I have seen opponents ask for the established companies that are using the extreme #NoEstimates processes of not estimating at all. Each time I usually get the response that they are soon going to interview them soon and would publish the results. I still haven’t seen any numbers published from companies that don’t estimate at all. So it is very difficult to validate the claims and whether the process would work in other situations.


In addition to these three characteristics, the inherent value of an approach is how wide the applicability is in the real world. If an approach is only viable in a controlled lab environment, then the approach is of not much use in the wild. For my money, an approach that is only applicable in a product company addressing only a very small share of the Software Development industry.

It probably is controversial, but the #NoEstimates movement has not yet demonstrated the widespread applicability in the Software Development Industry.

My Emotional #NoEstimates post

I’ve had multiple posts in the past where I’ve stated in very logical reasons why I believe in estimates. I’ve been thinking of penning an emotional #NoEstimates post lately. This is it.


Recently a close family member underwent major abdominal surgery. As the surgeon said, all abdominal surgery is major. Things went exceptionally well due to the world-class surgeon and tough patient.

But there were two aspects of the event that were very interesting to me from a Software Development point of view:


Yep, the surgeon provided estimates. Not just to me, but to everyone participating in the operation. You see, he was using a lot of shared resources that need to be co-ordinated across multiple surgeons and departments. You can’t just operate and then try to plan the next surgery after it is complete. There would be too much down time with critical health care resources. So all the procedures are estimated and scheduled on a priority basis to make the best use of scarce resources.


The surgeon’s report was the other eye-opening experience. For all your Software Development professionals that think no other industry is as complicated at Software Development and therefore it is difficult to estimate, I recommend reading a surgeon’s report.

Every minute, there is a surgeon operating somewhere not knowing what he is going to find when he or she opens up a patient. And through their skill and tenacity they estimate the procedures and then do their work in the best interests of their patients no matter what the original estimate was. Just like in Software Development, it isn’t acceptable to not provide an estimate on the procedure. I’m not sure we would have chosen the surgeon if he stated he didn’t know how long the surgery would have taken.

The Emotional #NoEstimates part

We as Software Development professionals need to get over ourselves and lack of professionalism in thinking our industry is unique and we shouldn’t need to provide estimates. Do estimates have negative aspects? Yes, but it is our duty to handle those negative aspects and work with estimates. We need to be brave to offer our commitment and then work with our teams when those commitments may not be able to be met.

When were discussing the surgery, it was dicey as to if it could be done at all. The surgeon looked us in the eye, said that he was confident that he could be done and provided an estimate about the procedure and recovery. From that point on we were one team focused on the procedure and recovery. And when the surgery or recovery went longer we discussed the reasons together.

If we as Software Development professionals don’t provide estimates, I don’t believe we are being true teammates with clients. We are asking more from them than we are willing to give.

For it to be a true #NoEstimates partnership, we don’t need to provide estimates but would only get paid when a feature is implemented in production. If we don’t need to commit to the client, they should not need to commit to us until they want to buy the product. Equal risk for client and Software Developers…

Now how many #NoEstimates proponents would sign up for that?


Drunken Sailor #Agile

Recently I was reading about the immense operations the D-Day landings on Normandy were. I believe I had heard that it took over a year or planning just for the event itself. This included many practices and mock invasions.

Here are some numbers, courtesy of

“On D-Day, the Allies landed around 156,000 troops in Normandy. The American forces landed numbered 73,000: 23,250 on Utah Beach, 34,250 on Omaha Beach, and 15,500 airborne troops. In the British and Canadian sector, 83,115 troops were landed (61,715 of them British): 24,970 on Gold Beach, 21,400 on Juno Beach, 28,845 on Sword Beach, and 7900 airborne troops.

11,590 aircraft were available to support the landings. On D-Day, Allied aircraft flew 14,674 sorties, and 127 were lost.

In the airborne landings on both flanks of the beaches, 2,395 aircraft and 867 gliders of the RAF and USAAF were used on D-Day.

Operation Neptune involved huge naval forces, including 6,939 vessels: 1,213 naval combat ships, 4,126 landing ships and landing craft, 736 ancillary craft and 864 merchant vessels. Some 195,700 personnel were assigned to Operation Neptune: 52,889 US, 112,824 British, and 4,988 from other Allied countries.

By the end of 11 June (D + 5), 326,547 troops, 54,186 vehicles and 104,428 tons of supplies had been landed on the beaches.”

Could Agile be used for a project this size?

The question that went through my mind is whether projects can be too large for Agile?

I would say some project characteristics make the project less suited for Agile, but it isn’t just about size. In fact, the two factors that can make a project suitable for Agile don’t involve size at all.

Perhaps two definitions would help. When I am referring to Agile, I am believe there are two main types of Agile:

Drunken Sailor Agile – This is where there is an un-estimated backlog of user stories and the stories are pulled from the backlog just in time for the next iteration. These projects may not have an overall budget. Frequently these Agile projects align their processes with Flow. This is where No Estimates methods and practices are used.

Budgeted Agile – This is where there is an initially estimated backlog of user stories and a budget for the overall project. It most cases the project also has a tentative schedule on what is expected when during the project. These projects are typically done by large enterprises and companies focused on being profitable.

The Two Factors

1) End Product negotiable – Drunken Sailor Agile works really well when the end product is negotiable or unknown. In those situations, the ability of Drunken Sailor Agile to pivot returns great value. But when the Minimum Viable Product doesn’t differ greatly from the Maximum Viable Product, the ability to Pivot returns less value. Capturing half the beaches on D-Day wasn’t acceptable. It really was an all or nothing value proposition.

2) Predictability/Co-ordination – Drunken Sailor Agile struggles to provide any level of predictability and co-ordination. If you require predictability, you really do need to use Budget Agile with a schedule. In many cases this predictability may not be about when the project is complete. Frequently the solution is so complex and intricate that dependencies between components requires much more predictability that Drunken Sailor Agile provides. The amount of co-ordination required on D-Day would prevent Drunken Sailor Agile from being used. Ships and Aircraft needed to be exactly where they said they would be.


As you may have surmised, I am not a hug fan of Drunken Sailor Agile. And I think the projects that it can be applied to are quite limited. I don’t think it can work on large projects.

More importantly, I don’t like Drunken Sailor Agile as I think it creates an “Us versus them” atmosphere. We seem to be scared to tell clients when we will be done in case we are wrong. It all comes down to trust and Drunken Sailor Agile seems like we want to be trusted without providing our trust that estimates and schedules will be treated fairly.

I’m still in awe of the co-ordination and trust required for the D-Day operations. Agile has a way to go before we can approach those levels.