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
You're confusing Scrum with Agile.
Agile is a Methodology and comes with a Manifesto + Principles.
Scrum is a process, focused on roles, tasks and steps to deliver work.
in that way, the Open Development Method is a Methodology and together with the community's help we will grow it, modify it and improve it then create process(es) around it.
I apologize for taking this long to reply, although you were the first commenter :)
hopefully this landed in your news feed to bring you here to add value and thought to the discussion and help us improve our workflows and processes :)
I shouldn't have labeled it as "code quality", but rather as simply "quality".
this applies to design, code, user experience, and business value. you want to provide quality in all these aspects.
same goes for testing. test your design, test your code, test your user experience, and most importantly test your business model!
the biggest failure in Scrum & Agile is the false promise of "focus on customer value" and actually delivering little to help that value.
the customer is usually not the expert (which is fine) but is treated that way and thus in most cases treated with kid gloves. they don't get full visibility into the REAL work behind the scenes, but rather get the foot notes, delegated through two layers: scrum masters (usually project managers) and product owners (usually product managers).
the customer never really sees or understands the complexities of the user experience, the design choices or the development challenges. in the favor of time and cost, you end up creating technical debt that keeps growing and never truly addressed, because you want to focus on "customer value" meaning delivering the features they are asking for in the shortest time possible no matter the cost.
It's also important to remember that Agile and Scrum are targeted towards the service industry, not product builders. from their inception and history to the wording they rely on e.g. "customer" its fundamentally different perspective on product building and introduces a deep separation from the creators of the software (developers, designers, etc ...) to the actual users of the software (usually the customer's clients)
> "you might have seen tons of Agile Coaches. Mostly bad ones, it sounds like. That might have made you bitter towards Agile."
quite the opposite in fact, many pleasant and helpful experiences with Agile and coaches. never-the-less is still comes up short to the reasons outlined above.
it seems that this is the default reaction to any Agile coach, or somebody drinking the Scrum koolaid for so long: "you just have not done it right"
which honestly is no way to have a discussion and provide value. lets discuss in details what's missing, what's good, what's bad and make improvements all around.
after all, at the core of Agile / Scrum is continuous improvements through an iterative process. I do not see Scrum or Agile it self being improved or re-visited at all, but rather stayed as static as that original website where the manifesto was first published, a relic of a time that has gone by, fully embodied by the dated website it's published on.
n