Agile: revolution to evolution

---

20 odd years ago, Agile was a revolution in methodology and some say a revolution in business objectives, all set down in some now-well-known principles from the last '90s.

But, has there not been an evolution in the last two decades?

Mike Cohn, a spearhead in the Scrum world to be sure, says this:

Originally, agile meant valuing individuals and interactions, working software, customer collaboration, and responding to change.

Agile was about cross-functional teams working closely together to innovate new products or solutions that couldn’t have been developed any other way.

These days agile seems to be about

• Improving productivity,
• Reducing work in process,
• Increasing velocity in any way possible,
• Holding teams accountable for finishing everything they say they will, and,
• Doing just enough that an organization can call itself agile without really being agile.

He's probably right on this.
So, what happened?

For agile to be anything other than a cottage industry, it had to marry up with serious business people who put up the money and expect effective functional results in-line with business objectives.

And, being a capitalist economy, projects have always had to line up with capitalist objectives:

• Relentless drive to reduce cost, 
• Produce more, and 
• Drive the bottom line (profit margin)

The soft side of agile, the camaraderie of harmonious teams focused on product by and large, when modulated by capitalism, comes out looking like the Cohn view of evolutionary Agile.

It's not personal, it's business!

---

Buy them at any online book retailer!

Alice, the Cat, and Agile

---

I've heard it many times that this little ditty is the essence of why Agile is problematic with its dearth of plans, estimates, etc:

"Would you tell me, please which way I ought to go from here?
'That depends a good deal on where you want to get to,' said the Cat.
'I don't much care,' said Alice.
'Then it doesn't matter which way you go,' said the Cat.
'So long as I get SOMEWHERE,' Alice added as an explanation.
'Oh, you're sure to do that,' said the Cat"

- Lewis Carrol from "Alice's Adventures in Wonderland"

Not so fast!

• No Agile project is sans a Narrative or Vision or epoch story
• No Agile project is without some tie to the business, and thus a business outcome or influence,
• No Agile project is without some commitment of resources from the business -- folks I know don't work for free

On the other hand

• Some Agile projects have trouble getting off the stage; to wit: Are we done yet?
• Some Agile projects spend the money and get little done, certainly little for the business
• All Agile projects benefit from some degree of planning and estimating, if only to frame the project onto the right first step.

Alice and the Cat are not Agilists!

---

Buy them at any online book retailer!

The Agile Canon

---

I thought this posting on the "Agile Canon" was worthy of passing along in its entirety. So, there's the link for a pretty good read on the most important elements of a canon that all should be interested in adopting:

1. Measure Economic Progress: Outcomes, means to measure, means to forecast
2. Proactively Experiment to Improve: Assess options, embrace diversity and variability, execute experiments to improve
3. Limit Work in Process: Visibly track work by category, communication delays are a form of WIP
4. Embrace Collective Responsibility: don't blame others, don't blame others by name, don't blame the circumstances, accept and embrace responsibility for outcomes
5. Solve Systemic Problems: Be de-constructive to the root cause, be aware of both static and dynamic influences

---

Buy them at any online book retailer!

Leveraging customer relationships

---

One of my students offered this strategy for establishing, maintaining, and leveraging relationships with the customer. I thought it was pretty good, so here's the idea:

1. Customer Account Responsible (ACR) -- who ... is the Account Manager
for the domain, market or dedicated to the customer (big accounts) responsible for:

• Account relationships,
• Opportunity identification,
• Commercial management,
• Communication management.

Normally the SPOC for a business development effort.

2. Customer Solution Responsible (CSR) – This role is held by various people
depending on the company type – Solution Architects, Solution Consultants,
Solution Managers etc – and they have the responsibility of:

a. End-to end solution integrity
b. Collection of and documentation of requirements from the customer – Executive,
Business, Technical and Users requirements – Securing the sign off on the
requirements scope with the ACR and CFR to the customer.
c. Prioritization of the requirements with the respective customer responsibilities,
in order of increasing importance, and determining the “fit to need” alignment of
the requirements
d. Map solution requirements to the vendor solution/product portfolio, and
determine the Delta, and how to fill those Delta.
e. Hand off complete solution design documentation to the project execution team,
and provide input to the executing team (CFR) for project execution planning.
f. Including and manages SME’s , Product Owners etc and their deliverables as
needed in various verticals that are needed to address the solution design and
product lifecycle

3. Customer Fulfillment Responsible (CFR) – this is normally the PMO organization that turn the solution into reality inside the customer organization/premises/site:

• Project management team,
• Service Delivery team,
• System Integration team,
• Field Engineers,
• Technical Architects etc

PMO is are responsible for:

• System Integration and Final Acceptance testing
• Validation with the customer, and
• Finished Product Handover to the customer Project/Service Operations team.

At this stage the solution ceases to be a project, and is included into the Customer Operational and Support Lifecycle Management.

---

Buy them at any online book retailer!

Does software actually fail?

---

Does software fail, or does it just have faults, or neither?
Silly questions? Not really. I've heard them for years.

Here 's the argument for "software doesn't fail": Software always works the way it is designed to work, even if designed incorrectly. It doesn't wear out, break (unless you count corrupted files), or otherwise not perform exactly as designed. To wit: it never fails

Here's the argument for "it never fails, but has faults": Never fails is as above; faults refer to functionality or performance incorrectly specified such that the software is not "fit for use". Thus in the quality sense of "fit for use" it has faults.

I don't see an argument for "neither", but perhaps there is one.

However, Peter Ladkin is not buying any of this. In his blog at "the Abnormal Distribution", he has an essay, part of which is here:

What’s odder about the views of my correspondent is that, while believing “software cannot fail“, he claims software can have faults. To those of us used to the standard engineering conception of a fault as the cause of a failure, this seems completely uninterpretable: if software can’t fail, then ipso facto it can’t have faults.

Furthermore, if you think software can be faulty, but that it can’t fail, then when you want to talk about software reliability, that is, the ability of software to execute conformant to its intended purpose, you somehow have to connect “fault” with that notion of reliability. And that can’t be done. Here’s an example to show it.

Consider deterministic software S with the specification that, on input i, where i is a natural number between 1 and 20 inclusive, it outputs i. And on any other input whatsoever, it outputs X. What software S actually does is, on input i, where i is a natural number between 1 and 19 inclusive, it outputs i. When input 20, it outputs 3. And on any other input whatsoever, it outputs X. So S is reliable – it does what is wanted – on all inputs except 20. And, executing on input 20, pardon me for saying so, it fails.

That failure has a cause, and that cause or causes lie somehow in the logic of the software, which is why IEC 61508 calls software failures “systematic”. And that cause or causes is invariant with S: if you are executing S, they are present, and just the same as they are during any other execution of S.

But the reliability of S, namely how often, or how many times in so many demands, S fails, depends obviously on how many times, how often, you give it “20″ as input. If you always give is “20″, S’s reliability is 0%. If you never give it “20″, S’s reliability is 100%. And you can, by feeding it “20″ proportionately, make that any percentage you like between 0% and 100%. The reliability of S is obviously dependent on the distribution of inputs. And it is equally obviously not functionally dependent on the fault(s) = the internal causes of the failure behavior, because that/those remain constant.

---

Buy them at any online book retailer!

Validation and Verification -- in Agile? Really?

---

Validation and Verification: traditionalists know these ideas well. Do they still have relevance in the Agile space?

My opinion: Yes!

Traditional V-and-V: the way it is

Traditional projects rely on validation and verification (V-and-V) for end-to-end auditing of requirements:

• Validation: the requirements ‘deck’ is validated for completeness and accuracy.
  
  If there are priorities expressed within the deck, these priorities are also validated since priorities affect resource utilization, sequencing, and schedule.
  
  
• Verification: After integration testing, the deck is verified to ensure that every validated requirement was developed and integrated into the deliverable baseline; or that changed/deleted requirements were handled as intended.

Agile: what's to verify; what's to validate?

The BIG QUESTION: Is the strategic intent of the narrative answered? Is the business case on a path to success?

After all, the grand bargain in Agile is that flexibility for tactical implementation is allowed insofar as there is faithfulness to the strategic intent. Tactics are fluid; strategy is not.

Agile V-and-V: the way to do it

Certainly, Agile projects are less amenable to the conventional V-and-V processes because of the dynamic and less stationary nature of requirements.

• Validation: After the business case is set, the top-level narrative is in place, and the overall strategy of the project is framed, some structured analysis can occur on the top level requirements.
  
• If there are priorities expressed within these business case requirements, these priorities are also validated
• Conversational-style requirements -- aka, stories -- are also validated, typically after the project backlog or iteration backlog is updated.
  
• Verification: After integration testing, the deliverable functionality is verified to ensure that every validated conversation was developed and integrated into the deliverable baseline; or that changed/deleted conversations were handled as intended.
  
• During development, expect some consolidation of stories, and expect some use (or reuse) of common functionality.
  
  Thus, recognize that Agile may not maintain a fully traceable identify from the time a conversation is moved into the design and development queue to the time integration testing is completed. However, the spirit of the conversation should be there is some form. It’s to those conversational forms that verification is directed.

The last thing to do is circle back to the narrative: Is the big question verified? If so: victory!
If not, back to the sponsor for guidance and direction

---

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

What time is the 3pm meeting?

---

Have you ever been asked: "What time is the 3 pm meeting?" 
You're thinking: "This guy is on something; or he's texting while talking!"


We here in the backyard of the seemingly larger-than-life Walt Disney World* pay some attention to the management paradigms coming out of our corporate neighbor.

And, so the Disney response to that question is instructive, as given in this blog post from the Disney Institute, which I sum up as:

'Any interaction provides an opportunity to add value and improve quality of communications'

“What time is the 3 o’clock parade?” On any given day in the Magic Kingdom at Walt Disney World Resort, you might hear Guests asking our Cast Members this seemingly peculiar question. And, while the question appears to have an obvious answer, we also know that frequently the true question lies beyond the obvious.

As our Guests are often excited and distracted ..... So, Cast Members will ask some additional questions to uncover what it is that the Guest really wants to know…such as, “What time will the parade get to me?” “When should I start waiting to get a good viewing spot?” and “Where is the best place to stand?”

Instead of simply repeating the obvious answer—the actual parade start time—back to the Guest, our Cast Members take this opportunity to .... share with the Guest what time the parade will pass by certain locations in the park, offer possible vantage points to view the parade or advise when to leave another area and still arrive at the parade on time.

This is important, because rather than dismissing the “3 o’clock parade?” question as something trivial and offering a blunt response, Cast Members understand that it offers the opportunity to exceed the Guests’ expectations ...... 
.... the “3 o’clock parade” question is commonly used to help Cast Members understand that their answer can either end the conversation, or it can begin a quest for richer discovery.
....

*Did I mention:7 parks, 29 hotels on property, 40,000 acres, and tens of thousands of "cast members
And, I am an un-paid volunteer for Disney Sports Attractions

---

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