MuleSoft Catalyst — Agile Delivery

Centre 4 Enablement Playbook Establishing the Foundation.

Identify Assets to Be Created and Reused Across Initial Projects

Agile Delivery

What does the MuleSoft Catalyst Framework say about Agile? Well actually the answer is not very much! Within the identifying assets to be created and reused across the initial projects it mentions four areas under the banner of Agile Delivery — Backlog, Sprints, Resourcing and Definition of Done/Acceptance Criteria. In my view this is a bit weak and my experience tells me that we need to explore this area in more detail.

• Agile delivery
• Backlog
• Sprints
• Resourcing
• Definition of Done / Acceptance Criteria

The first area mentioned by the Catalyst is the Backlog. You can ask any Scrum Master or Agile practitioner for a definition of Backlog and you will get a number of different answers which may include, but not be limited to, a to-do list of tasks, a list of required features or a prioritised list of deliverables. They will also probably make a distinction between a Product Backlog and a Sprint Backlog. Every definition may be correct and has to be placed in the context of the organisation that the person is working within. But there are some common features which I think we could all agree on.

The Product Backlog will be a collection of requirements, whether they be a to-do list or a list of features, that will be expressed in the form of a User Story or as a straight narrative requirement. We all know as well that the world, and the requirements of the business we serve, never stay still and therefore the Product Backlog will always be dynamic and changing even if that just means it’s being added to all the time. The fact that the Backlog is dynamic and ever changing also leads, inevitably, to the fact that the priority of requirements will change so we will have to find some mechanism to feed the requirements into the sausage machine that we call the development team(s). This is where the Sprint Backlog comes into life. In the Agile world the Product Backlog is owned and managed by the Product Owner whose prime responsibility, beyond defining requirements, is to prioritise and manage the requirements that are presented to the development team in whichever methodology they are using to manage their work, in Scrum this would be the Sprint and hence the formation of the Sprint Backlog. The operation of the Scrum Sprint promotes flexibility and adaptability, as it enables the team to respond to changes and reprioritise based on emerging requirements, customer feedback, or evolving business needs.

We have introduced Sprints and the Sprint backlog so let’s take a look at the second element mentioned by the MuleSoft Catalyst, Sprints. By referencing Sprints the MuleSoft Catalyst is placing the development firmly in the world of the Agile Scrum framework. This is just one implementation of the Agile ways of working, with Kanban probably being the second most popular framework, but a word of warning is required here I believe. This may not be the best development framework for everyone and it is certainly possible to use other frameworks or ways of working to achieve an equally favourable outcome. Do not for one minute think that you need to change your organisations development method to fit in with the Catalyst suggestions, they are just that — suggestions.

I am not going to explore the depths of Sprints, Sprint Backlogs or the Scrum events, or what used to be referred to as ceremonies. Anyone who uses LinkedIn will see articles almost every day on people’s views on Agile, Scrum and Kanban with some people giving their views on what should be used, how it should be used and some even expressing the views that the Agile Methodology doesn’t work anymore. There is an infinite debate to be held here with no right or wrong answers. The Agile methodology was built on four values and twelve principles suggested by a group of people meeting in 2001. They were looking at alternatives to documentation driven, heavyweight software development processes that were prevalent at the time and described their output as “mushy” stuff about delivering good products to customers by operating in an environment that does more than talk about “people as our most important asset” but actually “acts” as if people were the most important. And this is my point as with any methodology or framework, it depends on the people that operate the framework and their ability to mould that framework to something that works for them. Agile is not a recipe to be followed step by step but is a framework or suggested way of working that must be developed by the people to extract the best way of working for those people and that organisation.

What is really important here is that whatever mechanism is used to develop your API’s that mechanism needs to provide a structure and rhythm to the development process whilst containing a sense of urgency or timeboxing of the package of work to be completed. If the package of work is to be delivered by a development team within the organisation then that team should certainly be encouraged to work together, and in a collaborative way, to deliver that work and Scrum and Sprints may well work in these circumstances. But that is not the only way to deliver the work. Certainly, in a post Covid world a team that may have been collocated prior to Covid may now be a distributed team in terms of geographic location and even in term of temporal distribution. In this circumstance trying to get collaboration across distance and time zones may not be achievable and other ways of working will need to be examined. Now, some may say that technology, in the form of collaboration tools such as Microsoft Teams and Slack can be used and that may be true in some circumstances but it will never be as effective as a co-located team of people who have the advantages of personal contact and human interaction. Of course, there is also the human factor to take into account.

This takes me nicely into the next element that is mentioned by the MuleSoft Catalyst in this area and that is a discussion around resourcing. The obvious element here is the human resources, people, who need to get this work done. They need to build the assets that the foundational Centre 4 Enablement requires. As we are all aware people have many and diverse requirements in order to obtain the best output and it has to be recognised that there are reasons, both human, neurological and cultural, as to why some people will not have the mindset to work in a way that suites the Agile ways of working. In my view Agile relies on having an Agile mindset where a person wants to work as part of a team, for the greater good of the team and in a way that sees the continual improvement of the team. These teams are very difficult to build and incredibly easy to destroy and I have personal experience of both of these facets. I have worked in a team that took about two to three years to reach its optimum way of working and about three months to totally destroy through the appointment of one bad manager. Once the team is gone it’s very difficult if not impossible to get it back again. But as I have said there will be people who for one reason or another do not, or cannot, work in this way and there is nothing wrong with this! The real skill here for both managers and the organisation to find a way that does get the best out of people and delivers what the organisation needs while keeping to an agreed budget and timescale. This way of working may involve an internal, self-organising team who do not use the ‘traditional’ Scrum ways of working, although you could still say this team is Agile, or it could equally involve one or more Business Analysts producing a package or work, which may be requirements expressed in User Stories, which is then offered to internal or external development teams to deliver.

The key area here is that there can be many types of resource in terms of Business Analysts, Product Owners, Project or Product Managers, internal or external development teams etc that can be involved. The great teams and the great Centre 4 Enablement will be the ones that find the best way of putting all of these people and resources together to produce quality output at a regular cadence for weeks and years on end. A good analogy would be having the pieces of a puzzle that you have to work with without a picture to work to, you have to draw your own picture from the pieces that are available to you to use.

And so we come to the last element that is mentioned in this section of the Catalyst playbook, Definition of Done / Acceptance Criteria.

In my view there is one major oversight here and the element that is missing is Definition of Ready.

Whether you are working using an Agile framework such as Scrum or packaging work for submission to an internal or external development team the requirements that constitute that package of work must have met a Definition of Ready.

The Definition of Ready (DoR) outlines the criteria that must be met for a requirement to be included in the package of work. It serves as a checklist to ensure that the team has all the necessary information and prerequisites before starting work on the work package. The DoR may include elements such as:

· Clear and concise description: The requirement should be well-defined, with a clear understanding of the desired outcome.

· Acceptance criteria: Specific conditions and requirements that must be satisfied for the item to be considered complete.

· Dependencies: Any dependencies or preconditions that need to be resolved before work can begin on the requirement.

· Acceptance from the Business Analyst or Product Owner: The requirement has been reviewed and approved by the Product Owner or relevant stakeholders.

· All associated technical elements such as database connectivity, network connectivity and security requirements have been resolved.

Failure to meet the Definition of Ready can have serious consequences and will probably lead to blockers being raised in the development process or in testing of the work package. This will inevitably lead to time delays and cost overruns and therefore I see this as a serious omission from the playbooks content.

In association with having a Definition of Ready we now need to look at the Definition of Done (DoD).

The DoD outlines the criteria that must be met for a requirement to be considered done, or ready for release. It ensures that the team has completed the necessary work and achieved the desired level of quality. The DoD typically includes elements such as:

· Code complete: The code associated with the requirement has been fully implemented.

· Unit tests passed: The associated unit tests have been executed and passed successfully.

· Integration tests passed: The item has been integrated into the system and has passed relevant integration tests.

· Documentation updated: Any required documentation, such as MuleSoft Exchange documentation, Support documentation, Change Management documentation has been updated to reflect the changes made.

· Acceptance criteria met: The item meets all the agreed-upon acceptance criteria and has been reviewed and accepted by the Product Owner or stakeholders.

One final point here is to raise the issue of Design Governance and Code Governance. These are incredibly important elements of the Centre 4 Enablement and seek to maintain the quality, supportability, and incremental elements of API development. It is therefore very important to build these elements into the development process described above and I will talk about this in a future article.

Thanks for reaching the end of this article and if you found it useful then please consider following me on Medium.com