‍

Agile software development is pretty popular nowadays, but it can be frustrating for people in various roles working on the project. Here are a couple of notes on the experience that we faced on recent projects.

‍

‍

The vital role of the Product Owner

It is essential to have a project owner full-time allocated on your software development project, understanding the stakeholder's needs and priorities. It makes the development team's life easier because they do not need to know who is responsible for different parts of the project. Even better if they have a moderate understanding of the technical capabilities of the project, so they can offload some of the distraction from the development team that comes with answering questions related to what is easy and what is not. The development team then will have a single source of truth.

It is not an easy role to fulfill, because ideally, they might need to tell the stakeholders that some of the urgent features need to wait until the next sprint – it is also their job to manage expectations. Suppose they have a deep understanding of the business logic of the project. In that case, they can negotiate with the stakeholders about some conflicting requests with other application features. With the developers' help, they would find a solution that everybody is happy with. If the Product Owner fails to do so, your team will be distracted continuously with urgent requests and questions coming in rather than focusing on development.

All communication from the stakeholders should go through the Product Owner, and hopefully, they can answer some of the questions. Suppose the stakeholders see that the PO forwards emails to different development team members. In that case, they will start to send emails to the development team rather than the Product Owner, which is not ideal from the development team's perspective. These emails can easily be overseen if the developer is the only one addressed, and they can be sick or on holiday.

‍

Keep your software development team focused

There might be cases where developing a feature set can be arranged outside the main flow, and we allocate developers to that particular part of the project. These cases should be more like exceptions rather than the usual way of working. If you still need to develop like this, you might want to ensure that those developers working outside of the sprint know the complete picture of the features they are developing. Otherwise, the product owner or the senior members of the team can become distracted pretty easily to keep up with everything that is happening on the project and supporting the other team members.

It also needs mentioning that it also adds some overhead to the development by keeping your feature branches up-to-date with the main branch, not to mention that this way of working increases the chance of having merge conflicts. 

It also helps your team to be focused on delivering features if they do not have to allocate time on routine tasks like deployment. You can find details about Sitecore continuous deployment by clicking here. 

Plan ahead

You are developing in an agile manner, and you want to build a product with the most vital features required to support your client's needs. But this does not mean that you should not look ahead and plan your features properly. At the start of the project, you need to make several design decisions. 

We decided not to support multiple languages on one of our recent projects – which did not start as an agile project from the beginning. We knew that it would be tough to make it multilanguage later, but we wouldn't allocate time as long as it was not a real need. Looking back, this decision was not our best.

Time went by, and we faced that we need to support different tenants with different content elements. It would have been much easier to cope with this if we said that we would gather our content into some central resource files rather than embedding it into the user interface from the beginning of the project. There seems to be a client coming that requires multiple languages, so hopefully, we can implement this feature (multilanguage support + tenant-specific content). 

So we would recommend that if there is time and resources available to implement something properly, advise the client that it might takea little bit longer to implement this in the better way, but it would be much more effort to change it later.

Invest in the administrative functions as well – make your client support sustainable

If you build aproduct that is easy to sell, your sales team would be most likely to grow very entrepreneurial. Also, you are most likely focused on the client-facing features of your application. Still, as more and more clients want to use your platform, it is easy to get into a situation where you need some development work for each new client you would like to onboard in case of a multi-tenant application. The approach of getting the least administrative function enhancements done would seem an excellent idea at first sight, but it is not sustainable in the long run. This makes your development team frustrated if content needs to be loaded by them because they are keen to create new features and not do repetitive work from time to time.

You can avoid this problem if you also spent some time developing features that help you customize your application to a certain level that is acceptable to satisfy your clients. Besides making your developers feel better, you also do not have to rely on them and make releases to get your client’s content loaded. And honestly, you do not require programming skills to get your client onboarded – once they have done the job to create the functionality for you.

Have a plan for troubleshooting your project

From a security and access control perspective, it is good that the developers do not have access to the production environment. But sometimes, there are issues that you need to debug, and it often requires to do digging into the database or other subsystems. As long as you need to arrange calls with certain people who have access to the database or the logs, and the developers need screen sharing and guidance to the DBA on the other side, it can be frustrating, and it is also not sustainable. You might want to think about creating the process of supporting clients and troubleshooting before going to production. It can be either achieved by having some people access to the production environment who know about the system they are looking at. Another but less efficient way to do this is to create anonymized database dumps, and the person looking into the issue can reproduce the issue in their local environment. If the issue requires a code change, there is a need for a strategy to get the hot fixes to the production environment. 

‍

I hope that you found these tips helpful and they resonate with you. I am even happier if you think that these things are going well on your project, and you can put a tick on your checklist next to them. You can also find some valuable tips here and here.