I’m sure plenty of software engineers have been in this position: the rough surf of Agile and Scrum knowledge waves. Weekly blast emails about a new Agile garage or a new Product Owner organization change. Oh wait, Spotify a Guild? Let’s do it! Hire a Scrum Master – go, go go! Rollout DevOps – now!

It can be overwhelming.

But don’t get me wrong: I’m incredibly excited about the opportunity and the change and the excitement about Agile.

But I do have something small that I find a little amusing…I pulled the above image directly from Scrum.org and it reminded me so much of this old slide from an IBM BPM sales presentation about iterative development. I no longer have an exact copy of the deck, but check out this image from Page 11 of a 2015 Redbook:

And I know: Agile and Scrum have been around for years, I get that. But in some organizations, even in 2021, it is all brand new. But as an IBM BPM team we’ve been practicing this iterative development pattern for years, even in Waterfall projects, right?

Check out this Bruce Silver article about IBM BPM’s predecessor (Lombardi TeamWorks) in 2006:

A second distinguishing characteristic is support for rapid iterative development. Other vendors frequently pay lip service to this implementation style, but Lombardi supports it concretely with the ability to instantly “play back” activities and process fragments even early in the modeling phase, creating default components as necessary that will be refined later on. Lombardi emphasizes a project methodology in which a simple version or fragment of the process is piloted very quickly, with additional features and richness layered on iteratively after that.

Bruce Silver 2006: https://cs.nyu.edu/~jcf/classes/CSCI-GA.2440-001_sp12/handouts/BPMS_-_Lombardi_01.pdf

“Play Backs” and “rapid iterative development” – how much more Agile can you be?

It’s so nice to see other application teams excited (well, excited and full of trepidations) about Agile. Where they traditionally waited around for complete technical specification documents and design documents, now they can start coding and testing at the same time the larger team is building complementary code and functionality for stories. Where they were heads-down in code until QA, they are heads-up with the team each day, refining stories, providing Dev feedback, engaging the business, validating acceptance criteria, etc.

It’s seem like such “old news” to BPM developers, but it’s very exciting to have more partners along for the ride going forward.