Transparency in software development projects is not only important for project managers, product owners or the developers themselves, but for all stakeholders who want to be sure that a project is going in the right direction. Digital solutions are available for agile work with backlogs and task boards, which also support long-distance collaboration. Examples include Jira from Atlassian, Azure Devops Services from Microsoft or Trello. In the end, however, it is only marginally the tools for communication and collaboration that lead to the desired result.
More important are the agile methods and frameworks such as Scrum or SAFe, which make it possible to achieve short feedback cycles using sprints. With regular events such as Sprint Review, Sprint Planning, Daily Sprint and retrospectives, a toolbox is available for such feedback cycles. They can be used to continuously inspect and control the result of the work performed.
Regular reviews of the work progress provide the prerequisite for developing the product incrementally and iteratively according to the requirements of stakeholders, for early detection of undesirable developments, for continuous learning and for improvement. So that feedback from later users and customers can come as quickly as possible, it is advisable to deliver product versions at an early stage that provide a partial benefit for the later product. At least the interested parties should be invited to use and give feedback early. The idea of such minimal viable products (MVP) comes from the lean startup approach.
Agile methods such as Scrum and Extreme Programming provide the processes to realize incremental development and continuous improvement. How can you create a status of the work that is inspected by stakeholders and can thus ensure transparency in product development at all times? Tools and procedures for this are described below.
To see what developers are doing, it’s worth taking a look at where the developers are storing the result of their work – the source code and other file artifacts. This will be version control, in most cases Git. In addition to saving, this and other tools offer other important functions:
Conflict resolution (merging) in the event that several people want to save changes to files at the same time;
a log that stores who changed what and when. Changes can also be undone to restore older, but still functioning stands;
Code reviews to ensure code quality;
synchronize the status in the central repository with the computers of the developers. This offers the possibility to work offline and anywhere. After the work is done, the local changes can be transferred to the central repository.
It is important that the developers regularly synchronize their work with the central repository and merge them with changes made by colleagues. Regularly means at least once a day. This is not only necessary to see the progress and current status, but also to not let the work of the developers involved diverge too far. The result would be lengthy integration efforts that cost a lot of time and have a negative impact on the stability and quality of the software.
This would be the first step: there is a central memory in which everyone involved, regardless of where they are working, regularly save their results. Here you can also check who worked on what and when. Does the source code now need to be browsed to see if the work is going in the right direction? No, luckily not. That would also be impractical. It is better to check the current status of the work in the form of functional software.
- Product & project manager
Generally speaking, developers don’t particularly appreciate it if someone wants to explain to them how to do their job. Because product and project managers often lead development teams, that’s exactly what happens. This can lead to inconsistencies.
David Fox from devRant also has an opinion on this: “Ultimately, in most cases it is the case that product and project managers are in some way the ‘owners’ of projects and processes without the daily challenges and problems of software developers know.”
Just like the product and project managers, development or engineering managers are responsible for leading teams of developers and ensuring that projects are completed on time and on budget.
“In some companies, situations can arise in which the boss is also a member of the development team. In particular, if the boss was a developer himself and becomes a boss after being promoted, there is potential for conflict,” notes Fox.
Software developers do not have to actively look for a job themselves to be bothered by recruiters and headhunters – thanks to the lack of skilled workers. It should be very difficult to find a developer who has not yet caught on with the recruiters.
David Fox particularly sees the persistence of recruiters as a problem: “They call, email them and they simply won’t leave you alone – even when you’re not looking for a job. And even when you’re looking for a job, many recruiters tend to do so about making irrelevant job offers or recommending jobs whose profile doesn’t fit at all – like a job at the other end of the country, even though you’re not even willing to move. “
If there is no documentation, the software developers complain. If it’s too much, they complain and if they have to do the documentation themselves, too. Developers are even complaining about the way other people handle the documentation task.
At this point, all developers should finally agree, as Fox emphasizes: “Software developers want detailed, well-written and accurate documentation – but they don’t want to do it themselves.”
Meetings are not only a problem for everyone else, but also for software developers. Especially when it comes to completely unnecessary, time-consuming and boring meetings. As Fox tells, devotional items are now available that read ‘I survived another meeting that should have been an email’.
- Coworking spaces
With the rise of agility, flat hierarchies, collaboration and teamwork have become part of everyday life in companies – especially for software development teams. However, especially those who work in an open-plan office can usually only do it with difficulty or not at all – say at least the figures from devRant.
David Fox explains: “There is just too much distraction: colleagues are chatting, missed meetings, telephone calls are ignored. There are also a lot of complaints about coffee in the office and other amenities – or the opposite of it.”
Self-explanatory: Everyone has a colleague whom he particularly appreciates. Not.
In the case of software developers, the aversion to colleagues is usually due either to the poor quality of their work or an ego completely lost, says David Fox.
- Job interviews
When a software developer is looking for a job and is invited to the interview, there is usually something to complain about:
“Stupid questions or the solution of tasks that are completely unrelated to practice in the job interview are as annoying to developers as a conversation partner who doesn’t know what a developer actually does,” says Fox.
- Errors & bugs
Software developers deal with errors and bugs day in and day out. That’s why devRant founder Fox believes that developers tick differently about this:
r problems don’t get a positive resolution, but bugs and bugs are fixable and that feels good.”
- Quality assurance
Quality assurance (QA) – or quality assurance – is a critical part of software development. However, software developers often complain about QA experts the same things as about product and project managers, Fox says.
“Quality assurance gets its hands on the product or project when the developers have finished it. That is why they often do not understand what hurdles and workarounds the developers had to overcome in the development process. Obviously, it happens regularly that QA people ask the developers To rework areas that they could handle themselves. “
This is achieved with the concept of a continuous delivery pipeline. It can be used to build the corresponding version of the software from the current version of the code in the version management and to install it in the target environment. Depending on the type of software, a target environment can be a web server or an app store, from which the app can be installed on a smartphone.
The Continuos Delivery Pipeline ideally also installs the required infrastructure of servers, network services, database and web servers. This is done using scripts and configuration files. This approach is called infrastructure as code. Scripts and configuration files also serve as documentation, which is why the documentation and the systems created from it are synchronized. One of the tools for installing and configuring infrastructures in their environments is the open-source infrastructure-as-code tool Terraform. It is also supported by the major cloud providers.
This procedure works best with cloud-based infrastructure (IaaS = Infrastructure as a Service), as provided by the large cloud providers. These solutions are also available for infrastructures in classic data centers. Infrastructures based on software containers represent a particularly flexible and currently popular solution. It is important to save installation scripts and configuration files together with the source code in the version management. Then the software and the underlying infrastructure are synchronized.
Because continuous delivery pipelines play such an important role for modern and agile software development, there is a large selection of tools and platforms. GitHub, GitLab, Altassian BitBucket, Jenkins and Azure DevOps are just a few of the well-known ones. Continuous delivery pipeline installations can be performed manually or triggered by events. Ideally, the installation process takes place without further human intervention. At the beginning, the pipeline has to be set up once and then adapted to current developments. This effort is worthwhile in larger, long-term product developments.
It is ideal if the pipeline is implemented from the start of development. To put it bluntly: the first line of code being developed should run through a working pipeline. Then you are not only informed about the status of the product right from the start, it is also easier and less risky to set up, develop and operate this pipeline.
Software products can usually be developed in such a way that functional product versions are available at an early stage. The Sprint for Sprint software is developed incrementally and iteratively based on user and customer feedback. If a development team reports that something visible can only be presented towards the end of the project, this should be interpreted as an alarm signal.
The client and the developer should have a common understanding of when a software is “finished”. What belongs to this finish is laid down in a definition of done. It specifies which functional, non-functional and qualitative properties a function, a product increment or a release must have in order for it to be considered ready and deliverable. If there is no common understanding here, this can lead to nasty surprises in the course of the project. This is where agile action with short feedback cycles helps. If product stands are delivered early and regularly, you can quickly see whether there are any discrepancies.
Does the software delivered in this way now have to be tested by hand? That would certainly be too time-consuming and is not the most enjoyable activity. There are a variety of solutions to automate the testing of requirements. This is done by programming the tests or writing them so that they can be carried out automatically. Since this is an important function, there are innumerable frameworks and tools. Testing can be automated at all levels and from all perspectives
Accordingly, the tests are defined in different test types and types for different areas of application and target groups. The various types of tests include functional tests or acceptance tests. They are interesting for people who want to test software from a user or customer perspective. End-to-end tests are also possible, but they are usually more complex to automate.
The concept of Behavior Driven Design (BDD) provides an interesting approach. Using a descriptive language, for example Gherkin for Cucumber, requirements are described in a language that is understandable for everyone involved and later implemented and executed as coded tests.
This facilitates the joint creation of requirements and verification of the desired functionality by stakeholders or product owners. In this case, the documentation of the requirements tests the requirements for the software itself. Requirements documentation and tests are synchronous.
There are also unit and integration tests: They test the technical functionality of software. Unit tests focus on the functionality of the code without considering the dependent systems such as databases. Integration tests test the software together with the surrounding systems with which it will later be operated. Tests in this area say a lot about the inner quality of the software. In this context, the value of “code coverage” is interesting. It describes the percentage of code that is covered by tests. After all, functional and acceptance tests are also important, even if they only have the tip of the iceberg in view.
There are also non-functional requirements such as security, performance and scaling. The quality requirements for the software are checked here. Frameworks and solutions, such as Apache JMeter, also exist for these types of tests. It makes sense to integrate these tests into the continuous delivery pipeline.
The installed software is also automatically tested. In the end, not only is the current state of the software available, but the question is also answered as to whether the desired functional and non-functional features have been fulfilled. On this basis, it can be decided whether the software will be installed on the next staging level, e.g. User Acceptance Test (UAT). This can even be continued automatically up to the production level. The software is automatically brought up to production if the quality and functional requirements are met on all staging environments (test, UAT, …) on the way there.
This procedure also works in large environments. Amazon, for example, deploys to its production systems every few seconds. The result should be presented in a user-friendly and clear manner so that the forest remains visible for this amount of tests in front of the trees.
Platforms for software lifecycle management and continuous delivery offer opportunities to display results and status of installation, tests and other activities in a user-friendly manner. This way you can see at a glance whether the current work status leads to a functioning product and whether functional and non-functional requirements are met. It makes sense to choose a top-down approach. An overview is used to quickly see where a product is. This overview can be used to navigate in detailed views, down to individual tests and code changes. This enables developers and system administrators to qu
ickly find problems and their causes.
The delivery pipeline can also make the current state of the software available to users and customers. These don’t have to click through everything; Tests are carried out automatically and the results are clearly available. At a glance you can see where the product is currently.
It is advisable to keep an eye on another topic, especially if it is an important and critical application that should continue to play an important role in the future: internal code quality. This deals with topics such as complexity, coupling and lines of code per method. This topic is relevant if the program code should remain maintainable, expandable and modernizable in the future – and without undue effort and risk of errors.
There are also solutions for this, such as SonarQube, which test the code for quality features, can be integrated into the delivery pipeline and, in extreme cases, prevent code from being delivered that does not meet specified standards. These tools also offer clear graphical reports that provide an overview of quality and critical areas.
With all the great dashboards and reports on tests and code quality, which hopefully always show everything in green, the software itself is still the most important thing in the end. “Working software before documentation” is one of the central agile values. Customers don’t pay for a continuous delivery pipeline or dashboards that show good test results, but for a product that meets their needs, is easy to use, and looks good. The focus should always be on the software produced. It is crucial that you provide the user, the customer and yourself with software quickly and regularly, continuously test it and give feedback.
Is the right thing developed in the required quality? Determining this early saves a lot of money and helps to meet deadlines. This article is only intended to provide an overview. Especially for larger, long-term and important product developments, it is worthwhile to do this undoubtedly high effort. It depends on:
A source code management system like Git, in which everyone involved can check in their work at short frequency and thus resolve any conflicts that arise. Automated code analyzes and manual code reviews ensure that only code flows into the product that meets the required quality criteria.
A continuous delivery pipeline automatically creates the current product version from the current status of the code. This is made available to those interested in the product. Tests and checks for code quality are also carried out automatically in the pipeline. Success or failure of the tests and the code quality check can serve as quality gates as to whether this version is made available to the next staging stage.
Dashboards and reports that present the results of installation, tests, quality metrics and bugs in a clear manner so that you are quickly informed about the status of the software and the status of work.
Working software provides an early subjective, “feeling” whether the development is going in the right direction. Minimal Viable Products (MVP) provide feedback from customers and users at an early stage. Agile practices provide feedback at short intervals. In this way, future work can be re-prioritized and all aspects of the project continuously improved. (hv / fm)