Pega offers an interesting set of methods and tooling for directly capturing requirements and specifications into the system, called Directly Capture Objectives or DCO. The core of DCO is having DCO sessions where business and IT delegates work out the process flows and draft UI together. From practice I’ve seen that it's not always easy to make it work on the short run. Expectations of the results can be unrealistic and it takes some time for people to get used to the DCO way of working. But don't lose hope because when it starts working, it really gives a good vibe to your BPM project. This blog explains three do's and don'ts for working with DCO.

Read more: Six Do's and Don'ts for Directly Capturing Objectives

In today's market there are more than a few Business Process Management Suites (BPMS). Each has their strengths and weaknesses.

Pega and OpenText (formerly known as Cordys) are two of those Business Process Management Systems, which can be used to model and execute (business) processes. The kind of functionality is the same for both platforms. Therefore, there is a lot of overlap between of the platforms, but as with all similar tooling there are also differences.

Read more: Comparing BPMS Tools: Pega vs. OpenText

During Model-Driven Development projects the question often arises as to why we should document the requirements and specifications. As business owners easily understand the model used during model driven development, it diminishes miscommunication between business and IT professionals. Therefore it could seem sufficient that the product owner and system architect only have to sit together to build a quick POC that will be extended later by the project team.

Read more: To What Extent Are Requirements and Specifications Useful?

In many application development projects it is a recurring problem: The application is documented both functionally and technically inadequate. As a result, the software is difficult to transfer and maintain. Modern development tools try to prevent this problem by keeping software and documentation together in one environment.

Read more: Reduce Transfer Problems with Self-documented Applications

How to make testing in projects with a non-waterfall approach as smooth as possible? In these projects, I first found it difficult to time my testing activities – start too early and retest a lot, or start too late and run out of time.

The difficulty by testing in scrum projects is that testing takes place while development is still in progress. So, how do we ensure that we do not have to test everything (again) when development (thinks to be) finished? Below, I will distinguish between 5 testing aspects and their timing. For each of these aspects there are certain criteria, which help to decide when to start testing.

Read more: Testing in Scrum: Don’t Forget The Timing

Page 4 of 4