Close
Written by

Paulina Sielska

Low-code development in the eyes of a Business Analyst

At the end of February, we had an initial visit to a store which sells luxury products. Three weeks after the meeting, we’ve had the first planning session and three months later, working together with two developers, our team was able to complete the development of a CRM solution.  This included the UAT phase as well. So how did we manage to do all this so quickly? The answer is simple – Agile & Mendix!

Low-code – expectations vs reality

When I heard about rapid development for the first time, I thought that it may be more suitable for internal products, where a “feature” is more important than User Experience. I immediately thought about User Interface limitations and desktop-like applications, which were in standard use over 10 years ago. I heard developers saying: ‘Meh, this is not even programming and the performance will be poor’. In my mind as a Business Analyst there was only one sentence: ‘Hey, what value can I bring to the customer despite this limitation?’

All my fears turned out to be unreasonable and the power of Mendix really impressed me.

I have many years of experience working in Agile. Whenever it is possible, I try to deliver value to the customer within the first sprint. How much value can two Mendix developers bring in two weeks? Well, a lot! As a business analyst you really need to be prepared for it. The communication plan needs to be in place, so that you have meetings booked upfront with the stakeholders. On the other hand, Mendix allows you to apply changes quickly, so you can leave a gap for an improvement in the future. You don’t need to specify too many details when drafting acceptance criteria for a user story.

Illustration of low-code development

Working in a new reality

At Objectivity, we have a meeting called a Triangle Meeting. It is an informal meeting during the sprint, where business analyst, developer and tester talk about a user story before starting the development. Can you imagine my surprise when during the triangle meeting, I could actually see the developed functionality? It shifts the communication more into live coding.

The biggest challenge was to prepare the significant number of requirements which would be ready for refinement with the team. Beside the impressive pace of development, there are a lot of components readily available to use within the Mendix store. For example, within one two-week sprint, we were able to develop an email and templating solution which allows users to build flexible HTML email templates in order to create marketing campaigns.

Facing the challenges

In one of my previous projects, we had five business analyst preparing requirements for four development teams. We struggled to collect requirements from distributed parties and make them ready for the team. Rapid development wouldn’t solve that issue, but we could have probably developed the same features with one team only and then the burden of communication would not be so heavy. When you have four development teams, you obviously need to scale scrum. There are a lot of synchronisation meetings required and all scrum ceremonies must take place for the project to succeed. With only one development team, it feels more like a start-up – dynamic and fun.

There was one more important factor that led to a successful completion of the project – the customer. Our client trusted us and agreed that we don’t need to specify everything upfront. It is important to understand that when you work in Agile you can focus on delivering the best possible solutions within budget instead of spending a lot of time on specifying requirements in detail.  I can say from experience that spending loads of time estimating and committing to develop features which may no longer be valid after few months is not the road that leads to success.

The result and customer benefits

Coming back to our Mendix project, at its kick-off, we had an opportunity to run Scrum training for our customers’ employees who were involved in the project. We took our agile coach on board and were given their full attention for 2 days. They were committed enough to put aside their daily tasks and fully embrace the training. Within two days, they understood the scrum process, the pros and cons of affinity sizing, the importance of the refinement session, backlog management aspects and the power of feedback.  Thanks to this training session, our cooperation improved significantly because suddenly we were using the same language.

Finally, I want to mention the UAT phase. With Mendix you can apply changes almost immediately. UAT changes are often about improving UI and changing labels, but sometimes also about more complex features. It’s really satisfying to see how positively our customer reacted when the changes we had discussed during a daily the day before were already developed and deployed on UAT environment the next day.

It was a great experience working on this Mendix project. Having a User Experience specialist and User Interface developer in the team is a game changer in creating products that users will love. Within three months, we’ve developed a user-friendly product, with a slick customer-face responsive design, which can be used on PCs and tablets.

Share this post on

Tags

One thought in Comments

  1. PBS

    Great blog Paulina, thanks for sharing 😃

    Limiting work in progress is always important and it can sneak into our lives in many ways. I loved your comments about time spent estimating and committing to deliver features that will become irrelevant.

    Mendix and agile seem like a heady mix!!

    Reply

Leave a Reply

Required fields are marked *

Read next

Getting insights from the ABSL Summit

For years the majority of Objectivity’s growth was organic. I am confident that so far, we have done a pretty good job looking at our people, clients, projects and GPTW results. However, there is about 700 of us today and we are not living in a vacuum. The world is changing fast and there are many great companies around […]

Read more