Wednesday, February 25, 2015

Agile starts here

Even though the business case tells me what product I'm building, detailed outcomes of software projects, viewed from afar are not very predictable. But... up close, they are. 

From this we get the fundamental architecture of agile projects to wit:
Agile projects are strategically stationary but tactically emergent

And, 'stationary' means... ? Stationary means that no matter when or where you view the project, it's strategic intent and outcome are invariant --- the same, unchanging.

And, 'emergent' means... ? Emergent means that detailed requirements may be created, deleted, updated, or deferred as circumstances reveal themselves and the project moves along.

How do we move from stationary in the far view to stationary in the near (up close) view?
  • First, write a business case. And, from that a project charter. Those two dots should connect. These get you strategic intent and far view stability. These need not be heavy documents; often, a single page will drive a lot of project.
  • Second, adopt the idea that for each segment of work put in process (WIP) on a Kanban board or a sprint or iteration, the backlog for that unit of work is fixed and frozen. This gives up close stability. And, tactical estimates can be done on such a fixed scope of work. 
What about that bug-a-boo of estimate or no-estimate? This really shouldn't be a question, but it always is:
  • The sponsor is going to come with a top-down budget and schedule. In a real business, there are budgets, period.
  • The project must respond to the business case. The response is usually made in the project charter.
  • The project charter has two constituents: 1. The project's counter proposal to the top-down budget, and 2. the estimate of risk to close the gap between the business budget and project's counter-proposal.
The accountants among us may recognize the similarity to a triple entry balance sheet:
  • Business value and budget on the one hand
  • Project risk (liability) and capabilities on the other hand
In point of fact, for many years, I've been calling this balancing act a project balance sheet. The business gets one side; the project gets the other side (and, of course, the project gets the side with the risk... you wouldn't imagine it would be any other way!)

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog