Author: Isabelle Desmet
Various software development methodologies have been introduced the past decades. Using a systematic approach to software development will make your team work more efficiently to create better products. Every methodology has its own pros and cons. Depending on the company, the project, and the team, you need to make a choice. However, to make sure you can reap the benefits of the chosen methodology, it is crucial to adhere to the principles.
This article will distillate 4 practical lessons learned from a low-code application development project, needed to make agile development a success in your company.
1. ‘Why’ becomes your new favorite word
As with any methodology, the end-users are one of most important stakeholders. We want our end-product to become a solution delivering real value to them. However, end-users often have a state-of-the-art solution in mind that solves certain ad hoc inconveniences – they often not do not look beyond the surface. Additionally, end-users are not necessarily the management or the sponsors of your solution, so the goal of the solution might be different depending on the stakeholder.
To make all parties look in the same direction, contrarily to what you might think, is not to discuss the solution with them, but to discuss the true problems they have. What you should do is luckily relatively easy, just ask ‘Why?’. Listen closely and ask ‘Why?’ again. As many times as needed to help your stakeholders find out themselves what the core of their problem is.
Based on an articulated problem, with a defined root cause, you can identify the business needs that your application should solve, resulting in a clear goal to work towards.
Make sure to align all stakeholders on that goal, as afterwards you will need to keep applying this way of thinking. Also, during the actual development phases, be prepared to ask ‘Why?’ again. You want to guard the solution you are working on and not say yes to requests coming from all stakeholders that are nice to haves and do not add value to reach the goal that gives an answer to the core problem.
Have the problem in mind and think from an end-user perspective to work towards a solution.
2. Create an end-user core team
From start to finish, it is crucial that your stakeholders are involved. To begin with, they need to understand what agile is. Explain what working in iterations means, explain that they are seeing a work in progress. Demos should be interactive and next to the demos it is important to keep engagement high. Involve everyone along the way and have transparency of what is done.
A way to facilitate and ensure this, is to create a core team with a couple of enthusiastic & motivated end users to serve as a sample. They will:
Always attends demos.
Test the application thoroughly before production releases.
Spread the word about new functionalities and answer the first questions of the whole group of end-users.
Work incrementally on a user manual for the application.
This will help facilitate the change management, post-go live adoption and will make the success of your solution increase.
3. Guard the scope & backlog
Agile software development is not project management. Your time & costs are fixed, and it is the scope that can be variable. So, the challenging question is: ‘How flexible can you be in scope with the set timing & team set-up without losing value and quality of your solution?’
To deal with this constant juggling of scope, it is important to realize that stakeholders always want more. Whether it be the end-users, the sponsors, management… at one point they all want more. This is starts popping up after releasing an MVP. Firstly, user feedback will increase as the application is live and becomes tangible. Secondly, the application receives attention and interest beyond your small end-user group – across departments or the organization. Therefore, it is likely more people would like to make your solution also solve their problems.
To deal with this, your team needs to decide on an endpoint and a set of functionalities they could deliver within a certain timebox. That is the scope of the solution that is set to be delivered. So up until this is done, you should not play with everybody’s desires and stick to the solution that was decided on. If you do not do this, you most likely lose value and quality of the solution.
Next to that, your backlog is crucial during agile development. Agile often seems to be used as an open door to throw everything somebody thinks about on the backlog. So, guard your backlog well! Groom and prioritize your backlog constantly. When your scope is delivered, the backlog can serve as window shopping for new functionalities.
Agile gives the opportunity to react fast and deliver value fast, piece by piece scope can be increased, but you have to be honest what is realistic and guard the scope with all effort.
4. Agile does not mean quick.
Last but not least, it is important to note that agile does not equal quick. The delivery time of your solution will actually be more or less the same as using other methodologies to do software development.
However agile delivers small, predictable & workable pieces of your end product. This makes it easier to assess required effort from the start, it will set realistic expectations & allows you to deliver a workable product early on. The latter will allow you to gain quicker user feedback. Implementing this feedback from the beginning gives you a better end product.
In short, we found out that agile is adjustable, it is more efficient, and it answers the true business need more accurate (at least if you did lesson learned 1 right). Hence, in the fast paced world we live in today, doing agile is the best way to tackle problems, deal with changes and realize your solution. Quick, quality impact is what it therefore stands for – if you do it right 😉!
If you have questions or want to know how BrightWolves can realize an agile digital transformation, then do not hesitate to reach out to Sven Van Hoorebeeck or Isabelle Desmet!