Two basic types of release plans that are widely used are scope-boxed release plans and time-boxed release plans.
“In a scope-boxed plan the work that the team will do is defined in advance, but the release date (time) is uncertain. In a time-boxed plan the time and release date is defined in advance, but the specific work that people will do is uncertain and is being elaborated with time.
“Time-boxed plans are the most preferred way of release planning. This will constrain the amount of work and people will automatically start doing the prioritization which is the fundamental concept of Agile.”
PMI Agile Certified Practitioner; Chapter 5: Planning, Monitoring, and Adapting
Software always becomes iterative.
(Agile just does it sooner.)
Mark Richards & Neal Ford, Software Architecture Fundamentals , Part 1 – Introduction, 22m 56s
The length of a single task is notoriously difficult to estimate. But without an insertion ritual estimates don’t even matter because no one consults them. It’s a free-for-all.
Over a year ago I was part of a committee trying to improve our “on time performance.” Our conversation took me back to the heady days of my internship at Novell. Funnily enough, my old manager from that job was there. He had once given the same well rehearsed speech that another senior manager was giving:
The Golden Project Planning Triangle of Gold
Let’s review the storied planning triangle that every technical person ought to be familiar with. When you plan a project there are three major components: scope, schedule, and resources.
Resources includes people. We know they are people. Please look beyond the fact that they are called resources. We love you all as the individual and wondrous snowflakes you are.
Continue reading Your Plan Needs an Insertion Ritual
Chris Lehmann’s Purple Reign gives an inside view into the demise of the Yahoo News machine. Weighing in at nearly 9 thousand words it might take you a while to get through it. I’ve snipped out some of my favorite passages from my own perspective. The original article is a much better read than my uneven summary.
Beg, Borrow, Steal
Lehmann relates how one of his reporters acted to get his job done without overdue concern to corporate support:
My reporting team did important and groundbreaking work on … the 2010 Deepwater Horizon oil spill—our reporter moved down to New Orleans from New York, on his own dime, to cover it.
Often we have to get things done without all the support we would like–without all the resources we think we need. I like this example of dedication from this reporter who moved to the site of a big story to cover it.
Continue reading Lessons from Yahoo News’ Failures
Agile: the Good Parts (according to Bertrand Meyer):
developing in short iterations of two to six weeks … has profoundly transformed the software industry for the better.
absolutely no one, regardless of rank, is allowed to add anything during [an] iteration.
And now, some bad bits of Agile:
the general rejection of what’s derisively called “big upfront anything.” … The agile world has this phobia of not producing anything that’s not deliverable to the customer. … the idea that it’s bad to spend an appropriate time at the beginning of the project to clarify the overall requirements and design is nonsense. You do need at some point to focus on the deliverables; but until then you should take all the time necessary to address the big issues of specifications and design. I’ve seen projects fail miserably for blindly applying the Agile catechism: we’re Agile, we don’t need to stop and think, we just go ahead and code! Not surprisingly, what they code is junk and they have to redo it….
Bertrand Meyer in the article “Object Lessons” by Leah Hoffmann,
March 2015 issue of Communications of the ACM, pp. 95