1. BPM
  2. BPM Discussions
  3. Tuesday, 03 September 2019
  4.  Subscribe via email
Curt Cagle, in an article in Forbes, states that it is time to move on from Agile. In a followup article, he states:

It's time to move on. Agile may be everywhere, as several readers suggested, but scratch the surface a bit and you'll find that most of those successful agile projects were ones where you had a strong architect or steward, a culture that was already primed to work in a more Studio-Model like manner, a strong design in the first place as a foundation, and exceptional team-members that used agile in the way it should be used - as a scaffold, rather than a crutch. There are good things to take out of the last twenty years of Agile, but this is not 2000, and it's well past time to acknowledge what's worked with Agile ... and what hasn't.

So - is it time to move on?
  1. https://bpm.com/blogs/beyond-agile-the-studio-model
  2. https://www.forbes.com/sites/cognitiveworld/2019/08/23/the-end-of-agile/#5f805b0f2071
Find me at BPM.com.
Accepted Answer Pending Moderation
Absolutely. With software development we have always had the builders in charge of the project. It's time to empower the client (users) to be in charge. If I want a house I don't expect the builder to say 'What do you want?'. I know this will end in tears - as do many software projects. I with the help of an architect (who is client-centric not builder centric) create a detailed design and give this to the builder to work with. Most building projects deliver what the client expects. So it should be with software. The client/users should have the capability along with a business analyst to create a design of the system/process they want ...and defined to the level where the builder/developers can't go wrong.

We are moving towards this point with Low-code No-code. What's missing at present is a client-centric tool that enables them to define their business in detail. Current definition tools are designed for use on the builder side of the fence - like BPMN. The client may want a swimming pool, but they don't want swim lanes.
Accepted Answer Pending Moderation
Allow me to kindly disagree with Anthony Blackham :)

There are now cloud BPMs absolutely focused on the business user. These products allow that dose of agility, defining and delivering processes quickly, evaluating the results and introducing changes in a short time, and thus evolving the processes until they are complete. But without touching the "fundamentals", since they are using a proven and robust BPM Suite.

It is true that the full BPMN standard is not business-user friendly. That's why some tools adopted a subset of the BPMN artifacts (for example, reference #1); those that are understandable and more usable by non-technical personnel. This has broken down the entry barriers to BPMN notation, allowing them to fully model and deploy their processes.

With respect to the original question, it is true that agile methodologies that have been successfully applied have required expert teams and robust initial designs. But in my opinion, the core of agile methodologies, which is to build together with the client, with periodic and fast deliveries, has proven to be especially useful. I don't think we will ever go back to traditional models like waterfall.

Will agile methodologies continue to evolve? Of course. BPM's low-code and non-code tools will continue to strengthen as a relevant tool to apply agile methodologies in the reengineering, automation, and improvement of business processes.
  1. https://www.flokzu.com/blog/en/bpm/modeling-a-business-process/
CEO at Flokzu Cloud BPM Suite
Accepted Answer Pending Moderation
With the proven delivery of enterprise level Adaptive applications without need for coding the concept of Agile changes to one where the direct input from users into the build environment intuitively delivers an agile environment. The whole exercise of course needs planning to bring users on board and giving them the confidence that their contribution really can be directly inputted to the build. There will of course be differing ideas but quick build of ideas can allow such "agile" thinking arrive at optimal solution. The removal of coding for all business tasks and logic just change the participants in the project. This results in skipping the interpretation problems which the original concept Agile tried to address but does not remove the benefits of Agile thinking in building the required process.
  • Page :
  • 1

There are no replies made for this post yet.
However, you are not allowed to reply to this post.