The "done" thing keeps coming up in my agile classes.
I challenge my students this way:
When an agile project is "done"? Is it done when time/money runs out? Is it done when the backlog is fully exhausted? And, is it done when the customer says it's done, or someone else?
Here's some set-up:
- Sponsor is a member/executive of the business that sponsors the project; the sponsor has control of the money from the business, and provides the money to the project. Sponsor also controls/owns the business case on the business side that more or less conforms to the project charter on the project side.
- Customer is the person who buys the deliverables from the business, after the project is "done". Customer brings money to the business, but not to the project
- User is in the customer community, but has no money. User may advise the customer, or hold the customer's proxy in the agile project team.
- Project is the collective entity of the business doing the project tasks. Project gets its money from the business sponsor.
- Now, if the project is a contract with the customer, then the calculus changes since now the customer brings money to the project. See: Golden Rule.More often than not, my responding guidance goes something like this:
I wrote the book, so I'm supposed to know something about this.
So, here's my guidance, more or less, to the "done" question.
Getting to "done"
-- Other people's money (OPM): the sponsor always has a vote on all strategic aspects of the project, including "done:
-- The business case: no serious project is approved without a business case, even if just a web form to the CFO/sponsor. Therein is a narrative, a vision, and a business expectation. Probably little other detail (thankfully)
-- Other swim lanes: no serious project has one vertical in the WBS or one horizontal on the swim map, so agile often only applies to the development; the rest of the project often runs conventionally and according to plans with "done" defined
-- Strategy v tactics: in general, agile puts strategic responsibility with the sponsor and the narrative; tactical value judgments are made by the customer/user
-- Sequencing: Newtonian physics still apply: roof after walls, so some things the customer wants may have to be deferred and money spent elsewhere (See below: best value "done")
-- Quality, standards, regulation: The customer doesn't usually get a vote on business policies to adhere to standards, maintain accreditation, and conform to regulation. These take budget, and thus discretionary funds for customer needs/wants is thereby diminished, deferring some requirements to the next project.
-- Non-functional: The customer usually doesn't have a say in non-functional requirements, and they figure heavily into "done"
-- The release: theoretically, an agile project is "zero base" after every release and could be ended right then and there. Release = 'done'
-- Backlog: there's always another project to absorb the undelivered backlog. (Else we wouldn't have careers)
-- Best value: Best value is the maximum scope deliverable for the fixed budget (investment) where the scope is the best fit (highest fidelity) to customer/user needs and wants, as prioritized for urgency, importance, usefulness (utility). In a BV project, done is not-later-than when the money runs out, but not mid-release either (there can be no partial releases). It's presumed that value is built in priority sequence with every release. In my opinion, BV is the most optimum way to plan an agile project.
Check out these books I've written in the library at Square Peg Consulting
