Resolved
3 votes

Suggested by Peter Hilton and based on the agile manifesto: How can BPM become more agile?

Tuesday, August 25 2015, 09:46 AM
Share this post:
Responses (19)
  • Accepted Answer

    Tuesday, August 25 2015, 09:57 AM - #Permalink
    Resolved
    4 votes

    Easy; just renaming your 'process improvement project' to 'sprint'

    -----

    Copied from a comment later on: 

    Agile BPM...I would never combine these terms. What it would mean to me would be something like flexibilty and adaptabilty of processes. 


    What I mean by that: https://www.linkedin.com/pulse/our-processes-very-flexiblein-doing-useless-things-emiel-kelly?trk=prof-post

    • Craig Willis
      more than a month ago
      Put all the chairs from your meeting rooms on ebay and call meetings standups.
    The reply is currently minimized Show
  • Accepted Answer

    Ian Gotts
    Ian Gotts
    Offline
    Tuesday, August 25 2015, 10:00 AM - #Permalink
    Resolved
    7 votes

    I don't want to make BPM more agile. I want to make my business more agile.

    The challange is agility within a regulatory compliance framework. Compliance is a factor in every maror company and particularly inflentional in certain industries: Financial Services (FSA), healthcare (HIPAA), Life Sciences (FDA), Food (FDA) and Energy and Construction (HSE)....

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 25 2015, 10:01 AM - #Permalink
    Resolved
    4 votes

    Just apply agile development practices to what you're doing. We've been doing this a long time at BP3 and before BP3. I use agile with a lower case A because we take into account particulars of platform and UI development technique in the context of a BPM project. Recently we started putting a name to the method that we use just to have a short-hand for referencing it, but really there's no secret - all the secrets are published in blog posts and books - you just have to put them to work...!

    • Patrick Lujan
      more than a month ago
      If BPM is a "practice," Agile is an attitude. Execute, it's that simple.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 25 2015, 10:04 AM - #Permalink
    Resolved
    4 votes

    We have adopted the use of wire frames. Good business analysts (BAs) can guide innovation (steps to reducing process waste while improving the overall experience) and design (how the user interacts with the solution) by using wire frames to help users visualize user experience during every step of the overall process. The visualization allows the consultant to explain how data is captured and the users to understand and determine layouts. For example, in the UI users should decide what data should describe a work item and how the data is broken out into rows and columns. This exercise also helps users understand how form data (the list values and free text captured in each form field) and process data (touch time, turn around time) is published to the user interface. As users connect the dots, they become better analysts and designers themselves. They also often remember data and/or key metrics that somehow fell through the gaps during requirements analysis. So the use of wire frames not only help users understand how the application works they also help developers to quickly code/configure the end product. Projects go faster and smoother.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 25 2015, 10:34 AM - #Permalink
    Resolved
    5 votes

    1/ Model and execute processes directly in your IDE.

    2/ Model and execute business cases as Cases (either as per BPMN 2.0 with ad-hoc tasks or as per CMMN 1.0) directly in your IDE.

    3/ Model your data model directly in your IDE.

    4/ Model your interface directly in your IDE (or use something that can easily export the HTML / CSS / JS code - no, please, not friggin' Balsamiq or wireframing tools).

    Have an IDE, while you're at it.

    What does this have to do with agile? Because in an IDE you can iterate the cycle design - build - test - deploy with a fantastic speed.

    And the whole point of agile is that iteration beats planning.

    • Patrick Lujan
      more than a month ago
      I see 2.5 practitioners in the responses so far. The others are not going to "get" what you've just stated, though you're spot on.
    • Emiel Kelly
      more than a month ago
      Hey, this is 'just' about software development. That's not BPM.
    • Emiel Kelly
      more than a month ago
      Agile BPM...I would never combine these terms. What it would mean to me would be something like flexibilty and adaptabilty of processes.

      What I mean by that: https://www.linkedin.com/pulse/our-processes-very-flexiblein-doing-useless-things-emiel-kelly?trk=prof-post
    • Emiel Kelly
      more than a month ago
      Partly with software indeed, Bogdan. But assuming that's the only thing to 'manage a process'; I think that's a too narrow view.
    • Bogdan Nafornita
      more than a month ago
      Thanks, Patrick! I think the IDE problem is severely understated in the world of BPMS, also the solutions I've seen so far are half-assed Eclipse hacks - and those are the better ones.

      Emiel, you're right, this is just about software, but how do you actually bring BPM to life in today's world? Also, I have lately a tendency to navigate with the answers around the conditions of my own start-up, so I apologize if the answers tend to get a little too specific.
    • Emiel Kelly
      more than a month ago
      Bogdan,

      Everyone answers from his own experience. I (besides many other things) run a child day care together with my girlfriend. We use software, but that's not enough to manage the processes ;-)
    • Bogdan Nafornita
      more than a month ago
      You're right, Emiel, but the question is put in the context of agile as a software development methodology so I focused on that.

      I really can't be tortured to think about ISO 9001 compliance as agile, for example :-)
    • John Morris
      more than a month ago
      Bogdan, your comments on the importance of IDE are more important than one might think just on a casual read!

      Specifically you say that "the IDE problem is severely understated in the world of BPMS, also the solutions I've seen so far are half-assed Eclipse hacks - and those are the better ones." Your comment is made in reference to "processes", "business cases", "data model" and even "UX", realized natively in an IDE. (And we could add "business rules" too . . . )

      I like to say that a "business process should be a first class citizen of the technology environment within which business is automated".

      "First class citizen for process concepts" is nicely rhetorical, but the practical realization of this is exactly your point: a great IDE for process, case, UX, rules etc. etc.

      Both business and technical staff should be able to manage key business concepts directly and natively, without the painful mediation of code and complexity. As you say the result is "fantastic speed" for the business tool construction cycle!

      So IDE power for business process could not be more important. Ultimately, versions of processes will even end up on executive war room wall projections . . . for management purview and decision.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 25 2015, 10:36 AM - #Permalink
    Resolved
    4 votes

    Agile used to mean something. These days, however, it is just a buzzword to try to make broken companies look better than they are.

    There is a basic marketing rule - if something says "finest" on the label, then it probably isn't. If it was good it wouldn't have to say so.

    Like "innovation", "best practice" and "customer-driven", "agile" is just management speak for "we have a problem getting things done in this company. But I'm one of the good guys - it's the others".

     

    But there is an important thought in behind.

    Back in the pre-computer days of Time and Motion, Lean and Six Sigma, the world was made of physical things. Those things were hard to change.
    All the effort to collate data, add it all up and turn it into a justification for a process was massive. So people only did it once.

    That created the idea that fixed was normal and change was the exception. Something to be done only when you had to.
    And good reason to force it through a rigorous management process which made sure it wouldn't upset the figures which came off the fixed process.

    One reason why animals and plants exist is that we are made up of cells.
    Change is easy - indeed mutation happens all the time whether we like it or not.
    When something changes in our environment, we find that some of us have adapted to cope, or even thrive.
    Survival goes not to the strongest, or fastest, but the one most adaptable to change.
    Like AB testing, really - those who were adapted would survive, the others disappear.

    Our business world is now made up of pixels and bytes.
    Change happens in an instant, all the time, all around us.
    Indeed change is now the default - fixed is the oddity.

    That means we can throw out all those fixed state business models. Porter's Forces, Balanced Scorecards etc.
    Throw out all those Change Management textbooks too - the one which treated change as a rare event to be managed.
    Fixed business models and fixed processes will always be at a disadvantage to those which move forward continually in a state of change.

    What we need to do now is design processes which evolve. Which gather data on the environment they operate in (after all data isn't hard any more).
    Which use this data to AB test continually, adopting the winner each time, then repeating the procedure to create a truly evolving process.
    Always the best option for its current circumstances, yet able to reinvent itself andmove on when those circumstances change.

    That is truly agile. And it is the future of BPM.

    The reply is currently minimized Show
  • Accepted Answer

    Tim Bryce
    Tim Bryce
    Offline
    Tuesday, August 25 2015, 11:07 AM - #Permalink
    Resolved
    1 votes

    True "Agile" programming means abandoning documentation, making it difficult to maintain or modify the program. I do not believe this is the direction you want to go. Instead, better training of the Business Analyst is required. They must learn such standard concepts as defining information requirements, logical vs. physical design, transaction processing, the basic constructs of sequence/iteration/choice, work flow analysis, developing test criteria and test plans, etc.

    References:

    1. http://timbryce.com/
    • Patrick Lujan
      more than a month ago
      Not true, Agile programming does not mean abandoning documentation. As regards documentation, Agile has a precept of "to the necessary degree of understanding," but by no means does it say abandon documentation altogether.
    • Bogdan Nafornita
      more than a month ago
      I push my people into delivering a live and visual documentation. I usually abhor written documentation, unless it's in the code. The user-to-dev communication needs to happen via a fluid and consistent language - that's what I'd call "documentation".

      Not the usual let's-write-until-we're-sure-nobody-reads-this-eventual-legal-protection-waterfally-200-pages-of-screenshots.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 25 2015, 01:39 PM - #Permalink
    Resolved
    4 votes

    I'm wondering how many of these respondents have every actually read the Agile Manifesto, or the following for that matter -http://www.ronjeffries.com/articles/015-aug/manifesto/ - given the pontification being conducted.

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 25 2015, 03:25 PM - #Permalink
    Resolved
    4 votes

    Good subject for a book, frankly! But for the sake of brevity, I'll select just one of the principles of agile development referenced in the question:

    Simplicity—the art of maximizing the amount of work not done—is essential.

     

    “Work not done.” I love that. For BPM, this might mean, for example:

    • Eliminating (or at least vastly reducing) the amount of coding required to produce a solution
    • Taking advantage of data virtualization techniques to hide the complexity of accessing enterprise data
    • Discarding complex paradigms (I'm talking to you, flowcharts) in favor of more accessible models

    If for nothing else, BPM exists to increase the volume of work not done when solving business problems.

     

     

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 25 2015, 03:57 PM - #Permalink
    Resolved
    3 votes

    Agile is a slippery concept. My question is "Why be agile?" in the first place.

    Micro-agile applies to better and faster construction of software artefacts; macro-agile applies to adaptation of enterprise to changing conditions. Clearly it's better to be flexible when constructing complex technologies; Soviet-style top-down waterfall development is inherently flawed (although strangely popular in "capitalist" organizations). As for whole organizations, certainly it's probably a good idea to try and adapt to changing business environments (although it didn't work out too well for Kodak).

    But for agile to work, at any level, requires a concept of identity and purpose. Otherwise, agile and adaptation are just opportunism. Or a random walk. A random walk actually works in nature. Evolution is about the survival of successful adapters.

    But at the individual level, evolution results in failure for most entities. This is just a fact.

    Consider evolution in business. We have seen the death of rather too many Fortune 1000 companies over the past decades. So by all means, lets speed things up, be agile and adapt. But without leadership, we lose our identity, we are only opportunistic and we embrace the evolutionary risk of a single insect. (Investors likely don't want to hear that you are going to be "agile".)

    OK, the original question was not about leadership, but I take it that one cannot ask about agile without considering leadership. In this context, I like the following quote:

    "As a guiding principle, however, adaptability is analytically useless for doing what any coherent strategy must do: specify where we do and don’t play in specific markets and how we propose to win in places where we do choose to play."

    ”There’s No Excuse for Avoiding Strategy”, by Frank V. Cespedes, Harvard Business Review, October 28th, 2014

    • Patrick Lujan
      more than a month ago
      At a holistic level, for this thread, I like this response the best so far. :-)
    • John Morris
      more than a month ago
      Thanks Patrick! Agile is popular, going on at least a decade, and for understandable reasons. So to question the approach "holistically" one must be fair, which I've tried to be. What may I ask is your own overview on agile?
    • Patrick Lujan
      more than a month ago
      On the ground it has always been about, specific Agile methodology and SDLC aside, how to iteratively develop and deliver those "one off" tactical business solutions, but still have an eye for, towards those incrementally building out to that strategic end-state. That's always been the inflection.

      That's the "art" part.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 25 2015, 03:59 PM - #Permalink
    Resolved
    5 votes

    BPM is already agile because BPM implements the agile manifesto.

    “Individuals and interactions over processes and tools” obviously, modern processes and related tools are much better than 15 years ago and they are real enables for efficient interactions between individuals

    “Working software over comprehensive documentation” thanks to modern DSLs (primarily BPMN, CMMN and DMN) a lot of business artefacts are captured directly in executable formats and maintained directly by business owners. No needs for intermediate documentation.

    “Customer collaboration over contract negotiation” modern IDEs are perfectly implementing this by enabling pair (customer & BPM-suite specialist) development of process-centric solutions.

    “Responding to change over following a plan” the combination of classic workflow and case management is the way to do this.

    Thanks,
    AS

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 25 2015, 07:33 PM - #Permalink
    Resolved
    3 votes

    Agility is a wide concept, I will take the point of view of the CEO of a small/medium business who involves in some degree in the tasks of automating and optimizing their business processes. Let's call him Lucho.

    Lucho wants agility when automating a process for the first time, but want it more in the subsequent improvement cycles. So Lucho will find his BPMS agile if and only if:

    • his people model AND EXECUTE the process in the same notation, and one they know (ie BPMN)
    • his people are able to deploy fast between environments (development test production)
    • Lucho and his people should focus on the process; having already resolved (not distracted by) security, platform, connectivity, backward compatibility of the new versions of the process, etc.

    For example, an integral SaaS & PaaS approach as Flokzu BPMS or our INTEGRADOC suite in SaaS mode would be good examples.

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, August 26 2015, 03:30 AM - #Permalink
    Resolved
    4 votes

    Agile is a way (and IMO a pretty good one) to be able to anticipate fast moving developments. However and whatever these developments, you still need to be in control of your processes.

    So, not the process it self needs to be agile per se, but the way you manage them. And IMO this difference confuses many when discussin BPM. Which seems strange to me, as the phrase Management is part of the very acronym...

    • Dr Alexander Samarin
      more than a month ago
      The operative word is "anticipate". To better manage your processes, it is necessary to be prepared that everything related to processes may be changed - events, roles, rules, coordination, activities, forms, services, data, documents, audit trails, KPIs, goals, etc.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, August 26 2015, 04:10 AM - #Permalink
    Resolved
    2 votes

    Key to this is do your research to find the enterprise level software that supports "Agile" build direct from input by users. Then explain to users how it delivers and show how their ideas now matter!

    Once business get over the shock that there really is this new Agile way to help them do things better a new door opens with no turning back....So do that research ask relevant questions and get answers all in business language.......

    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, August 26 2015, 08:26 AM - #Permalink
    Resolved
    3 votes

    Agile implementation if one of BPM keystones; it isn't BPM if it's not agile.

    BPMS technology speeded up business process implementation and improvement by order of magnitude comparing to typical ERP project. From my experience, it usually takes 2-3 months to implement first production release of a fairly complex executable process and 3 or 4 weeks for successive releases.

    Yet today many customers want more:

    1. In many cases (e.g. in M&A scenarios) business can't afford spending 2-3 months on process analysis, design and implementation - they would rather utilize ACM work style immediately ("today") and switch to process models later, with less timeframe pressure and much more processinsight got from the Case Mining. It implies true interoperability and migration capabilities between ACM and BPMN. Most vendors aren't there yet.
    2. People want to minimize professional development efforts, especially at the early stages of the projects. Professional developers and architects should be involved at some point indeed (e.g. to design data architecture, process architecture and integration) but a process tool must be democratic enough to allow a business analyst or even a "power user" from business side to make first prototype without IT. Unfortunately it's hardly realistic with Eclipse-based IDEs.
    3. People don't want to spend time on obtaining computing resources internally, installation and setup - they want to sign up and become productive instantly. Hence PaaS and IDE in a browser. Most BPMS vendors aren't there yet.
    4. Current BPMS are pretty good at developing process applications fast - but only those targeted to internal users. If external participants are involved (customers, partners, 3rd parties in brokerage scenarios) then out-of-the-box process portal becomes virtually unusable and custom portal should be developed - say good-bye to agility.

    So there is a lot we can do to make BPM even more agile.

    The reply is currently minimized Show
  • Accepted Answer

    Maria Paz
    Maria Paz
    Offline
    Wednesday, August 26 2015, 09:50 AM - #Permalink
    Resolved
    3 votes

    To make BPM more agile, you need to focus on the processes!

    That means forgetting about extra programming, code, installations, complex set up, having an already secure infrastructure which already defines user levels and enables permission setting.

    A SaaS BPM Suite that has all that (such as Flokzu) will let you focus on what really matters: the processes.

    • John Morris
      more than a month ago
      Sounds pretty radical @Maria! Forgetting about extra programming?! But people like programming. OK, developers like programming. I see you take a "business comes first" approach!
    • Emiel Kelly
      more than a month ago
      Luckily saas BPM suites never have to make use of stuff that still is done in legacy systems.

      Neither they need data that's hidden is some database with a lot of security.

      Luckily they can OCR, Classify and extract data from incoming documents and add it to a running case.

      And luckily they can create output in any format the customer wants.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, August 26 2015, 02:25 PM - #Permalink
    Resolved
    3 votes
    The purpose of BPM is to enable the transformation of a rigid way of business into an agile way, in the sense of an agile change management. So, the Agile methodologies together with recent tools easy to use, and standard notations, clearly understood by business and IT people, combine perfectly with the purpose of BPM.
    In my opinion, the key point is to establish first a good framework, clearly understandable by all the stakeholders, under which it may foster the BPM discipline by small projects without loss the consistency of global vision.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, August 27 2015, 02:28 AM - #Permalink
    Resolved
    1 votes

    Just FYI: http://blog.toolshed.com/2015/05/the-failure-of-agile.html

     

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, August 27 2015, 03:20 AM - #Permalink
    Resolved
    4 votes

    Oh noes, Agile is dead, too? *SMH

    Sometimes when I come on bpm.com I feel like in a cyberpunk novel: a decrepit graveyard of zombie technnologies, dead frameworks, failed methodologies, half-buried tweeting fridges with rusty USB 2.0 ports, IoT drones flying against a darkened sky of incoming economic crises, and a toxic green AI brain floating around in an augmented reality visor shooting random process tokens into pale, skinny customer passersby.

     

    • Emiel Kelly
      more than a month ago
      Haha, +2

      It would be silent if people cannot bash things anymore ;-)

      Have to be honest that I like to be sarcastic so now and then, but agree it is of more value to help each other applying useful stuff, methods and things and share the experiences.
    • John Morris
      more than a month ago
      Bogdan, are you angling for QOW? Pretty good shot I'd say.
    • Bogdan Nafornita
      more than a month ago
      @John, nah, it's not tweetable :-) (I had to google QoW!)

      we need a bit of levity from time to time. Besides, it's almost weekend! (another bad joke)
    The reply is currently minimized Show
Your Reply

Join the Discussion

Want to join the discussion?

Login, or create an account to participate in the forum.

Top Participants

Dr Alexander Samarin
278 Replies
29/09/2016
David Chassels
270 Replies
29/09/2016
Emiel Kelly
223 Replies
29/09/2016
Bogdan Nafornita
210 Replies
29/09/2016
E Scott Menter
182 Replies
28/09/2016