Project Management

Big Change Up Front (BCUF)

From the Manifesting Business Agility Blog
This blog concerns itself with organizations moving to business agility—the quick realization of value predictably and sustainably, and with high quality. It includes all aspects of this—from the business stakeholders through ops and support. Topics will be far-reaching but will mostly discuss FLEX, Flow, Lean-Thinking, Lean-Management, Theory of Constraints, Systems Thinking, Test-First and Agile.

About this Blog


Recent Posts

Improving Scrum by Attending to Flow, not Merely Using It

The Difference Between Inspect and Adapt and Plan do Study Act (PDSA)

Random thoughts about Scrum Guide Based Scrum

The Iron Triangle Constraints Are Misleading

Why to Focus on Flow of Value and Not Iterations

Originally published 1/1/2011. I have some additional information at the end to bring it up to date.

Throughout the Agile movement, one acronym that has been used in a derogatory way has been BDUF (Big Design Up Front). The problem with BDUF is that we are laying out our entire plan when we know the least about our actual product. Agile is about doing a little, learning, doing some more, learning some more. It is about being incremental and iterative in our discovery, creation and learning.

The irony of Agile's (currently) most popular method, Scrum, using something comparable to BDUF hit me this morning in responding to a discussion on a user group regarding Scrum roles. The challenge was that the roles of ScrumMaster and Product Owner are pre-defined for Scrum teams. For those that don't have either true teams or these roles, one has to make a Big Change Up Front (BCUF) to start Scrum.

This is not necessarily bad. It presents both opportunities and challenges. But the risk of using pre-determined roles is somewhat overlooked - and it is dangerous to do so. For some, BCUF is wonderful. Creating a team alone solves many of the problems being faced. But for others, this change can be traumatic and can have dire consequences. Which way it goes depends considerably on who is requesting the change and the maturity of the people involved.

I find it odd that we denigrate BDUF while not even questioning whether BCUF is good. David Anderson created Kanban to avoid BCUF. Odd that Kanban has often been attacked as not good because it's "evolutionary" instead of "revolutionary." I have long contended that an "evolutionary" approach to change is "revolutionary." 

The Lean/Kanban alternative is to first understand your current process and to gradually change it. You do this by creating visibility into it using a Kanban board which represents the value stream. You discuss your policies to make them explicit. You manage your work in progress to do step by step improvements to your work flow.

I am not suggesting that BCUF is always bad. There are times I've used it when there is a well identified problem with a clear solution and almost universal buy-in. However, not looking at whether a BCUF approach should be taken is dangerous. It's one of my complaints about consultants who have only one tool in their arsenal and why at Net Objectives we have several (Lean, Kanban, Scrumban, Scrum, hybrids even).

BCUF can be expanded beyond the team. It is common practice when adopting Agile methods to do a pilot project. But this is also a kind of BCUF. We assume that the change here (at the pilot) is the correct thing to do without understanding the nature of our true challenge. See How Successful Pilots Often Actually Hurt an Organization (blog and 4 minute video).

To me, the question is never if something is bad, but rather when is something bad. This creates more learning. So, next time you start an Agile transition at the team or organizational level, ask yourself, is BCUF appropriate here?

Bringing this blog up to date. 

A few years after this blog was written, the Disciplined Agile approach came into existence. It suggests that we need to look at the current situations companies are in. This includes their culture and what the best approach for the organization at hand​ is. This means not only to choose your way of working but to choose the way of implementing change. 

One could also argue that always doing small change up front is also a problem. Sometimes started starting with a big change is what it takes to ensure the change will stick. Again, one has to have both a flexible approach and not insist on predetermined methods just because it's easier to train consultants to do this. 

Posted on: February 19, 2020 10:11 PM | Permalink

Comments (11)

Please login or join to subscribe to this item
Dear Al
Interesting your perspective on the topic: "Big Change Up Front (BCUF)"

Thanks for sharing

As I understand it (correct me if I'm wrong) BCUF is a predictive approach to the life cycle of projects

This approach is contradictory to adaptive (agile) approaches

The link you shared is not working

Thanks, Al. It is vitally important to meet people and teams where they are to understand where to go and how to get there. Dropping individuals into new roles and/or a new paradigm of execution and expecting immediate results is impractical. That said, it is quite amazing to watch the magic happen.

Dear AI

Thanks for sharing your point of view. Changes are always problematic, and should exist a period of adaptation and evangelization. However all gurus that i know of Scrum never advised to use BDUF. The strategy would always be to start the transformation into a company by a small team where the most open mindset was detected to maximize the probability of success. Using these cases to prove that it was possible to implement scrum with success, and with that, spread the framework slowly throughout the company.


luis. fixed the link.thanks.

At the team level, Scrum itself is a BCUF. And many many companies say they are going Scrum with a pilot project (see link).
Your gurus must be good. I have seen many (most even) Scrum evangelists try to role Scrum out across an organization.

I think you'll find the linked post (fixed the link) useful.


The gurus are not mine, but are people of reference in scrum as in every professional areas, like you in FLEX.
I am a humble follower of very few people and only ask some questions from time to time.


all i know is that i've gone into many companies where they have all of their teams do Scrum training right up front. This means a shift to roles that may or may not work. And usually, for the companies I know that have done this, the real problem is poor intake and lack of using MBIs. And too many Srum consultants are willing to just schedule the workshops.

The point is not whether you should do BCUF or SCUF but what is the right change level for the company involved.

thanks for the engagement.

Dear Al,

One way of look at BCUF is that the project manager does not have clear and defined requirements and objectives from the start and as a result is implementing the project in a piece meal fashion. Implementing a project in a stop/start fashion is expensive, time consuming and wasteful.

The question the project managers needs to ask before starting a project and deciding on a methodology is, Do I commit a considerable amount of time engaging with all key skakeholders, client and the target market/audience to define in detail the product/service that I want to develop OR do I start small, build something, test it and see if this is what the client is looking for and at the end of the development process put all the pieces together, hope that the incremental products development process pieces all fit together and then test it on the target audience/market.

The answer would depend on what it is you are developing. If its an infrastructure project then you would have a clear and detailed plan before you even turn a sod. If you are developing and app for a mobile device, have a "good idea" but not sure that it will work or take off then a incremental methodology with a lot of revision and change will probably be your choosen methodology.

I think in this world of change and revision people want to hit the ground running, to be seen to be doing something and producing something quickly and regularly instead of clients giving project manager the necessary amount of time to do their job and manage the project. This fact is overlooked by clients, in that project managers manage the project and are hired by clients to act on their behalf.


Nice thoughts Daire.

Dear Al
I was reading the article you shared and the video


Its assumption is that the organization is functional

It changes everything in my interpretation of what you write, the pilot team, the use of PDCA and SDCA

Luis - great thought. While the example I gave was of a dysfunctional organization, I would suggest whether you do big or small change up front is based on other factors as well.

This is worth a blog - what are the factors that would suggest a big change? How would you go about it?

Please Login/Register to leave a comment.


"Nobody can be exactly like me. Even I have trouble doing it."

- Tallulah Bankhead



Vendor Events

See all Vendor Events