Archive

Posts Tagged ‘Big Design Up Front’

Scrummin’ For The Ilities

August 30, 2013 2 comments

Whoo hoo! The product owner has funded our project and we’ve spring-loaded our backlog with user stories. We’re off struttin’ and scrummin’ our way to success:

US Backlog

But wait! Where are the “ilities” and the other non-functional product requirements? They’re not in your backlog?

ilities backlog

Uh, we don’t do “ilities“. It’s not agile, it’s BDUF (Big Design Up Front). We no need no stinkin’ arkitects cuz we’re all arkitects. Don’t worry. These “ilities” thingies will gloriously emerge from the future as we implement our user stories and deliver working increments every two weeks – until they stop working.

From Complexity To Simplicity

September 9, 2012 3 comments

As the graphic below shows, when a system evolves, it tends to accrue more complexity – especially man-made systems. Thus, I was surprised to discover that the Scrum product development framework seems to have evolved in the opposite direction over time – from complexity toward simplicity.

The 1995 Ken Schwaber Scrum Development Process paper describes Scrum as:

Scrum is a management, enhancement, and maintenance methodology for an existing system or production prototype.

However, The 2011 Scrum Guide introduces Scrum as:

Scrum is a framework for developing and sustaining complex products.

Thus, according to its founding fathers, Scrum has transformed from a “methodology” into a “framework“.

Even though most people would probably agree that the term “framework” connotes more generality than the term “methodology“, it’s arguable whether a framework is simpler than a methodology. Nevertheless, as the figure below shows, I think that this is indeed the case for Scrum.

In 1995,  Scrum was defined as having two bookend, waterfall-like, events: PSA and Closure. As you can see, the 2011 definition does not include these bookends. For good or bad, Scrum has become simpler by shedding its junk in the trunk, no?

The most reliable part in a system is the one that is not there; because it isn’t needed. (Middle management?)

I think, but am not sure, that the PSA event was truncated from the Scrum definition in order to discourage inefficient BDUF (Big Design Up Front) from dominating a project. I also think, but am not sure, that the Closure event was jettisoned from Scrum to dispel the myth that there is a “100% done” time-point for the class of  product developments Scrum targets. What do you think?

%d bloggers like this: