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?