Toronto
Ahmad is an advocate of all things open source and a developer tooling enthusiast. Currently leading the talented engineering team at Mashape in building world-class API tools and Marketplace. In his spare time, Ahmad blogs on Technology & Leadership, mentors early stage startups, and builds open source projects used by thousands of developers world wide.
Authored Comments
Hey Rico,
hopefully this landed in your news feed to help us come together and improve everybody's process and software :)
indeed the article is heavily focused on "code quality" and "code" in general, that is my mistake, I do tend to use development terminology, but I am referring to the whole product.
Everything that I say about "code" also applies to "design" + "user experience" + "business value".
take the key questions I listed under Quality, a wider scope of all aspects of the product still apply:
Is this code/design/experience/business legible?
Is this code/design/experience/business testable?
Is this code/design/experience/business modular?
Is this code/design/experience/business economical?
the article would have perhaps been longer to include a listing of all aspects of a product, rest assured I will make sure to clarify that in future write ups.
as for Agile Coaches, yes, we've had many, across different teams and companies. some we good, some were great, few were bad actually. I would say the Agile coaches I've worked with have generally been a great investment into our teams workflow, and productivity. some of the most energetic people I've worked with in fact.
That said, while the coaches were great, and provided tremendous value, the were still preaching a dated process designed for Software Development of the past. our world has evolved, and our technology too, teams are disturbed, across multiple timezones, languages, and cultures. Software is no longer a single definition, but many, and teams working on a Product, have to touch on an ever expanding landscape of technologies that can not be easily grouped into small Scrum teams with overlapping delivery schedules and requirements.
There is no such thing as a "silver bullet" I fully agree, and I'm not suggesting The Open Development Method is one either. What I am suggesting is we evolve our processes and methodologies through a contentious cycle of evolution to match our times and needs, rather than holding on to 20+ year old methodology.
after all, doesn't Agile champion Iterative, incremental and evolutionary style of development? why not apply it to Scrum it self?
Hey Joseph,
thanks for your comment! indeed an international team poses challenges beyond traditional Project Management methods! I have experienced that in the past, and continue to do so today with a team split across 7 cities, 6 timezones, 8 Nationalities, speaking 8 different languages :)
Which is where the quest for an alternative lead me to the Open Source world, and the Open Development Methodologies.
as per the longer comment I left below: https://opensource.com/business/15/11/open-development-method#comment-8…
I don't feel the Agile Manifesto is at odds with The Open Development Method, in-fact, I think it is -mostly- compatible in its principles, but it is fundamentally different, in being a "manifesto", as oppose to a "Methodology". Both also need a "Process" to realize into day-to-day activities.
While Agile has Scrum / Kanban / XP etc ... The Open Development Method has none. yet.
and that is intentional, as I don't want to dictate the process we use as holy, or as the expert's answer that all should follow, I want this to be an open initiative, with the community determining what makes sense and what doesn't, and maybe even have more than one process!
I invite you to help in forming the future of this for everybody's benefit :)