Big Change Up Front (BCUF)

January 1, 2011 — Posted by Al Shalloway

Throughout the Agile movement, one acronym that has been used in a derogatory way has been BDUF (Big Design Up Front). Essentially BDUF is when, at the start of a project (up front-UF), we do a big design (BD). 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 issue 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." J

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.

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?

Author: 

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.


Comments

Nice post, Alan. I really like the balanced/contextual treatment of BDUF/BCUF. (Note: BCUF is BDUF when you view the process as the object of design.)

I couldn't get the How Successful Pilots ... link to work (same problem when you posted it on leandevelopment). Also, did you really mean to say that Kanban is attacked because it is "evolutionary"?

Pete

P.S. Feel free to delete this comment after you've addressed the above.

Fixed the link and yes, i had evolutionary / revolutionary reversed.  Fixed that too. 

Alan Shalloway, CEO Net Objectives

Free Email Updates!

Sign up for free email updates from
Net Objectives Thoughts Blog

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean-Agile, Kanban, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, Kanban
Ken Pugh
Software Design, Design Patterns, Technical Writing, TDD, ATDD, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile