• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (3)

1 Carson commented Permalink

Scene 1 - The Stakeholder, just wanted to add a thought...

 
The ideal stakeholder would be someone who could build the system themselves, yet today this usually requires programming skills which the typical stakeholder doesn't have. Instead the stakeholder has to articulate his vision in some fashion, be it sketchs, white board drawings, and hopefully not heavy documents. The development team in turn needs to show incarnations of the working system and get feedback from the stakeholder. The more frequent this feedback the better the team can understand the vision and adjust the evolving system to fulfill it.
 
So the greater the distance and barriers between the stakeholder(s) with the vision and the team developing it, the longer it will take and the less likely the system will look like the vision. The power to innovate is inherent in the dynamic nature of software. Tight collaboration between the stakeholder and development team will result in visionary leaps forward that could establish a greater competitive edge in the marketplace.

2 Carson commented Permalink

Scene 2 - Procurement, another thought

 
In the world of enterprise IT there is a serious culture clash raging between the traditionalists and the agilistas. The traditionalist philosophy believes in up front estimates and predictability even though empirical evidence shows that their is low fidelity in these original estimates. Software is unlike construction, as much as knowledge work is unlike physical labor. Building a bridge between two view points in much different than two land masses.
 
There are new metrics for those traditionalists from the lean and agile circles like throughput and velocity. These metrics can drive a high fidelity estimate for delivering future business value through software. By basing predictions on finer grained demand and on past and current performance, as teams establish a cadence, the business will gain better predictability and transparency into their IT investments.
 
Once traditionalists can experience this new paradigm for knowledge work, a light will go on. The shift is happening in our IT cultures already. It's time to put side old notions of estimation and embrace a new wave. There is a science behind why agile and lean practices do work, though it's not know to many practitioners. For the math behind the movement and how to rationalize about the larger Lean IT Enterprise, read SDLC 3.0, Beyond a Tacit Understanding of Agile, by Mark Kennaley.

3 Carson commented Permalink

Scene 3 - Governance & Compliance, piling on...

 
Most IT compliance policy has been translated from the legalese of compliance legislation. After which, the IT organization regiment-ally follows without question during solution delivery. The real problem is that the translation is usually slanted towards the method affiliation of the translator. In the past, a large percentage of these translators used the waterfall method as the basis for solution delivery.
 
Julian hit it on the head when he wrote, "Provide better measures of real progress than the typical documentary evidence has ever provided." The practices and techniques of agile actually increase the standard of care. The intent of the compliance legislation is to protect the shareholder, and many IT compliance policy based on waterfall is negligent.
 
Be careful of legacy IT policy that mandates requirements must be detailed prior to development. This is a misinterpretation of the spirit of intent in the original compliance legislation. Don't blindly follow existing policy without questioning where it came from and asking why (five times).

Add a Comment Add a Comment