Webinar
56:55 Mins
DCO (Directly Capture Objectives) & Microjourneys™: Real-Life Stories from Business A...
This business architect event was originally recorded on Tuesday, January 25th 2022
Replay
Overview
Description: As a Pega BA have you ever wondered - are you doing DCO well? Are you breaking down your customer journey right? You're not alone. We as Pega Business Architects are often asked these questions, so join us to hear how Business Architects like you have successfully applied DCO and Microjouneys to help deliver great outcomes.
Let's keep the conversation going! If you have any additional questions for
reply here to let them know.
We hope you understand we couldn't get to every question during our Q&A session, but we'd like to provide answers to as many as we can.
Check them out below:
With the world being completely virtual, how do we make DCO (Directly Capture Objectives) effective in a virtual world?
The key challenge in the virtual world is online fatigue - so this means that we need to keep front of mind that the session should only include those that can directly contribute to the topic in question. Additionally, the session should only be as long as is absolutely necessary. We need to make sure that the environment is as inclusive as possible and large groups make interacting more difficult. For the longer sessions (sometimes they are required) another really important aspect is to ensure you account for breaks. Holding concentration during video calls can be more difficult as the sessions extend over the 60-minute mark. Another tip I have found useful is to make sessions as active as possible - try to structure the session so that there is some hands-on work for the participants that is aligned to achieving your goal. This is where the collaboration tools are highly effective.
Having ensured the logistics are correct - make sure that all parties are clear on why they are there and the purpose of the session. When running the sessions make sure to cut out noise and speak in a common language that everyone can relate to irrespective of their skillset. It's helpful to engage SMEs/POs by stepping through the system for a playback resulting in a richer experience. To get the SMEs (subject matter experts) involved you could ask them to try run through the system. As we say all the time - make extensive use of the visualization tools that drive engagement and collaboration.
When I first started in Pega DCO was delivered in 1 of 3 ways, Direct into Pega, Prep and Review or the Whiteboard approach. Has this changed?
It is less about how it has changed and more about how it has evolved. We see DCO as a continuum that starts with the very early conversations and extends through the life of the project.
For us, DCO is the holistic experience that includes User story refinement, education and enablement, visualization of the customer experience, and active engagement with the application from the very start. It is collaborative from the get-go and ensures we can adapt and respond to our collective learning collaboratively, quickly, early and from a common reference - the application itself. In combination, this is a powerful way to work to break down the traditional barriers between business and IT. This is the key that brings the business team and the technical team together in a way that ensures the expectation gap between what is asked for and what is delivered is kept to a minimum from the very start.
Having said that we recognize that DCO can start with the equivalent of the Prep and Review or Whiteboard approach to explore new and forming ideas in a dynamic and lightweight collaboration tool and then progress to capturing into Pega as soon as possible. Having said that, it is worth noting that as App Studio is becoming more and more intuitive, the opportunities for starting the prototyping very early in the business conversation is becoming a reality. Sanket gave a good example of how 3 teams used slightly different approaches to achieve the same goal of alignment between business and IT.
In summary, the idea behind the evolution is that we know it is becoming simpler and easier to use App studio to capture directly into Pega and we need to utilize that option as much as possible, where this is not possible however we recognize that with the use of other tools like Mural etc. to really visualize & illustrate a point, show value we can keep the business and IT aligned through all our conversations.
When dealing with a mature application, how does App Studio usage for DCO work? There are complex layers of technicality already built and using the App Studio becomes a challenge. Any suggestion on how we can deal with this?
This is a fantastic question and important to understand for the ongoing success of App Studio usage and more importantly how we are Business Architects can fit into the delivery of an application with DCO.
As your question implies, App Studio is a fantastic tool to accelerate delivery during Discover and Prepare phases. The visual models and quick time to configure the easier use cases, or quick wins, is suited to this Studio. As your team grows, as your application grows there are going to be more complex layers and it's important to understand that App Studio may not always be the answer when it comes to DCO so you should carefully consider your options.
Yes, there are a few ways of handling this situation. In my experience, I have used two different approaches.
-
Get your LSA (Lead System Architect) to create a ‘DCO app’ built on your client application but separate to the Technical Development app. This might all sound a bit technical, but it allows you to work in an isolated and controlled way. You can see what user stories are complete and merged but no inflight work from developers will break what you do. On top of that, you can make changes without interrupting sprint work. In this kind of model, your DCO app work is more ‘reference’ for the user stories you discuss in the DCO. You can take screenshots or refer developers to this app to help build consensus for a user story.
-
Use App Studio to work alongside a development team in the development application but create a DCO branch. This is the opposite of the above and as such the benefits are reversed – you see everything that developers are working on, and they see yours. In this kind of model, you may meaningfully contribute to development. However, this is not suited for large development teams where you might clash with ongoing work.
-
Use App Studio for playback and show & tells, the important aspect of DCO is the collaboration and visual models. If you can use App Studio to configure and develop the application great but the key for Business Architects is alignment and trying to bring to life requirements. You can still do this without configuring changes live in App Studio and/or using other tools like virtual whiteboards to design & annotate processes as you like.
All these approaches bring with them their benefits and constraints. Your current project delivery, platform version, application structure and general working practices will affect your choice of approach. The key to success here is to make sure there is a close working relationship with your LSA (Lead System Architect).
Having said the above, we think this is a great topic for a deep dive webinar - we will add this to our topic list for 2022. In the meantime, if you get a chance to watch a replay, some of this is explored in January’s CLSA Webinar: The Value of App Studio. Most of this is not too technical and we even have a Business Architect presenting!
If the BA does not record the user stories and the case type in Pega App Studio - does that mean it's not DCO?
For us, at Pega, we do not limit the definition of DCO to the BA activities in the Pega Platform. As Sanket mentioned DCO is a mindset of how to work in a continuous cycle in collaboration with the business team. DCO is inclusive of all members of the project team including the system architects, testers, and user experience designers. As mentioned in the previous question above extends beyond user story capture and although it is ideal for us to capture directly within App studio, irrespective of where we record the User stories the key to success is the collaboration and the discipline of REPEATEDLY collaborating, iterating, and validating across all aspects as we progress through the Discover, Prepare, Build, and Adopt phases.
We have a real difficulty with our customer adopting DCO - they insist on using their own backlog tool which means that we can't see the user stories in App Studio - how do you recommend we address that issue?
Using Agile Workbench is key to solving this issue for those situations. Additionally, for those projects where the backlog management tool is Agile Studio or Jira, Pega has an interface to link these tools to Agile Workbench. When this link is established user stories captured in Jira/Agile Studio are automatically updated in Agile Workbench. Developers can then directly assign the user stories to the configuration they are doing in the application. This brings huge benefits for traceability.
A further benefit when using Agile Studio as the management tool includes the facility for any Feedback and Bugs created in Agile Workbench to be automatically created in Agile Studio. Using Agile Workbench in this way means that the testers/business teams can capture/record screens using Agile Workbench and attached them to the bug or feedback item which is then seamlessly available to all users in Agile Studio or Jira.
What is the role of DCO when the client enforces the use of a third-party tool such as Jira or Rally to keep track of the requirements?
This is a great question and I think the combination of our responses to questions 2, 4 and 5 above covers a number of aspects as to the role of DCO within the entire lifecycle of a project including that of requirements management in other tools.
Beyond what we have mentioned above it is important to remember the experience of working in App Studio and bringing the solution to life early in the delivery cycle in collaboration with the business is the key to gaining the trust of the business and crucially improving their ability to help you help them to achieve their outcomes
A key message for us to our community on DCO is that it is a holistic experience that is not limited by the use of third-party backlog management tools. You can still use any tool to track requirements as long as we engage the business using more visualization practices within DCO. The stories relayed by Jon and Sanket on the call are a great example of this in action.
Our product owner refuses to use the system or demonstrate the system - how have you addressed that in your projects.
This is not uncommon. There can be situations where the PO (Product Owner) is either still looking at things from an older system perspective or is not fully adopting the usage of Pega. In projects like Sanket mentioned it is critical to educate the PO as much as possible, also ensure there is an enablement plan to do the CPBA or other courses weaved into the plan. What has worked for us in the past is the BA lead the show and tells a few times to start off and eventually pass on the baton to the PO as this will help them not only with learning the system but also to own the application after Go live.
What are your learnings from the Microjourney based approach of requirement gathering in the projects?
The biggest learning was discussing the delivery, backlogs, roadmaps using Outcome focused terminology and not technical terms such as case types, data, etc. This resonated straight away with the PO(s) and the business. They could easily identify the value each Microjourney™ would deliver without any ambiguity. This led to huge buy-in and delivery ownership from the business much earlier on.
Another recommendation is following the 80:20 rule. With that what I mean is, start with the Microjourney that works for 80% of the scenarios, and then get the remaining 20% out later. In many cases, the 80% workable solution automatically handles the 20% fallout once you start building the Microjourneys™ in an optimized way. This ensures that your focus is on tackling the most important business challenges upfront and build the solution right.
What is the difference between micro journey vs macro journey --> how it's mapped to work type/case type?
At Pega, we think in terms of end-to-end customer journeys rather than macro journeys. For us, we refer to Forrester to help us with the definition of that.
"A journey is the series of interactions between a customer and an organization that occur as the customer pursues a specific goal." — Forrester
Microjourneys™ on the other hand, are a part of the overall customer journey. They are the life cycles, or units of work, that deliver a meaningful result to customers and users. As Sonakshi and Kev mentioned on the call, Microjourneys can be of varying sizes and complexities and with that, they can be represented in Pega through one or more case types, personas, and channels.
Our Pega Express Delivery - Microjourney defined topic within our Pega Academy mission provides some excellent guidance on Microjourneys and how they relate to Case Types, Personas and Channels
I find that it is quite difficult to know when a microjourney is too big - My Product Owner keeps adding features to the microjourney and I'm not clear on how to find the line when it's too big. How do you know if your microjourney is too big?
At Pega, we like to keep our Minimum Lovable Products (MLPs) to circa 60-90 days. The idea behind the little and often approach makes it easier to keep the focus on what is important to get the greatest impact from the work undertaken. As Keval mentioned on the call the additional benefits extend to making the whole build cycle much easier to manage, testing much easier to complete and the overall delivery risk much reduced.
Our advice when scoping the Microjourneys™ is to aim to achieve releases of capability and the associated value as frequently as possible, with that, where you find your Microjourneys are extending beyond 90 days to release consider options to reduce scope by restructuring the Microjourneys for example by product type, customer type, or a combination of both, whichever may be relevant to your industry and project.
If the circumstances are such that you are creating a foundation and the MLP (Minimum Loveable Product) extends beyond 60-90days then it's really important to make sure that you aim to keep the releases as short as possible. Also, try to make sure that every additional feature added to the scope has a very clear link to the outcome that has been agreed.
How does the concept of microjourneys work for a big enterprise solution, where everything is required on day 1?
Yes - we often see projects start with the premise that the entire solution needs to be delivered as a big bang release. The key to breaking this mindset, as Keval and Sonakshi mentioned on the call, is to orient the business to focus on the outcomes they need to achieve and then from this, the customer journey(s) that deliver on those needs.
Within the context of the customer journey, the Microjourneys™ readily become evident along with the opportunities to break the big bang requirements into a series of releases (MLPs) prioritised based on their contribution to the outcome. The Microjourney is the construct that helps us achieve that focus and ensures the release retains the customer in the forefront of the solution throughout.
Is a microjourney an EPIC?
That is entirely dependent on the structure of your backlog. At Pega, we regard an EPIC as a grouping of user stories. Given this very broad definition - a Microjourney™ can be an EPIC. It is important that on your projects you agree on how best to correlate your user stories to your Microjourneys to keep the traceability intact, aligned to your agile working practices and the backlog management tool you are using.
In our experience, we have also identified Microjourneys as themes or features. On some of our projects the EPICS became too large, covering many different types of functionality, and as such the traceability to the Microjourney was lost. Adding themes into the mix helped us manage the backlog and keep the different reporting perspectives intact.
How does the concept of microjourneys apply to a marketing project?
We have a great blog Be a hero: How-drive-successful-11-customer-engagement-implementations written by Mark Davies on our Pega Community Blog website that answers that very question.
Is there any material available to start off defining any Out-of-the-box MJs for any of the applications?
Yes, on the Pega community website there are sample Out-of-the-box journeys for certain applications e.g., Pega Customer Services Financial Services (CSFS) which defines the capabilities that an Out-of-the-box CSFS has along with (most commonly used) sample Microjourneys™ using those capabilities that can be leveraged as a starting point to build upon. You can access the community page using the link below;
https://community.pega.com/products/customer-service-financial-services
How do different Microjourneys join together later to achieve the big outcome?
A fundamental tenet of our Pega Express Delivery approach is to start with understanding the business outcomes first. This ensures we focus our energies and solutions in accordance with what is most important to the business and their customers.
With the overall business outcomes identified, we progress to identifying the customer journeys that are contributing to achieving those outcomes and we Kev and Sonakshi shared with us on the call – we break those customer journeys down into Microjourneys™. Working forward from business outcomes to customer journeys and then to Microjourneys means we can maintain the traceability of the Microjourney’s contribution to the overall outcomes in an unambiguous transparent way.
For more information try our Pega Express Delivery Mission on Pega Academy.
File Attachments