DCO Lessons from an Enterprise Programme

When I joined Pega around 3 years ago, I was very familiar and experienced with running backlog refinement/elaboration within an Agile framework, but the concept of DCO (Directly Capture Objectives) was somewhat alien. Initially, I had many conversations within the Pega Business Architect (BA) community as to what defined DCO, and the answers varied, with everyone applying their own spin to the concept. So I found myself without a clear direction, and fell back on old, reliable, SCRUM-based practices.  

Since those early days, our Pega Express™ approach has established clarity, continuity, and a more practical vision of DCO. It is now a concept of strong collaboration between IT and business, encouraging co-production and a feedback loop that ensures that the value and design of a solution is clear - using the most appropriate tool at the right time to support the process, instead of constrain or confuse it. But in this blog post I’m not going to repeat what has already been more eloquently described here.

But in practice things aren't always so straightforward. And against the backdrop of a large-scale, public sector programme with multiple Product Owners (PO)s, multiple delivery teams, a pre-determined customer view of their requirements and the numerous Microjourneys™ to be delivered as part of an Minimum Lovable Product (MLP), how can DCO be best applied, and is the concept scalable?

These are questions I asked myself whilst working for a customer where, acting as a Lead Business Architect (LBA) across multiple, parallel-running projects, I needed to apply the Pega Express approach and DCO. Inevitably I learned a lot, and I captured a couple of these experiences, including some key takeaways that I hope will provide some benefit. So for this blog, I’ve distilled these takeaways into 3 areas in which can set you up for success:

1. Work through the requirements list
2. Do the basics well
3. Manage the scale

Work through the requirements list

Initially, my team was presented with a long list of detailed must-have requirements, without any context or priority, which the business had spent many months focusing on. These requirements were often based on the functionality provided in an existing system. Tackling them within the context of DCO was a challenge, but we found success by adopting the following practices:

1. Specify by Example. Don’t gamble on discrete requirements when using DCO. Push for the use of testable, business scenario-driven examples, or executable specifications. These provide an objective description of a business need and serve as a common language across both technical and business teams, and can demonstrate value. As an added benefit, examplses and specifications can eventually be used to automate acceptance level testing.
2. Don’t Fall in Love with a solution. It’s easy to focus on ‘solutions to implement’ in support of a requirement, rather than ‘problems to solve.’ But before you start directly using Pega software to clarify how a potential solution could be implemented, ensure that there is an actual problem that needs solving. And make certain that you’re not just rebuilding a feature just because it already exists for the customer. During the DCO session you should aim to build a clear understanding of a particular problem (see Point 1), and only once the whole team is clear can a solution be implemented. Remember that not all problems are worth solving.
3. Understand the Value. In any discussions on how best to deliver value quickly, ensure that you fully define the ‘Why’ statement in a user story. This will give the development team the needed context and clarity to provide accurate and useful estimates, and then to guide prioritization. This leads to my next point…
4. Estimate and estimate again. Ensure that you keep estimating the user stories that are currently without estimates, so that the PO can use their value to understand the cost to the project. This should be the true overall value, which will inform Sprint Planning. Focus on a shared understanding when estimating value, and not just numbers.

Do the basics well

We have all inadvertently been involved in the global experiment of enforced remote working for the past two years, which has obviously introduced challenges. My team had to pivot quickly, so we immediately established a “Ways of Working” charter across the account, which covered a large number of operational areas and also focused on DCO. Within days, we had implemented the following guidelines:

1. Know your audience: Keep the audience for the DCO small. This sounds obvious, but since working remotely I’ve been part of DCO sessions that suddenly had 40 people in attendance. On the other hand, the audience should not be so small that key voices are missed out. And make sure that if architects are part of the session, they actually do provide some input. Too many times, the technical input only comes at the point of sizing. It might take a little time to find the right audience, but persist in creating a good invitation list and it will pay dividends.
2. Have a consistent and clear approach: In the ongoing environment of remote working, setting a DCO cadence that is both realistic, achievable, and that delivers the required value is vital. Clearly communicate the features to be covered at least 24 hours before the session, to allow the business to prepare and to ensure that you set the expectations that you will all exit the session with the required outcomes. 
3. Timebox the DCO session: Although you could spend hours discussing backlog items, I’d suggest capping your refinement meeting at about an hour and a half. This much time will motivate you and the development teams to stay focused and keep the conversation on track. Sometimes, when we know we have more time, the conversation can deviate from its initial purpose into edge cases – business stakeholders often love talking about the complex rather than the high value, and so setting time limits can held curb this. We’ve even used 15-minute time boxing for specific backlog items, which also worked very well.

Manage the Scale

Within this particular client, we commenced multiple projects over the last two years. Each project was either built on, or adjacent to, another Pega application. On each occasion we were presented with a new audience of stakeholders and subject matter experts (SMEs), a different priority of needs, and varying levels of experience with both Pega and Agile methodologies. So how did we tackle the day-to-day operational model for DCO? Well…

Think about creating a ‘Platform’ Team. Establish a governance-based ‘Platform Team,’ not only to act as assurance to our Partners - who will also be running DCO - but also to drive best practices, communicate and demo reusable components across projects, and manage customer enablement. This allowed us to demonstrate the value of re-use, and to establish a common understanding and consistency across projects.

Some of these tips may seem obvious, but hopefully they ring true and will help guide you towards successful DCO sessions. DCO is a great best practice for creating quality user stories in a collaborative way, and it has been fantastic to experience such rewarding sessions in my Pega projects. Why not take the Pega Express academy mission and learn more about how you can apply DCO and many other best practices to your deliveries?

Related Resources

• Pega Express Delivery Approach

• Microjourney Defined

• Directly Capture Objectives

Don't forget 

• JOIN THE CONVERSATION on Collaboration Center 

• FOLLOW @PegaDeveloper on Twitter 

• SUBSCRIBE to the Pega Developer Podcast on Spotify or via RSS