I’ve come to realize system-software development methodologies have in common with nature the life span of infancy, childhood, adolescence, adulthood, and aging. I have also come to realize methodologies, sometimes as part of their life span, enter into a relationship or marriage with other methodologies; like has happened with Agile Software Development and Lean Manufacturing.
Additionally, methodologies of the past and present have an associated taxonomy, new jargon and technical terminology or idiomatic expressions of the practitioner. They also tend to reuse old jargon but with different connotations.
Just like the seventeen like minded individuals did in 2001, when they came up with the Manifesto for Agile Software Development , it is time to reflect on today’s reality, specific to the fundamental practices underlining our industry’s and your agile/lean product (system-software) development approach and look to the future.
“You can clutch the past so tightly to your chest that it leaves your arms too full to embrace the present.” - Jan Glidewell
We use to have the pony express delivering letters helping to keep folks in touch with one another. Then came the telegraph and telephone. Now we've gone back to letter writing, in the form of email, text messaging, or Twitter to keep in touch.
Let’s not dwell on the past, but reflecting on our past and present creates a better future.
To help you reflect, ask yourself a few questions and give honest objective answers to them. You will then be able to see whether or not you have progressed the way you wanted. The 5 Whys is a simple problem-solving technique that you can use. Made popular in the 1970s by the Toyota Production System, the 5 Whys strategy involves looking at any problem and asking: "Why?" and "What caused this problem?"
Very often, the answer to the first "why" will prompt another "why" and the answer to the second "why" will prompt another and so on; hence the name the 5 Whys strategy.
Following is an example of the 5 Whys analysis applied as an effective reflective technique in the world of being agile when applying the Scrum framework:
- Why is our Product Owner, unhappy? Because we did not deliver the product release when we said we would.
- Why were we unable to meet the agreed-upon timeline or schedule for delivery? The stories took much longer to develop than we thought they would.
- Why did it take so much longer? Because we underestimated the complexity and uncertainty of the stories.
- Why did we underestimate the complexity and uncertainty? Because we did not have acceptance criteria associate with each story, our stories were not at the right level of detail and we did not realistically size each story prior to committing to a schedule for delivery.
- Why didn't we do this? Because the higher powers were still working under the traditional waterfall planning mental-model, as a result we felt pressure to work faster and skipped steps. We clearly need to review our approach to writing stories, sizing stories, estimating duration and committing to a schedule for delivery and then get buy-in and visible support from the higher powers .
“The present is never our goal: the past and present are our means: the future alone is our goal.” – Blaise Pascal
In the span of the last 35 years or so the following system-software development methodologies have been widely practiced and evangelized:
- Structured Programming
- Structured System Analysis and Design
- James Martin’s Information Engineering, popularizing visual modeling in the form of data modeling and process modeling
- Object Oriented Analysis, Design and Programming
- Extreme Programming
- The Unified Software Development