Blog List

    Aktuelle Seite:  
  1. Startseite
  2. Blogs
retrospective
Blogs
Zugriffe: 647

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.

 

Tags: , ,
YAGNI principle
Blogs
Zugriffe: 677

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: ,

Menu