Roberto Lofaro
change, with and without technology| check on https://robertolofaro.com/cv
Turin, Italy
keywords: agile, iterative, methodologies, obiject-oriented, scrum, waterfall
As the title says, I am quite old in ICT (started officially in 1986, actually earlier), and I started when a company called Andersen Consulting still existed (I left in 1990), and I had the official title "Project Manager" on the payroll since 1990.
I eventually surrendered, as also unexpected sources started muttering "agile" and "scrum", and I read over the last few months plenty of material- including material that I had collected since 2007 concerning Agile and specifically Scrum.
Before designing and delivering methodologies, for Andersen in late 1980s I used part of Method/1 (the internal methodology), called "iterative development" and "post-production support", to design a method to "engineer" the creation of Decision Support System Models (number crunching on multiple dimensions: variable, time, region, product, demographics, etc).
It was built out of necessity: limited time, from both the customers (usually senior managers) and myself (at that time I was scattered around a significant number of projects, and marketing/pre-sales activities as well); eventually, somebody else built the usual visual charts etc, trying to convert the approach into an addendum to the method.
And also in my next job (selling, designing, and delivering methodologies for customers, at the Italian branch of a French company) I ended up creating hybrid approaches incorporating also some concepts from object-orientation, e.g. statecharts, classes, etc.
Question: is there anybody who came from a similar background (a Big-8, at the time, with an internal methodology built on few decades of experience), and who transitioned to Agile and Scrum, with a couple of full project cycles and can post some feed-back and caveats?
"Full project cycles" does not mean simply begin-to-end through the various sprints and other paraphernalia: means also that, to the best of their knowledge, the final product delivered did not become shelfware, and was really usable.
I saw way too many "innovative projects" followed by replacement delivered with more traditional, but more sustainable within the specific cultural and technical environment.
If you can, but you aren't from Andersen: Method/1 (then M/1, right before I left in 1990) was structured around functional traceability and documentation classification (e.g. ADM for administration, TCH for technical), across a basic waterfall process (first analysis, then develop, etc), and a multi-stage integration process (unit test, integration test, system test, etc), but it catered also for "alternative" approaches, e.g. the iterative when the requirements were built by the side-effect of the first deliveries, or the post-production support for what we could now call continuous improvement.
Reason for asking? I worked across multiple platforms (even before 1986), and also on Web projects I found useful practices that most of those born in IT development on the web seem to have re-discovered only after much of trial-and-error.
But the more I read detaiils about Scrum, the more is a déjà-vu
And I am confident that there are other "(professionally) born on a mainframe" within a structured environment who migrated to Agile and Scrum: so, why re-inventing the wheel?
Thanks
R
PS I walk the talk- therefore, I posted online hundred of pages sharing experience (scattered around, and mostly collected on my blog), if you are curious
Saving Changes...
|
|
|
