Regardless of your organization's ability to develop quickly (as discussed in my last post
), the main objection from many businesspeople to the way that their development organization approaches agile is a lack of perceived accountability: "Teams build stuff, but I never get anything delivered -- or I can't get them to give me a date. It's always in the next PI/cycle."
In keeping with the mythbusting I referenced two posts ago
, your organization does not need to suffer a lack of accountability in order to successfully improve its agility -- but you may benefit from a rethinking of the details of accountability as the world has evolved over the last two decades.
We've identified two key concepts that form the foundation of this new accountability model: Deliverables
is a package of one or more value elements (epics, etc.) as defined in my earlier post
. Each package represents the expectations of the business for meeting its goals. Note that care should be taken not to over-prescribe the necessary characteristics of a deliverable; the deliverable is the minimum viable product (MVP) that satisfies the business' overall expectations.
is the date by which a particular deliverable is expected to be received. In most cases, a deadline -- unlike a milestone or other traditional planning date -- cannot
be moved because it is a result of circumstances outside management control.
Two key concepts here:
(1) Deliverables and deadlines are inexorably linked. Part of what defined a deliverable is that it must
be received by a particular date (i.e. deadline).
(2) As stated above but reiterated here for emphasis, deadlines usually cannot be moved because they are usually tied to external events. Legal regulations, industry events, merger & acquisition dates, or even suspected market windows are all examples of events outside of management's control that fuel the need to deliver product.
Defining your deliverables and corresponding deadlines can ultimately serve as a rebranded form of program management that allows for coordination within and across products. I'll discuss this in greater detail in future posts.