Part 3: How Agile Software Development Can Work

In Part 2, we already talked about the most common mistakes that many companies make when introducing agile methods. In the last part of our "Agile trilogy " we would like to show how agile software development can work after all. The following tips and advice will help you when starting and implementing software projects using agile methods:

Get help from people with experience in agile software development

As an introduction to agile project management, training and online courses are certainly a good start. The four basic principles of the Agile Manifesto are easy to learn. However, this alone is not enough. The manifesto and its meaning must be understood at its core and the paradigms really lived in the hectic everyday project life.

At Sitewerk, we have found that a team with little or no experience in agile project management benefits greatly when an additional person (e.g. a Scrum Master) with practical experience in agile approaches is brought on board. This person can help out in many situations where the team doesn't know what to do. In addition, she can also take on the role of a referee in a way, raising your hand if you fall into old ways of thinking.

Close contact to customer and user

Although the product owner forms the link between the development team and all other stakeholders, such as users, management or customers, it is not optimal if developers are isolated too much. There are requirements and feedback where the meta level (context, feelings, pains and gains) is lost too much when they reach the team via the PO (Product Owner) in the form of a user story. In return, a customer can have a much better understanding of a bug or a complex and seemingly expensive requirement if the developer can explain the complexity in their own words.

It is important that the development team maintains a direct and regular exchange with the customer or user, but also has phases in which it can work undisturbed. It is important to find a healthy middle ground here.

CI/CD (Continuous Integration & Continuous Delivery/Deployment) - A must for agile software development

If you want to involve the customer and the user in the development process and offer the opportunity to give feedback in a timely manner, the process must be adapted to how software is developed and delivered. This is where CI/CD comes into play:

Continuous integration (CI) is a process in which newly developed features are continuously integrated into software in small steps. The highest possible degree of automation and high test coverage are crucial. Otherwise the software would become unstable and such short integration cycles would become impossible.

In the past, software was only delivered three to four times a year, which led to long feedback cycles and thus no agility. If you want to react agilely to the environment and its requirements, the software must be delivered much more often and faster. Therefore, bi-weekly releases are often used today, on which the customer or a user gives prompt feedback. How to deliver continuously → Continuous Delivery/Deployments (CD).

A common project goal and a vision

If the development team only deals with user stories and features, they lack the big picture and the vision for the whole. For example, if I let someone stack bricks on top of each other for 1000 hours without telling them why, they will soon have a motivation problem. But if I show him a photo of a pyramid and ask him if he would like to build it with me, the bricks almost stack themselves. It's the same with a complex software project. The team needs a vision. It has to see what it is working on and what added value is being created in the process.

Create contract models that actually allow agility

In order to be able to work agile and still enable management to plan financially, the following two models of cooperation are available:

Agile fixed price : With this model, human resources (e.g. a scrum team with three developers and a scrum master) and their rate per sprint (or other time unit; e.g.: two weeks or one month) are fixed. In addition, a project budget is defined, which in turn allows the exact duration of the project to be deduced from the team rate. The only thing that can change now is the project scope. And that's the crux of the matter. The project scope should be able to adapt to the requirements that have been added or changed in the project or to the new circumstances. This with 100% financial predictability.

Billing according to effort : With this method, too, personnel resources and their rate are determined. It is billed monthly and worked until the product meets the customer's requirements. This model requires full transparency, a lot of trust and a very close collaboration between the contractor and the customer. If these points are given, this method is highly efficient and you get the maximum out of the calculated time.

Question yourself, be critical of yourself → Retrospectives

It goes without saying that when a team implements Agile software development from scratch, you don't hit the ground running on the first iteration. The paradigm shift takes time and each team has to find the best way for itself first. This also applies to teams that have lived agility for a long time. You can always improve.

In order to constantly improve as a team, feedback and an open exchange between those involved is necessary. Team retrospectives, for example, are suitable for this, which are carried out at the end of an iteration and evaluate the quality of the past sprint. It is not about the output resp. the software itself, but rather soft factors, such as how well the team worked with each other. Both positive and negative things are discussed openly and transparently. The aim is then to improve these points with the help of action items for the coming sprint. In this way, the team can constantly improve, which will have a long-term effect on performance, but also on a good team spirit.

There are countless ways a team retrospective can be conducted. Here are some ideas.

(https://www.funretrospectives.com/category/retrospective/)

Squad Health Check Model

Also interesting is the "Squad Health Check Model" approach developed by Spotify, in which the team can evaluate itself based on various factors and identify a trend.

(https://engineering.atspotify.com/2014/09/16/squad-health-check-model/)

Conclusion

It is important that agility is much more than a fancy buzzword of recent years. It is a paradigm shift, a new perspective, even a new way of working or even living. An agile transformation is never over, just like a digital transformation is. The most important thing is that you start with it, you constantly question and adapt and thus try to improve iteratively. Successfully mastering an agile transformation is not something that happens in days or weeks. It takes a lot of patience and it can take months to years for the new perspective to take root in everyone.