Blog List

Quality rocket

How do you find the right balance between quality and efficiency when developing a software product? If the quality is too low, it will reduce the acceptance of the product among your target group (stakeholders), significantly delay the development time and cause additional costs as more errors have to be analyzed and fixed. A level of quality or quality assurance measures that is too high and no longer delivers any added value to your target group creates unnecessary development and production costs. Both extremes, too low quality and too high, affect the efficiency of product development as development time and costs increase.

The key is to find the ideal level of quality! This includes precisely understanding the needs and expectations of the target group, prioritizing the development of product functions and introducing or expanding appropriate testing procedures from the beginning of development. This means that deviations from the quality criteria and thus errors are detected early and can be remedied.

Here are some tips for achieving the right balance of quality when developing software products:

  1. Define clear quality goals: Set specific, measurable quality goals that align with the overall project goals (e.g. functional and non-functional requirements).

  2. Prioritize quality activities: Identify the most impactful quality assurance tasks and allocate resources accordingly.

  3. Automate as many processes as possible: Use automated testing tools (continuous testing) to optimize the testing process and detect errors early. Automated deployment (continuous deployment) helps you achieve the quality goal when rolling out the software. Automation saves time, resources and therefore money.

  4. Engage stakeholders early: Work with customers and other stakeholders to collect feedback and ensure the product meets their expectations.

  5. Measure and monitor quality: Continuously track quality metrics to identify areas for improvement and maintain a high standard.

  6. Balance quality with time and cost: Find the sweet spot where quality meets efficiency without compromising. Start from the stakeholders’ requirements for the product.

  7. Apply continuous improvement: Take an iterative approach to quality, constantly refining and improving the product over time.

  8. Communicate effectively: Promote open communication within the development team and with stakeholders to promptly address quality concerns (risk management). Establish a positive error culture in the team/company.

  9. Strengthen the team: Provide the development team with the tools, training and support they need to deliver high-quality software and remove impediments early on. A retroperspective helps to uncover circumstances that are blocking the team at an early stage.

  10. Leverage external expertise: Reach out to experienced quality assurance experts to uncover product quality or quality assurance issues and resolve them with professional help.

retrospective

Retrospectives are the ultimate and indispensable tool of the agile team. If you do retrospectives correctly, you can increase your team's satisfaction and productivity using simple methods. All too often, the potential of retrospectives is often not exploited at all or not fully, although the advantages of a regularly conducted retrospective are clear:

  • It offers your team a platform for reflection, dialogue and improvement and promotes a culture of continuous learning.

  • By increasing effectiveness and productivity, team performance is significantly accelerated.

  • Obstacles (Impediments) that slow down the entire team are identified and can be eliminated.

  • The mood in the team can be measured and improved regularly. This avoids stress and dissatisfaction at an early stage.

  • Mutual appreciation (kudos) within the team is encouraged.

In order for a retrospective to be carried out successfully, you should consider the following points:

  • The retrospective should best begin with a mood survey in the team (team radar). This also helps to uncover the crucial obstacles and problems later.

  • The retrospective is a team event where personal openness is important and should therefore only be carried out by members of the team to avoid external influences.

  • A retrospective is a team-building event where respect and appreciation of colleagues comes first. Finger-pointing and blaming have no place here.

  • To uncover obstacles and problems together, you should use an established method, such as 'Mad Sad Glad'. The best way to do this is to write your problem topics on cards (e.g. Post-it), stick them on a whiteboard and finally prioritize them.

  • Only select as many of the problem topics as you can actually work on or eliminate by the next retrospective. The topics with the highest priority are always processed first.

  • The solution to remove an obstacle is discussed in advance in the team and a person responsible for each problem issue in the team should always be appointed to take care of it.

  • The team also tracks the progress of a problem topic in each retrospective. To do this, you should show in the retrospective which topics have already been dealt with and which could not yet be eliminated.

 

YAGNI principle

The development time in projects is expensive and should therefore be used as efficiently and as value-adding as possible. To do this, the development goal should always be kept in mind and only the product functions required by the customer or stakeholder should be implemented.

Basically, the YAGNI (You Aren't Gonna Need It) principle is a simple principle that is difficult to adhere to in practice. Software developers in particular tend to quickly add unplanned functions.

If functions are built into the product that are not required by the stakeholder, this results in a number of problems for the product:

  • Since the additional features do not deliver any value to the customer, they will most likely not be willing to pay for them. In addition, the development time for the product is extended. Both will have a negative impact on customer satisfaction.

  • The agreed product scope changes (scope creep) and becomes more difficult to plan.

  • Tests must be developed and documentation written for the additional functions. In the course of the product cycle, these points also have to be adjusted, which results in additional maintenance effort.

  • The complexity of the product increases without benefit and the risk of errors in the software increases.

In practice, it is usually not completely new functions that are built into a product. Often I experience that something is built in "foresight", either because the specification is not yet completely finished, but something has already been implemented, or because it is assumed that the function will be needed in the future. However, it can also often happen that functions that are no longer required are deactivated or only partially removed. This approach involves additional risks:

  • Tests must already be implemented for the new or unused functions, which means additional effort.

  • If no or insufficient tests are implemented for the unused functionality, this represents a significant quality and security risk in the software, even if it is not yet used. In addition, system or exploratory tests are missing for unused functions because nobody uses them or can use them.

  • The complexity and memory consumption of the software increases without benefit. This is a particular problem in the embedded systems area, since the software here has to be developed in a way that conserves resources.

The YAGNI principle is easy to apply if the following points are observed:

  • Only functions are installed for which there is a comprehensible requirement from at least one stakeholder. If a requirement or specification is unclear, this must be clarified in advance.

  • Choose an architecture that can be easily scaled or adapted in the product cycle, e.g. through software updates. This reduces the pressure in development to plan or incorporate functions that are not yet precisely specified.

  • Completely remove features from your software when they are no longer used.

  • It can be useful to regularly use tools or a review to find the parts of the software that are no longer be used so that they can be removed later.

 

 

Tags: ,
DRY Principle

Today I am reporting on another proven principle from my projects, the DRY (Don't Repeat Yourself) principle. Most developers are, or should be, already familiar with this principle.
In my experience, however, applying the principle in a project can bring you real benefits and greater efficiency.

The DRY principle is mostly associated with software development. The principle was originally mentioned in the book "The Pragmatic Programmer". The duplication of the same lines of code should be avoided, as this later leads to higher maintenance costs and a higher probability of errors. However, the DRY principle can also make work considerably easier in many other areas.

Basically, you should avoid redundancy in your work as much as possible. In general terms, information should only be in one place. 

As a very simple example, we can consider specifying a version number in a software project. Instead of using them N times in the code, in the documentation, or in configuration files, it should be saved as centrally as possible with the project files, e.g. in a central file, or still better, via the version management system. In all other places where the version number has to be specified, it is either included automatically or only referenced.

Certainly, this is only a very simple example, but I often experience in projects that information is distributed across different files and has to be adjusted manually during a release. A manual process is always prone to errors, is often ineffective and frequently leads to inconsistent documentation and software versions.

In projects, it is always important to keep all documents in a consistent state. That is why, in cooperation with the customer, I have abolished the sending of documents via e-mail in some projects. The better solution here is to use a central and jointly accessible storage location, such as Google Drive or Microsoft OneDrive. For information to be passed on, only the links to the relevant files are then sent. This ensures that every reader or editor always has an up-to-date status.

Especially in large and complex projects, the DRY principle has proven itself. The effort involved in changing documents remains within the estimation and can therefore also be better planned.

Summary:

  • Do not create redundancy in your project. If possible, save information only once centrally.

  • Do not send copies of documents, but rather just pass on links to the respective documents.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
KISS principle

The KISS (Keep It Simple, Stupid) principle is one of my favorite principles that I like to use again and again in projects, but not only there. It leads to a more efficient way of working and enables easier handling of the complex structures, which generates great added value for the entire team and, above all, for achieving the project goals. The KISS principle satisfies a fundamental human need to present complex issues in a simplified manner. In projects, however, it often has to be used consciously, according to the quote from Confucius,

"Life is really simple, but we insist on making it complicated".

With the application of the KISS principle, the aim is to find the simplest possible solution with which, on the one hand, the desired goal can be achieved and, on the other hand, unnecessary complexity can be avoided. The solution should be simple and concise. The KISS principle does not necessarily refer to a technical solution, but can also be applied to other areas such as team communication, documentation, processes, etc.
By reducing the complexity, the team is given a better overview of the overall system, which, for example, accelerates the development of the product in the long term. In addition, many errors are avoided, as many things become more understandable.

How do I use the KISS principle?

The details of the application of the principle depend heavily on the respective area of ​​application. However, there are basic rules that can be applied to all areas of application:

  1. The solution should be based on the goal. Everything that does not directly or indirectly serve to achieve my goal does not generate any value and should be removed or, even better, not added yet!
    In terms of technical implementation, this means, for example, that I do not plan or add any functionality that is not really needed. This also means that I subsequently delete or adjust things, such as documents, that are out of date. With this I contribute to a significant improvement of the clarity. Too often outdated documents lead to misunderstandings because structures and processes have changed. Here is less, but current, better!

  2. The relationship between the amount of work required to implement the solution and the value should be as efficient as possible!
    In concrete terms, this means that I have to spend as little time as possible on implementing or using my solution, in contrast to the value or benefit that this solution brings me. In software development, for example, the architecture, framework or API used should simplify and accelerate the work so that the development of further functions can be carried out efficiently by the team.

  3. The solution should be as self-explanatory and easy to understand as possible!
    The less I have to document additionally, the better. This saves me a lot of time because I don't have to look for and read through extra documentation or ask other people.
    By the way, this also applies to the resulting product. The more intuitively a product can be used, the more value it has for the end user.

  4. My solution should be accepted by the team!
    Things are only simple if they are simple and understandable for everyone involved. In an agile project, the retrospective or a technical meeting can be used very well to work out a solution with the team members concerned. This ultimately leads to greater acceptance in the team and also to a better solution.

  5. I am constantly simplifying or improving my solution if this generates greater value for me!
    This means that I keep applying the points mentioned above whenever I get a more efficient solution (in terms of value). Conversely, I will not do this if it does not increase the value of the solution!
    For example, I should regularly question the processes used in the project, especially if they are not accepted by the team or even bypassed. Then, by adapting the processes, I can considerably simplify the processes and contribute to a more efficient way of working.

The conscious application of the KISS principle naturally requires additional effort. Due to the sustained increase in efficiency in the entire team, however, these expenses should quickly be compensated by the resulting savings and the increase in satisfaction in the team.