Tuesday, November 13, 2018

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!

Saturday, November 10, 2018

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!

Wednesday, November 7, 2018

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!

Sunday, November 4, 2018

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!

Thursday, November 1, 2018

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!