DEV Community: devlix Blog

devlix News: We develop a product!

jakobhofmann — Tue, 27 Jun 2023 09:50:31 +0000

Henry Ford is supposed to said once:

If you put one dollar into your business, you need to put another dollar into it to make it visible.

According to this, we would at least like to announce that we as a software company are in the process of developing a (digital) product. We cannot yet reveal much about the product. However, we would like to take this opportunity to address a few topics of the first product development phase.

What are our challenges in product development?

One of the biggest challenges in the first phase of product development is financing. The idea, the team, and also the market for a potential product can look so promising. But first, it must be clarified how the development of the product is funded. We rely on subsidies and self-financing. For this purpose, we applied last year for the Invest BW funding programme of the state government of Baden-Württemberg (Germany). More information on the funding programme and the funding invitations can be found at (in german): Startseite » Invest BW: Innovationsförderung

Besides financing, another challenge is to identify a market niche that has a natural need for a product. Many companies — especially start-ups like us — are increasingly trying to develop new products. The barrier of finding an unfilled or poorly filled market with customer potential is therefore becoming more and more difficult. These days, a high level of specialisation or the combination of features from different target markets or technologies is important.

Finally, the product must be implemented by the company and, therefore, especially by the employees. Scientific articles say that an inadequate product team is one of the main reasons for product development failure. As a result, we are currently looking for motivated developers to start product development with us immediately from the very beginning and to strengthen our expertise in the scope of application development.

How did we plan product development?

First of all, product development must be seen as a strategic goal of a company. In the best case, products deliver sustainable added value for the users and the developing company and therefore contribute to a company's success. The company's strategic alignment also depends a lot on which product fits with the company in general. As an example, a company from the medical branch would probably not develop a product for the automotive branch, unless a product would be combined in both branches and thus represent an added value.

This fundament already creates the first "milestone" in product development. An analysis of the market segment must be done before making further decisions. According to strategic product development principles, we analysed the market situation based on the idea. And by using our own core competencies, we decided how the product should be structured to deliver a value for the market. Especially start-ups have big hurdles at this point, as they may lack market experience, a good network or the feedback of potential customers. A market segmentation strategy is therefore already necessary in the early stages of development. On this basis, surveys can be conducted to find out who the potential buyer groups are or how they can best be reached.

Why do we want to develop a product?

If the barriers for developing a product are so high, why would a start-up want to develop a product at all? First, a difference must be made between start-ups and companies that already offer a product portfolio on the market. Start-ups often have the wish to improve/change existing products or market conditions. Existing products that are established on the market may not seem perfect to many people. But this means that disadvantages and weaknesses of existing products can be quickly identified, giving start-ups the chance to realise new and better products. This offers start-ups an opportunity to present a USP for new products. There have been numerous examples of this in the past.

Companies that already have a product portfolio typically want to ensure the company's growth in a sustainable and a long-term perspective. Due to the competitive situation and constantly changing market conditions, companies have to develop new products to not be left behind the market.

For us, changes in our society play a major role in which we want to actively create improvements. Therefore, the key question for us is: How can we as a company contribute to improving one aspect of our society?

How can product development be planned from a management perspective?

From a corporate management perspective, product development is usually considered strategically. This perspective is necessary to ensure that the product is aligned for the customers and the own company. However, the operational planning of a product ties up many company resources that are lacking for a successful practical implementation of the product. Many companies therefore choose the path of MVPs (Minimum Viable Products). This means that the company develops a product in the most basic form, which already delivers one or "the" added value on the market, to then measure whether the product has the required market significance at all. From this, conclusions can be drawn on how the product should be refined and developed to be able to offer features to other customer groups or to the customers already using it. Adapting the product to the needs of the customers plays a key role in the next step.

Of course, we will discuss all issues in a strategic manner and discuss ways to maximize the product's potential value.

The path is the goal, all beginnings are hard

No successful company in this world has developed and successfully launched a product from one day to the next. Behind this, there are often many strategic decisions, clever marketing strategies, and, of course, a high effort for the necessary company resources. In this context, product development is like many areas of personal life: from an idea, a vision can be developed, which is then used as the basis for the mission and the resulting milestones. The vision defines the goals, strategy and direction of a company. The mission, on the other hand, specifies how the goal from the vision is implemented in daily business.

As a small software company, product development also creates new challenges for us. Financial risks, planning uncertainties or even the discussion about the "right" product for our company can only be solved in teamwork.

From time to time, we will inform about our product development on this blog and thus make sure that our customers are informed about the added value of the product at the right time. Who knows, maybe you will also be affected by our product one day. Be curious to see what we develop for you!

Jakob Hofmann is writing for the devlix Blog at https://www.devlix.de/blog
This article was published first here (german): https://www.devlix.de/devlix-news-wir-entwickeln-ein-produkt

devlix GmbH: quality, consulting, development

Feature image: Photo by Frank Schillinger, Midjourney

Retrospectives: understanding the present and shaping the future

Frank Schillinger — Tue, 25 Apr 2023 07:00:00 +0000

Retrospectives are an important part of agile processes. They let your team look back at what they've done and see where they can improve, so they can adjust the way they work. But how do you achieve a successful retrospective? In this article, we talk about the importance of retrospectives and give ideas for how to use them effectively.

Retrospectives can enrich many aspects of working life, but we focus here on software development, as we always do in all articles in our blog.

What is a retrospective?

A retrospective is a meeting that usually occurs at the end of a development sprint and is an opportunity for the team to reflect. Did the collaboration work well or did it cause problems? Are the applicable processes compatible with the team or are they hindering? Are there factors outside our control that are slowing down our progress? Which things worked well? Should external feedback be discussed and considered?

Photo by Antenna on Unsplash

The following questions guide us through a retrospective:

What are the challenges and obstacles we face as a team.
What is causing these challenges?
What steps can we take to improve to eliminate these challenges and obstacles?

So, the goal is to collect information about the team's current or past development cycle and the state of the team's interaction. However, only collecting this information does not help. Considering that simply identifying an issue does not promise improvement, the development of solution approaches and concrete tasks, often called “action items,” is therefore also a goal of retrospectives in everyday work.

These meetings are exclusively reserved for the team. In this context, we consider a team to be a Scrum team or simply a defined number of people who work together on the implementation of product features or similar. This means that no stakeholders or other third parties are invited to these meetings unless it is the team's explicit wish.

Why are retrospectives important?

Retrospectives are essential because they allow the team to learn from mistakes, as well as from successes. They allow the team to identify issues where they can or need to improve their process, knowledge, or collaboration. To change something, you have to see that it needs to be changed. If one isn't directly affected by an issue or problematic situation, this realization usually only comes up in conversations with other team members. It's critical to give these conversations space. Looking back is necessary to make improvements in the future.

Holding these meetings regularly is important and included in most agile frameworks. But even if you aren't using an agile framework, regular retrospectives make perfect sense.

The team can speak freely

Since a retrospective is meant to be a safe place for a team, the Las Vegas rule applies here: what is discussed in the retrospective stays in the retrospective or with the team. The only transparency to external observers should be the action items that are developed as a result of a retrospective.

Talking freely only works if everyone feels comfortable. I have observed repeatedly that new team members often need one or two retrospectives to really feel comfortable. And that's perfectly okay. You might be cautious about what you say if you have never participated in retrospectives before. So give your team time to understand the benefits and positive effects of a retrospective.

In addition to the Las Vegas rule, it is important to remember that criticism must always be constructive and never personal. Personal attacks are not allowed. They can undermine any advantage of the meetings.

Challenges are identified and addressed

In a retrospective, the team can identify all the challenges they have encountered during a sprint or since the last retrospective. Various methods and techniques can be used to achieve this.

Photo by Shane Aldendorff on Unsplash

Many times, participants have had a topic in mind for a long time and they say it right away. It can be helpful to ask the team to send the moderator topics they know about in advance if they are going to be talked about. The moderator then can prepare specific methods and techniques that he or she feels are appropriate for the analysis. If a list of topics emerges automatically in this way, time can be saved by not planning for the elaboration of topics in the meeting.

Joint solutions are developed

Based on the results from the retrospective, the team can plan and introduce changes to its process and approach. These may involve a small change or a major overhaul. The goal is to improve the way the team works so that it can be more effective and efficient.

Problems can occur in many areas, and possible solutions are just as varied. During a joint discussion, an analysis succeeds faster and better. A key consideration is to include the different perspectives and opinions in the discussion. Only then will a solution be found that will satisfy everyone. Do not miss out on this opportunity.

How do you run a successful retrospective?

When conducting a retrospective, there are several important things to consider. Let's take a closer look at them and use a few tips. Let's assume that you are tasked with organising such a retrospective or that it is part of your role in a team, as is the case with the Scrum Master, for example.

Retrospectives have to be organised differently for each team, so the following paragraphs should serve as a hint to conduct retrospectives successfully. They should not be perceived as a fixed structure.

Clear communication of the rules is important

Clear and simple communication is important before and during a retrospective. There are a few things to point out.

Stay positive – It's not about finger-pointing or finding the guilty ones for problems. It's about finding ways to improve.
Stay specific – Be as specific as possible when discussing issues that need improvement. This helps the team focus on specific obstacles and how to change them.
Stay action-oriented – The goal of a retrospective is to identify actions that can be taken to improve the way the team works and their circumstances and environment.

Photo by Mark Duffel on Unsplash

Make sure you point out these rules at the beginning. During the retrospective, always point out these points if you feel that the discussion could drift or develop in an unpleasant direction.

A well-thought-out agenda and a pleasant atmosphere helps all participants

Note: To learn more about methods and techniques for the individual steps, we recommend taking a look at the planning aids mentioned in the next paragraph.

Create a pleasant and relaxed atmosphere for the discussion. A successful retrospective won't happen under stress or tension. The facilitator should provide mental relaxation exercises at the beginning. Maybe just ask how everyone in the group is feeling. Or use games to break the ice.
Collect topics and information with the team about the time between the last retrospective and the current meeting. This can be done with a variety of techniques. As a moderator, you gradually develop a sense of which techniques help a team. This process can be interactive or formal, stimulating conversations or requiring individual work. The important thing is the goal: a collection of topics to be discussed and looked at in more detail later on. Notes documented during a sprint can be used to help and speed up the process of finding topics.
Analyse the identified problems, obstacles and barriers with the team. There are many different approaches to this as well. You should design this agenda item as you think it works best for your team. Problems can be addressed in writing, visually, interactively, or in any other creative way. The goal here is to bring the core of the issue or problem to the surface. Only then can you decide on action items in the next step.
Plan actions and make decisions. This is how you lay the foundation for improvements. Make sure that actions are taken as quickly as possible. After all, you want to achieve the fastest possible improvement in circumstances. There are always actions that can be taken care of immediately and do not have to be scheduled into the next sprint. Make sure that the remaining actions are really included in the next Sprint Planning! It is also important that actions and tasks are documented transparently, can be planned and progress can be tracked. Check this progress in the next retrospective!
Conclude the retrospective with an activity aimed at feedback. It can be a simple question about whether the team liked the retrospective or not. It can also be a round of praise, in which each participant praises the person sitting next to him or her for certain activities or results in the past sprint. Here, too, there are no limits to the imagination. Activities that shift the focus from problems to positive aspects are always good. After all, everyone wants to leave the retrospective with a good feeling.

Planning tools that you can use as an aid

Retromat: With this tool, you can create your next retro. Agenda points can be exchanged and you can then share the agenda with a generated URL. A great source of inspiration!
EasyRetro – Random Retrospective Generator: A wide variety of templates for your next retrospective. You can either take the structure suggestions and design each point yourself, or you can use the professional tool from EasyRetro and conduct your retrospective with it.
Retro.Generator: Like Retromat, one can have activities suggested for each item on the agenda. A benefit of this approach is that they can be filtered according to the operational scenario.

Realistic planning of concrete actions

If actions can't be done ad-hoc, they have to be scheduled for the next sprint or development cycle. Like any other work package, be realistic about the size and amount of work involved. Improvement activities should, of course, be completed within one sprint. If something is too big, break it up into smaller packages that can be improvements on their own.

The bottom line

Conducting a successful retrospective helps teams to learn from mistakes and successes, to identify opportunities for improvement and to make and bring changes to the way they work or in their own environment.

Photo by Julia Taubitz on Unsplash

Retrospectives should not only be seen as an instrument of an agile way of working. Regular retrospectives also make sense in traditional working environments.

There is a way to improve cooperation in all companies and industries! So let's use the tools available and make our everyday work easier.

Please let us know in the comments whether you use retrospectives in your team and what experiences you have had with them. Thank you!

Frank is writing for the devlix Blog at https://www.devlix.de/blog
This article was published first here (german): https://www.devlix.de/retrospektiven-die-gegenwart-verstehen-und-die-zukunft-gestalten/

devlix GmbH: quality, consulting, development

Feature image: Photo by Mark Duffel on Unsplash

Decrypt & Validate JWE Tokens with Spring Security

Florian Storz — Tue, 04 Apr 2023 11:21:33 +0000

All systems that are exposed to a flood of requests must respond in a short time due to today's requirements. It is therefore important that the individual steps for processing a request are as fast and secure as possible. Therefore, stateless protocols such as OAuth 2.0 (or OIDC) are used for authentication purposes, for example. This protocol usually uses so-called JWTs (JSON Web Token). These tokens contain data about the user and his permissions in the system. The information is usually readable by anyone who has access to the communication and also by anyone involved in the connection between the user and the system (e.g. browser, proxy server or reverse proxy).

Usually, this is referred to as JWS (JSON Web Signature) tokens. To ensure that a potential change can be detected during transmission, these tokens are normally secured against this by signatures (immutability). In addition, there is another form of JWT, the JWE (JSON Web Encryption) tokens, which transmit the content in encrypted form (confidentiality). The encryption does not ensure who created the data. Therefore, when using JWE tokens, a JWS token is normally used as content to ensure the necessary security.

What are JWE Tokens in a nutshell?

JWE tokens are basically a standardized way of exchanging structured data between systems in encrypted form. The RFC standard offers a wide variety of symmetrical and asymmetrical methods for encryption. The list of supported encryption algorithms can be found in the RFC-7518. The payload to be transmitted contains a JWS token for stronger security, which ensures the immutability and correctness of the data.

What is the structure of JWS and JWE tokens?

A JWS token consists of three parts separated by a dot (.) - {header}.{payload}.{signature}. The header contains, among other things, information about the algorithm used to create the signature and how it can be verified. The payload contains the data to be transmitted, and the last part contains the digital signature.

A JWE token consists of five parts separated by a dot (.) - {Header}.{EncryptionKey}.{InitializationVector}.{Ciphertext}.{AuthenticationTag}. The header contains, among other things, information about which algorithm was used to encrypt the data and whether there is a JWS in the data. The two parts EncryptionKey and InitializationVector contain technical data relevant to decrypting the data. The Ciphertext contains the encrypted data. The AuthenticationTag is used to ensure that the token has not been altered.

If you would like to know more about JWS and JWE tokens, you can read this interesting article about it or look at the respective RFC specifications.

How can JWE tokens be decrypted and verified with Spring Boot or Spring Security?

Spring Boot in combination with Spring Security includes the functionality to include the verification of JWS and JWE tokens easily in the authentication process of the system.

Including the following dependency (e.g. via Maven) adds the functionality to the system.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-oauth2-resource-server</artifactId>
</dependency>

Who is interested: The configuration in the Spring Boot Framework is done in the following classes.

org.springframework.boot.autoconfigure.security.oauth2.resource.servlet.OAuth2ResourceServerJwtConfiguration.JwtDecoderConfiguration:jwtDecoderByJwkKeySetUri
org.springframework.boot.autoconfigure.security.oauth2.resource.servlet.OAuth2ResourceServerJwtConfiguration.OAuth2SecurityFilterChainConfiguration

Including the JWS Token Check in Spring Boot

The following Spring Boot configuration shows how to verify the tokens:

JwsSecurityConfiguration.java
@Configuration
@EnableWebSecurity
public class JwsSecurityConfiguration {}

application.yaml
spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          jwk-set-uri: ${url}/.well-known/jwks.json
          issuer-uri: ${url}
          audiences: resource-server-app

Including the JWE Token Check in Spring Boot

To include the verification of JWE tokens, the following configuration can be used. Among other things, this requires a private key for decryption. In this example it is a RSA private key. Because of that, it must be defined for which algorithms the provided private key can be used for decryption. This configuration is largely based on an example project of the Spring Security Framework, which can be found here.

JwtDecoderConfiguration.java
@Configuration
@EnableWebSecurity
public class JwtDecoderConfiguration {
    private final JWEAlgorithm jweAlgorithm = JWEAlgorithm.RSA_OAEP_256;
    private final EncryptionMethod encryptionMethod = EncryptionMethod.A256GCM;
    private final OAuth2ResourceServerProperties.Jwt properties;
    private final RSAPrivateKey key;

    JwtDecoderConfiguration(OAuth2ResourceServerProperties properties,
                            @Value("${sample.jwe-key-value}") RSAPrivateKey key) {
        this.properties = properties.getJwt();
        this.key = key;
    }

    @Bean
    JwtDecoder jwtDecoderByJwkKeySetUri() {
        NimbusJwtDecoder nimbusJwtDecoder = NimbusJwtDecoder.withJwkSetUri(this.properties.getJwkSetUri())
                .jwsAlgorithms(this::jwsAlgorithms)
                .jwtProcessorCustomizer(this::jwtProcessorCustomizer)
                .build();
        String issuerUri = this.properties.getIssuerUri();
        OAuth2TokenValidator<Jwt> defaultValidator = JwtValidators.createDefaultWithIssuer(issuerUri);
        nimbusJwtDecoder.setJwtValidator(getValidators(defaultValidator));
        return nimbusJwtDecoder;
    }

    private void jwsAlgorithms(Set<SignatureAlgorithm> signatureAlgorithms) {
        for (String algorithm : this.properties.getJwsAlgorithms()) {
            signatureAlgorithms.add(SignatureAlgorithm.from(algorithm));
        }
    }

    private OAuth2TokenValidator<Jwt> getValidators(OAuth2TokenValidator<Jwt> defaultValidator) {
        List<String> audiences = this.properties.getAudiences();
        List<OAuth2TokenValidator<Jwt>> validators = new ArrayList<>();
        validators.add(defaultValidator);
        validators.add(new JwtClaimValidator<List<String>>(JwtClaimNames.AUD,
                (aud) -> aud != null && !Collections.disjoint(aud, audiences)));
        return new DelegatingOAuth2TokenValidator<>(validators);
    }

    private void jwtProcessorCustomizer(ConfigurableJWTProcessor<SecurityContext> jwtProcessor) {
        JWKSource<SecurityContext> jweJwkSource = new ImmutableJWKSet<>(new JWKSet(rsaKey()));
        JWEKeySelector<SecurityContext> jweKeySelector = new JWEDecryptionKeySelector<>(this.jweAlgorithm,
                this.encryptionMethod, jweJwkSource);

        jwtProcessor.setJWEKeySelector(jweKeySelector);
    }

    private RSAKey rsaKey() {
        RSAPrivateCrtKey crtKey = (RSAPrivateCrtKey) this.key;
        Base64URL n = Base64URL.encode(crtKey.getModulus());
        Base64URL e = Base64URL.encode(crtKey.getPublicExponent());
        return new RSAKey.Builder(n, e)
                .privateKey(this.key)
                .keyUse(KeyUse.ENCRYPTION)
                .build();
    }
}

application.yaml
spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          jwk-set-uri: ${mockwebserver.url}/.well-known/jwks.json
          issuer-uri: ${mockwebserver.url}
          audiences: resource-server-app
sample:
  jwe-key-value: classpath:private.key

private.key
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----

Testing the authentication with JWE Tokens

To test the configuration for authentication, valid tokens must be created in the tests. These JWE tokens can be created with the following class. The contents etc. must be adapted to the respective requirements.

@Component
public class TokenService {
    private final JWEAlgorithm jweAlgorithm = RSA_OAEP_256;
    private final EncryptionMethod encryptionMethod = A256GCM;
    private final JWSAlgorithm jwsAlgorithm = RS256;
    private final OAuth2ResourceServerProperties.Jwt properties;
    private final RSAPrivateKey key;

    TokenService(OAuth2ResourceServerProperties properties,
                            @Value("${sample.jwe-key-value}") RSAPrivateKey key) {
        this.properties = properties.getJwt();
        this.key = key;
    }

    public String buildToken() throws Exception {
        SignedJWT signedJWT = new SignedJWT(new JWSHeader.Builder(jwsAlgorithm).build(), new JWTClaimsSet.Builder()
                .issuer(properties.getIssuerUri())
                .audience(properties.getAudiences())
                .subject("subject")
                .issueTime(new Date())
                .expirationTime(new Date(new Date().getTime() + 5000))
                .build());
        signedJWT.sign(new RSASSASigner(rsaSigningKey()));

        JWEObject jweObject = new JWEObject(
                new JWEHeader.Builder(jweAlgorithm, encryptionMethod)
                        .contentType("JWT")
                        .build(),
                new Payload(signedJWT));

        RSAEncrypter encrypter = new RSAEncrypter(rsaEncryptionKey());
        jweObject.encrypt(encrypter);

        return jweObject.serialize();
    }

    private RSAKey rsaEncryptionKey() {
        RSAPrivateCrtKey crtKey = (RSAPrivateCrtKey) this.key;
        Base64URL n = Base64URL.encode(crtKey.getModulus());
        Base64URL e = Base64URL.encode(crtKey.getPublicExponent());
        return new RSAKey.Builder(n, e)
                .keyUse(KeyUse.ENCRYPTION)
                .build();
    }

    private RSAKey rsaSigningKey() {
        RSAPrivateCrtKey crtKey = (RSAPrivateCrtKey) this.key;
        Base64URL n = Base64URL.encode(crtKey.getModulus());
        Base64URL e = Base64URL.encode(crtKey.getPublicExponent());
        return new RSAKey.Builder(n, e)
                .privateKey(crtKey)
                .keyUse(KeyUse.SIGNATURE)
                .build();
    }
}

Summary

Based on our experience JWE tokens are not often used. Therefore, information regarding the usage in frameworks like Spring Boot and Spring Security is very rare. With this blog post we would like to make things easier for other developers who have to work with JWE Tokens and Spring Boot. Have fun 😃

Florian Storz is writing for the devlix Blog at https://www.devlix.de/blog
This article was published first here (german): https://www.devlix.de/jwe-tokens-mit-spring-security-entschluesseln-und-verifizieren/

devlix GmbH: quality, consulting, development

Work from home

Frank Schillinger — Tue, 28 Feb 2023 07:00:00 +0000

The pandemic has moved us humans and the entire world. And, of course, the economy and its companies. Decision-makers who had previously been unsure about new working models now had to try them out, test them and introduce them. If there are positive things about a pandemic, one of them is the increased willingness to work in one's own and private four walls.

Of course, this is limited to companies where employees do not have to be present on site in the office, on the factory floor or in other important places. The desire to work more at home was often granted with a sneer or rejected before the corona pandemic. There was no understanding that it was possible to work just as productively at home in the majority of companies. This is not least because digitalization in the economy was delayed and overslept. The latter now had to show that it could make up for this delay in record time. It had no other choice and was forced to make its fortune. The clear winners of the crisis were providers of video conferencing solutions and messaging services for businesses.

Among many other points that have changed in everyday working life, we focus in this article on working from home. This is because it has both positive and negative aspects, both for employees and companies.

I’d like to share how we’ve dealt with this issue in our company and how we’ve adapted to the new reality.

What employees and companies can get out of working from home

More people are working from home in professions that allow it, which provides advantages for companies and their employees that can't be ignored. Let's take a closer look at a selection of the positive aspects.

Summary:

Companies have the potential to save money or reallocate space by reducing their use of office space.
It is possible to reduce heating and energy costs by merging workspaces within the company.
Employees can adapt their workspace at home to their needs.
Employees can work flexibly and are less bound to external requirements.
Days spent at home in the office reduce the effort and cost of commuting to work.
Potential for more productive work through longer, uninterrupted blocks of time.

Photo by Nathan Riley on Unsplash

If only half of stationary workplaces need to be kept available for employees, this opens up new possibilities for companies. Depending on the nature of the company's locations, subleasing or downsizing of the premises can be considered. Considering the constant rise in rental costs, this is certainly an aspect that could have a positive effect in the medium term due to the possible savings. A more interesting option for companies that have had to deal with insufficient space before is repurposing premises, for example making the long-awaited meeting or project room a reality.

Of course, less space also means savings in terms of energy costs for heating and electricity. To be fair, however, it should be said that these costs are paid by each employee when they work from home. Companies sometimes pay monthly supplements to the employees to cover these costs. It is assumed that there is a reduction in costs for the companies, even though they compensate the employees for the additional costs.

Working from home can also have many advantages for employees. While the design of a company's workplace is usually based on rules, a person's own workplace can be designed to meet and fit their needs.
Most people don't have a separate room to use as a workspace. In these cases, it's not possible to create a workspace that's separate from the private space, which limits the possibilities. However, this gives most people more freedom to design their own place of work.

Another plus is the flexibility that comes with working from home. Families can especially benefit from this. In the best case, private appointments can't be made only after work, which is hard to do when dealing with authorities because the offices only have limited hours. The presence at home can also help you organize your family. But it's important to note that working from home doesn't mean that parents are always available for the children.

More than 30 minutes to get to work is not uncommon. Depending on the type of transport, this can be a costly pleasure. In rural areas, the choice of transport is not even guaranteed. With the current prices for mobility, people are happy to save on these costs. In addition to these costs, people also have to spend a lot of time every month to be able to get to work on time every day. It seems tempting to get up in the morning, having 5 minutes more to enjoy the first coffee, read the news and then start working. The quality of life is positively impacted by such a start to the day, according to experience reports. This aspect is the most important reason for many people to demand working from home. Even if the employee pays the costs of the commute to work proportionately or in total.

Even though some people would rather not admit it, it's possible to work more focused and focused at home in many cases. This is not least because longer and uninterrupted blocks of time are organizable and feasible. Of course, this presupposes that you don't immediately check your chat or e-mail every time you are notified. Noise can usually be contained by oneself, and the workplace can be set up in a way that minimizes distractions. Of course, this does not always work. But many people on the web report that this is one of their main arguments for working from home.

Disadvantages of working in your own home

Of course, there are also negative aspects to consider when discussing working from home. I'd like to talk about some of them here.

Summary:

Contact and personal exchange with colleagues is limited to digital ways and tools.
The increase in video conferencing or remote meetings and chat messages can cause stress.
The separation of private life and work becomes more difficult.
It can be hard to finish the workday.
The expectation that employees are always available can increase.
Elimination of small talk reduces social interaction between colleagues.
Increased energy costs and loss of private space.
Companies and supervisors may be forced to trust employees more, which is not always possible.
Increased demands on controlling and management.

Photo by Magnet.me on Unsplash

One effect that is mentioned repeatedly is that many people working from home miss personal contact and direct exchange with their colleagues, and would like to have this again more. It's hard to make this personal contact with digital tools. A certain distance is usually noticeable in 1-to-1 conversations via video conferencing solutions. Naturally, this depends on the individual people and their attitude towards digital tools. Nevertheless, it is true that many people find this difficult.

Depending on the situation, the use of video conferencing solutions is increasing at work at home. Despite the increasing use of chat messages and e-mails, video and voice communication between colleagues is still an important method of communication. But according to experience reports, this can also lead to stressful situations for people. Whether it is the feeling of being recorded by a camera or an unsafe handling of digital tools. Many people feel uneasy using video-based communication tools.

Another reason, perhaps more obvious, why people may find it difficult to work from home is that it is not at all easy to separate private from business matters when both take place within the same four walls. Only a few people can call a separate workroom their own, so they have to set up their workplace in the normal living room. The more restricted the living situation, the harder it is to separate the two worlds.

Furthermore, there is a problem that is obviously equally critical. A local separation between private and business matters makes it easy to end a working day. It can take a lot of mental consistency to find a point where one is not mentally preoccupied with work issues if this separation is removed. It is even more difficult if one does not have the privilege of closing the door to a separate working room.

And when we talk about consistency, we also have to consider the issue of constant availability. Some supervisors assume that messages to other employees are answered or at least read immediately. The difficulty hasn't only existed since the increase in working from home. But it is reported repeatedly that this has exacerbated the difficulty. And yes, it's hard to not check for new messages at every notification tone. And this is not only true during working hours. As the boundaries between private and business life become increasingly blurred, it is becoming increasingly difficult to close the computer completely at the end of the day and put the mobile phone on silent.

The reduction in personal communication is accompanied by another aspect that may not seem as important. Small talk is crucial in human relationships and interaction. It helps us to take a deep breath and clear our heads for a few minutes. Off-topic conversations often take place before an appointment, but in the context of a video call they are often just a desperate way to fill the silence.

It should be mentioned again that the conversion of private space into workplaces increases the costs of privately used space. In addition, more energy is consumed. This concerns heating and, of course, electricity. The cost will be felt in one's own wallet at the end of the month if the employer doesn't contribute.

Of course, companies and their supervisors must have greater trust in their employees when they work remotely. This is not always successful, and it can also be for personal reasons. Mistrust can be reduced with the digitally networked tools available. When it comes to digital work, results are usually visible in real time. But you have to first introduce these tools to the company, which is hard for many companies.

The communication of companies with their employees may be somewhat more difficult overall. Not only the employees, but also all the trades that come into contact with them must consider and use digital communication. It is important that a company has a set of guidelines for internal communication and uses certain tools and solutions for this purpose. This may result in a high licensing and usage cost.

Tips for working at home

We have noticed that there are both positive and negative aspects to working within your own four walls. With a few tricks, the negative points can be well managed.

Photo by Helena Lopes on Unsplash

An ergonomic workplace is also essential at home. Employers should consider subsidizing an appropriate workplace.
Sufficient light and good air make for a pleasant working environment. When setting up a workstation at home, care should also be taken to ensure that ambient noise is low.
Routines facilitate the separation of private and professional life. Structuring the workday at home (and sticking to it, of course) can help clear the mind. Constantly changing break times, work start and end times blur boundaries between private and business.
The right tools are important for communication and distributed work management. Too many tools for overlapping tasks or tools with heaps of features that you never use can unintentionally increase the complexity of using such tools. Less is often more here, too.
Regular off-topic calls promote social exchange between colleagues. Regular meetings for team exchanges and small talk can loosen up communication.
It is significant for colleagues to get together regularly. Team events promote cohesion and should be planned regularly. Company-wide events once a year are not enough.
A constantly open and video-supported communication channel for the team brings high added value. It is similar to the principle of water dispensers in offices. Colleagues dial in when they feel like it and can simply talk there, completely apart from all work topics.

The model of devlix GmbH

The topic of working from home has also been on our minds. Since the beginning of the corona pandemic, we have been mainly working from home. During the process, we realized that we needed more time for off-topic conversations so that we could not just talk about current projects.

Photo by Chris Montgomery on Unsplash

To keep the communication in the team and the interaction going, we have introduced regular meetings during the week with a duration of 30 minutes. To make the purpose of these meetings clear, we have called them "coffee klatch". In addition, we plan regular games evenings in our offices, where everyone can bring board games. Company events, such as summer party, Christmas party etc. still take place once a year, as the name suggests.

We have introduced two days per quarter on which we train together and are not available for day-to-day business. Each colleague works on a topic of their choice, but we show it to the whole team in the following weeks to pass on knowledge. This also happens remotely, but it promotes communication among us.

Generally, we plan regular lunchtime meetings in which a colleague presents a topic to the team. The choice of topic is completely free, but is of course very much oriented towards current projects. The audience can eat their lunch and drink coffee. We see this as a good opportunity to learn new things in an informal atmosphere.

We are satisfied with the measures we have taken, but of course, we are always thinking about how we want to deal with the issue of working from home in the future. Not only that, but we agreed that it is up to everyone to choose the model that suits them best. Results come first, not the place of work. With this, we are also in full agreement with the developer community, which wants exactly this.

It is important to regularly question one's own procedure and approach to working from home, and to adjust it if necessary. We ourselves are satisfied with our model. However, this may also be since we work on a wide variety of projects across the team and are not necessarily dependent on constant coordination within the team.

We are currently planning to spend more time on site in the office again, even though we were able to accept the change to working from home. We are missing the social component of working together as a team.

My conclusion

Working from home is a suitable option for jobs that do not necessarily require on-site presence in the company. All this requires the right tools and strategies to deal with the challenges.

This model is not for everyone. Ultimately, everyone has to try it for themselves and decide for themselves whether they can gain advantages from it. I think regulations for or against working from home are fundamentally wrong. Companies have to develop a strategy together with their employees on how to deal with this issue.

It was always important to me to keep my private and business life separate, so I had problems with it at the beginning. It took me a while to get used to it. Simultaneously, I have also adapted to the advantages and I organize my working day in the same way as when I leave the house at a fixed time and come back again. I also take a short break at the same time. This routine gives me the distance I need when it's closing time. I don't have a separate room for work. However, my desk is in a room that is only used as a passageway. This means I don't lose a lot of space that I would use privately in my spare time. In addition, I have limited myself to a small desk, which prevents the workspace from spreading out and taking up even more private space.

Do you work at home and what are your experiences with it? You are welcome to let us know in the comments. We would be truly interested. Thank you very much!

Frank Schillinger is writing for the devlix Blog at https://www.devlix.de/blog
This article was published first here (german): https://www.devlix.de/zu-hause-arbeiten/

devlix GmbH: quality, consulting, development

Feature image: Photo by Nelly Antoniadou on Unsplash

Introducing Scrum — Common mistakes when introducing Scrum

jakobhofmann — Tue, 31 Jan 2023 14:04:43 +0000

“And how do you work in software development?” an engineer asks his former fellow student over dinner. “We do Scrum now,” he answers proudly. Have you ever heard a conversation like this before? If so, you will certainly have listened carefully to how the conversation went on. But what does “We’re doing Scrum now” actually mean for a company, and why does the introduction of Scrum so often not lead to good results?

Processes and especially agile processes are certainly different in many companies — and they have to be because companies have very different characteristics, both in their goal and in their (historical) development. As a framework, Scrum therefore sets certain boundary conditions that can then be adapted to the respective company and embedded in existing processes.

But when is it no longer Scrum? What mistakes and experiences do many companies make in the process, especially when introducing Scrum in the company?

Introducing Scrum — common mistakes

Introducing Scrum without employees

Companies regularly review themselves and their procedures. This is because both the company representatives and the employees want to be the best company on the market in their segment. If other companies are more successful in the same segment, they quickly and intensively work out what the reasons are and how they can catch up. A transformation is needed! “The other company does Scrum — I want that too”. This realisation may be purposeful, but it brings significant changes with it. Unfortunately, employees are often not involved strongly enough in the process. This reveals a lack of role definition for them in the future and, above all, a failure to rethink and adapt existing internal processes. A break between the classical and agile worlds is regularly the result. This is exactly the point where an experienced Scrum Master (or better an Agile Coach) has to be involved (see article: Why a Scrum Master has to demand processes). Employees must be involved from the beginning when the company is undergoing such a major change.

The missing of a Scrum Master

Another consequential error in this context is that individual roles are saved during the introduction. “A Scrum Master costs money and can also be taken over simultaneously by the Product Owner” is then the common opinion. However, any person who has had first-hand experience with this scenario will agree that this does not work. Even if a product owner has the ability to take on the role of Scrum Master, this person has neither the time nor the awareness in the team to do so. To make it more clear: Scrum without a Scrum Master is simply not Scrum. What effects the missing of a Scrum Master can lead to the success of the company can be read in the blog post “Why a Scrum Master has to demand processes”.

Agile vs. waterfall

Many conventionally organised companies have difficulties introducing agile ways of working and adapting the processes. The approach in the organisation plays a major role in this. People who do not know or understand agile process models often fall back into familiar patterns even though they are coached by a Scrum Master. This often concerns the way decisions are made. In classic product management, schedules are typically given that depend on a target date. After the introduction of Scrum, an attempt is then made to take the developers’ estimates as the basis for a timetable for the project. Milestones, project plans and entire business decisions are made dependent on them. However, the estimates of the development team then represent at most a rough scope or only consider the complexity of the implementation. The time schedules based on this and the classic procedure of first making a detailed plan for the implementation often present management with great challenges. This is almost a classic mistake for approaching and planning in an agile approach, and it is quite easy to avoid it. How exactly this can be avoided is explained in detail in our blog article: “Estimates in everyday project life”.

Meetings are too expensive

Let’s face it: meetings can be very time-consuming, aimless, and above all expensive for companies. In Scrum, there is a fixed timetable for when which events take place. The time frame is therefore clear to the participants from the beginning and with a little practice and friendly reminders from a Scrum Master or timekeeper, it usually works out. But is all the meeting time really necessary? You can guess the answer: Yes! Because people can only work together successfully if the goal, the derived tasks and emerging problems are solved communicatively. So, should the thought arise at the next review that it is a waste of time, the follow-up thought must be: “How can I contribute so that the meeting is more successful for everyone”. Omitting Scrum events or staying away from them is not a solution to the issues that have arisen.

Consider Scrum as a fixed process

Scrum newcomers would certainly expect that Scrum already defines everything necessary for joint teamwork. Far from it! As already described in the introduction to this article, every company has established different procedures, partly for historical reasons. Scrum must be integrated into these processes and should serve as methodological support. In doing so, it is important to adapt the existing processes so that the attractive advantages of this approach can be used.

Apply Scrum hands-on only

“We introduced Scrum and we also defined the roles of Scrum Master and Product Owner ourselves. Previously, the two employees were part of the team, but they wanted to try something new.” Wonderful! Because the employees start their mission full of curiosity and joy. In the best cases, this will also be able to lead to success. However, there is also the danger that critical components of Scrum will not be applied completely or incorrectly. The reason for this is, for example, a lack of knowledge or experience with Scrum. Recommendation: Get external support through coaching or at least temporary parallel cooperation by experts who have already gained enough experience. If you need support in this area for your company, you are of course welcome to contact us.

Conclusion

The introduction of Scrum in a company is a big challenge that has to be considered individually for employees and the company processes. Only when the advantages of the agile way of working are in focus and have been understood it is possible to make all the necessary adaptations for the company. Such a cultural change is preferably facilitated by experienced experts. In this way, some challenges described can either be solved directly or may not even arise in the first place. Ultimately, this transformation can only succeed if the processes are successively adapted to the needs of the company by trial and error.

Jakob Hofmann is writing for the devlix Blog at https://www.devlix.de/blog
This article was published first here (german): https://www.devlix.de/scrum-einfuhren-haeufige-fehler-bei-der-einfuhrung-von-scrum/

devlix GmbH: quality, consulting, development

Feature image: Photo by ThisisEngineering RAEng on Unsplash

Creative Brainstorming

Frank Schillinger — Tue, 20 Dec 2022 08:00:00 +0000

There are lots of different brainstorming methods out there, but which one is best for you and your team? Whether you're a solopreneur or part of a team, one of these methods will help you come up with great ideas!

Coming up with good ideas is one of the hardest and most creative tasks you can face. However, you don't have to be “creative” to do this. Motivation is key – without it, even the best-organized brainstorming session won't generate good ideas. Create a relaxed atmosphere and give enough time and space for the session.

Techniques for your next session

Since hardly any people succeed in brainstorming or finding ideas without a setting, techniques have been developed that aim to guide this creative process in an organized pattern using defined procedures and rules. The success of these techniques proves them right.

So let's take a look at a few techniques that you can try out yourself or with your team.

Mind mapping

A popular brainstorming technique that can be used by individuals or groups is mind mapping. To create a mind map, you start with a central idea in the middle of a sheet of paper and then draw branches from the center. Each branch represents a different aspect of the central idea, and you can add as many details as you like. This technique is especially helpful when relationships are important and details need to be worked out. There are also plenty of digital tools for creating mind maps.

Mind maps are easy to understand, they organize your ideas and thoughts and are a good way to document them.

Example: We start with a concrete product idea and note down significant features that are essential for the customer acceptance. We now take a closer look at each feature and note down the individual functions that a feature must or should consist of. In a further step, we can even add further information to each feature, e.g., attributes, behavior, images, diagrams, etc.

Example of a Mind map

In a group, it is essential that discussions be given enough space and that everyone is asked for his or her opinion or idea. It easily happens that primarily the “loudest” person brings in his or her ideas, and other opinions are lost.

More information: https://en.wikipedia.org/wiki/Mind_map

Brainwriting

This technique can also be used solo or in a group. Unlike in mind mapping, each person is forced to write down their ideas. So, everyone impacts the outcome.

You start by having each person write down a new idea on a piece of paper. Then all the pieces of paper are collected and shuffled. Each person takes a piece of paper and expands the idea written on it. This process is continued until each person has complemented all the ideas of the other participants. This technique is excellent for quickly generating and developing many ideas.

Example of a Brainwriting process

More information on the 6-3-5 variant: https://www.toolshero.com/creativity/brainwriting/

SCAMPER

SCAMPER stands for

Substitute,
Combine,
Adapt,
Modify,
Put to other uses,
Eliminate and
Reverse/Rearrange.

In this method, you take an existing product or service and think about how you could improve it using the SCAMPER framework. First, get a good picture of the product because you should be familiar with its features, functions and unique aspects before you start thinking about possible improvements.

Then go through the following checklist and write down at least one sentence or keyword for each bullet point.

Substitute: Can you exchange components, e.g., parts, modules, materials, people, applications, and steps in the process?
Combine: Are there features or services that you can merge/combine?
Adapt: Are there similar features and solutions in a different context? Can they be used and adapted?
Modify: Can a feature, function, haptic, taste or similar be changed? Can the value of the product or service be increased?
Put to other uses: Can the product be used in other ways? How would people use the product who are not part of the current target group? Can the target group be expanded?
Eliminate: Is there potential for simplification? Can functions or features be removed, downsized, split up without reducing the value? What might even be unnecessary?
Reverse: Can the product be used for something contrary without losing value?

This technique is especially useful for developing new product ideas from existing products or to improve them. As you can see, the list forces you to answer fundamental questions.

The technique is also suitable for groups to get more ideas and inspiration from different points of view. Furthermore, it is certainly interesting to have these questions answered by direct customers of the product you are looking at.

More information: https://en.wikipedia.org/wiki/SCAMPER

Rapid Ideation

Rapid Ideation is a brainstorming technique that can be used by individuals or groups and promises many ideas generated in a short time. There are various forms of this technique, which we will not discuss here. In the most simple variant, all participants write their ideas individually on Post-its within 3 to 5 minutes and then stick them on a wall or another surface for working. Each idea is introduced shortly by the author, and short questions are answered directly.

Photo by Brands&People on Unsplash

It is important to note that this is not a direct evaluation of ideas. Quantity is more essential than quality in this technique. So collect as many ideas on different aspects as possible.

Afterwards, an evaluation can take place. In the simplest case, this is done by “dot voting”, in which each participant gives his or her vote or one point to the ideas. Now would also be the time for a discussion on different ideas. This technique is excellent for overcoming creative blockades.

More information: https://www.thinkfwd.co/toolkit/rapid-ideation

Reverse Brainstorming

There are always situations in which an idea simply does not want to succeed with the techniques described here. Then Reverse Brainstorming is a helpful tool to overcome this blockade! Instead of finding ideas to improve products, we think about how we can make known or non-existent problems of a product worse or cause them. This may sound counterproductive, but this approach actually brings aspects to light on closer inspection that are otherwise rarely considered. If we reverse the ideas about making things worse, we often get measures that can improve the product.

Examples of questions we can ask ourselves:

Identify risks: How or why might the product or a feature fail for the customer?
For known issues: How might we worsen and foster the issue? What underlying conditions could make the issue worse?
Product strategy: What negative aspects might the market bring to our product? Why might sales of our product drop off?
Identify potentials: How might processes become slower and more expensive? How can we prevent our product from becoming more popular?

It is irrelevant, whether you first write down answers on Post-its and then stick them on the wall, or whether you discuss questions together and agree on an answer. Important is, that the answers are then reversed – in other words, we look at the opposite statement and evaluate whether it could be useful as an idea for improvement. This means if we have identified the stopping of all marketing activities as worsening the current situation, strengthening these activities is very likely to bring about an improvement.

More information: https://online.visual-paradigm.com/knowledge/brainstorming/what-is-reverse-brainstorming/

Round Robin

This technique is slightly similar to the Brainwriting technique, but in contrast, it does not rely on the continued development of an idea. Rather, ideas are used as triggers for new ideas.

Ideally, a group of people sits in a circle or around a table. Each person now writes down an idea, e.g., on how to solve a known problem. Once each person has done this, the ideas just noted down are passed on to the person sitting next to them. This person can now use them as inspiration and in turn develop a new idea from them. This is again passed on to the next person.

This is repeated until you feel you have collected enough ideas. Duplicates are then sorted out, and the remaining ideas are discussed and explained in more detail.

More information: https://www.mindtools.com/pages/article/round-robin-brainstorming.htm

Stepladder

Stepladder brainstorming is a good technique to prevent the problem of the “loudest” or to better engage introverted people into discussion. After the topic of the brainstorming session is explained, all but two people leave the room.

The people who are now no longer in the room use the time to come up with one or more ideas for the topic. To involve many perspectives on the topic, each person should do this on their own.

The two people present in the room now discuss their ideas and then call one person back into the room, who in turn presents and explains his or her ideas. Afterwards, the people who were already in the room present their ideas and, in the best case, a discussion with new views follows.

This is repeated until all the people of the group are back in the room and have presented their ideas. A group discussion is then encouraged, which should have the goal of developing these ideas.

More information: https://online.visual-paradigm.com/knowledge/brainstorming/what-is-stepladder-technique/

Five Why's

Constantly asking “why” is strongly reminiscent of the childlike tactic of trying to understand the world. At the same time, it is one of the simplest and most effective techniques on how to understand problems.

Photo by Evan Dennis on Unsplash

One person expresses a problem and another person asks the simple question, “Why or for what reason is this the case?” The person who expressed the problem then answers the question, thereby concretizing the actual problem. This is repeated until the core of the issue is identified. “Five” is considered to be a benchmark here. Sometimes problems are explored after only two questions, or they require more than five rounds of concretization.

This technique can happen in groups of 2 and is very effective. However, more people can be involved on the Q&A if it helps to solve the problem.

More information: https://en.wikipedia.org/wiki/Five_whys

Crazy Eight

Another technique aimed at finding ideas quickly are the “Crazy Eight”.

All participants grab a sheet of paper and a pen and divide the sheet into eight areas, which are then worked on one after the other. Now a timer is set and participants have one (1) minute to visualize an initial idea on a previously presented topic. “Visualize” here means just that: draw your idea and use words if you can't visualize them (but only then). This process is repeated until all eight fields are filled.

Photo by Alex Lion on Unsplash

The time restriction forces participants to not get lost in thought streams too much and encourages them to be spontaneous. It may take some practice to get comfortable with this format. However, very unconventional ideas often come up for discussion this way!

The most important rule here: There are no bad ideas!

Finally, each participant presents his or her ideas and answers feedback questions. You should make sure that ideas are not discussed down to the smallest detail. Afterwards, a dot-voting can be used, for example, in which each participant votes for his or her favorite(s) with a sticky dot or similar.

More information: https://conceptboard.com/blog/crazy-8s-brainstorming-template/

Six Thinking Hats

Even if you can use this technique alone, it's really fun in a group. Brainstorming and problem-solving become more efficient if you consider different perspectives and aspects.

Start by explaining the topic, problem, etc. that you want to brainstorm about. Now assign the roles. Of course, they do not have to be hats, which have to serve as a symbol for different roles. Alternatively, you can use place cards, badges, stickers, etc. You yourself should take the blue role at the beginning. The roles will be taken by the individuals in further explanation. However, there is nothing wrong with groups of 2 or more people taking on the roles.

Photo by JOSHUA COLEMAN on Unsplash

White hat: This person represents the objective analyst in the round, who always takes a neutral standpoint and trusts data, figures, and facts
Red hat: Good ideas are often based on emotions – therefore this person brings in fears, hopes, opinions, and feelings into the discussion
Black hat: Doomsayers are exceptionally welcome – they focus on risks, problems, express concerns and fears and thus personify the critical skeptic
Yellow hat: Of course, the optimist cannot be missing, who is always focused on the positive aspects and brings into play opportunities, advantages, and benefits
Green hat: In a creative process, the creative person cannot be absent, who with his thought-provoking ideas, alternatives, and impulses perhaps also takes unconventional directions
Blue hat: This organizational talent brings structure to the table and safeguards the actual creative process, keeping it and the big picture in view

Now start the discussion in turn and explain your thoughts, ideas, suggestions, etc. according to your role. Record this information on a flip chart, wall, or paper.

Once each participant has expressed their thoughts according to their role, the roles change and so do the perspectives of each person. So pass the “hat” and accept the new role you are given. The discussion round now starts again. Once the roles have been changed all the way through, a group discussion can be initiated or the collected aspects can be reviewed.

More information: https://en.wikipedia.org/wiki/Six_Thinking_Hats

Try it out!

These techniques are excellent methods for brainstorming and problem-solving – but not the only ones. A search on the web will give you insight into plenty of other techniques and possibilities. Use them to overcome creative blockades, involve all members of your team, and come up with a variety of ideas in a short amount of time. Try them out! Have fun with it!

Frank Schillinger is writing for the devlix Blog at https://www.devlix.de/blog
This article was published first here (german): https://www.devlix.de/kreatives-brainstorming/

devlix GmbH: quality, consulting, development

Feature image: Photo by Brands&People on Unsplash

Why a Scrum Master has to enforce processes

jakobhofmann — Fri, 02 Dec 2022 10:38:25 +0000

Of course, who hasn't been through it: The (product) management sets budgetary and/or time targets for product development and “once again the development team has missed the targets". Frustrating! But even more annoying is that the developers also conclude that they have built up technical debts due to the tight schedule, or that they were not even able to set up the testing properly. What’s the reason? Although there was an extra buffer in the planning!

Challenges as a Scrum Master

Regardless of possible methods and ways to avoid such problems in the first place (have a quick look into: Estimates in everyday project life), one of the most important tasks of a Scrum Master is to ensure that a team can achieve its goals.

The Scrum Guide does not necessarily describe practically which challenges a Scrum Master has to face in his daily work - and they are quite difficult. Below are the top three problems that I have encountered frequently in companies or projects:

Waterfall-like approach vs. agility
Disconnection between "Product Management" and "Delivery Unit”
(Too) many people in the company influence the product development

I am often asked how to deal with these problems as a Scrum Master and the answers are difficult to put in practice:
Remember the values of the agile manifesto
Smart and experienced people started thinking about what agility means more than 20 years ago:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Source: agilemanifesto.org

From these values, many possible solutions to the issues named above can be developed.
Example: A product management specifies that a feature or an entire product must be implemented by a certain date. In the process, no consideration is given to the fact that estimates have to be made by the development team. Instead, the product owner is supposed to provide rough estimates. The implementation does not match the specification, the project fails.
Solution: Product management needs estimates. Since rough estimates were enough in the past, the Scrum team was bypassed in the process. A different process needs to be established. The Scrum Master should already intervene when estimations are required from the PO and reflect together with the team on how the process can be modified. Product management must be briefed on the estimation methods and possibilities. Instead of an entrenched process and statements like "I just need a rough, approximate figure", a new process needs to be worked out together. The Scrum Master should also demand that the PO prioritises the important features in coordination with the product management. Accordingly, the PO and the development team can inform about the progress of the features at regular intervals, e.g. in the sprint review. Product management can then adjust the prioritisation at any time in coordination with the PO or actively contribute to the product that is to be developed through feedback.

This example shows how critical the basics of the agile manifesto are and what relevance they actually have for everyday life in a company. In addition, it clearly shows that a neutral person recognises the problems and deduces either to introduce new processes or to remind and demand existing processes.

Transparently show the advantages & disadvantages of agile working methods
People are quick to downplay complex problems with an apparently simple solution. For many, agility is therefore the long-awaited answer to rigid structures and the "modern" working environment that many people desire. It is rarely critically enough questioned whether both the philosophy and the concrete processes in the company are in line with agility. Just as quickly as the announcement "We're doing Scrum!" is proclaimed loudly in the company and the long-awaited "fresh spirit" in the company is longed for, first problems arise. Scrum is not the answer to all problems, but in the best case it delivers more advantages than disadvantages in the methodology for a company. When evaluating the introduction of Scrum, the risks must not be underestimated. On the contrary: the more all individuals in the company are involved in the process - and thus the company - the closer one comes to a common understanding of what agility means in the corporate context.

A Scrum Master should continuously guide this process and insist that the organisational structures outside the "development department" (e.g. sales, management) are regularly trained in the Scrum process and thus help to promote understanding. At this moment, it contributes significantly to the development team being able to focus on what it is there for: developing software.

Following the Scrum process
The Scrum development process is explained in detail on the internet and in various literature. Nevertheless, the Scrum Master has to point it out again and again and also actively engage in conversations to defend the process. A common example is that people with authority in the company (e.g. managing directors, product managers) undermine the sprint cycle and would like to modify the sprint scope. The Scrum Master must support the Product Owner in an advising role and, if necessary, try to talk to the corresponding people. Often it is enough to show that necessary adjustments can be made, but there several dependencies are fundamental to the implementation. Changes to the implementation must be considered in the context of the overall architecture. This results in a significantly higher effort than originally roughly estimated. Especially here, the Scrum Master can clearly point out the dependencies in the development process in a clarifying conversation and therefore turn away from an emotional argumentation towards a logical one that builds on each other. The Scrum process is not an immutable procedure, but is developed and lived by the individual employees. In detail, there are different preferences and needs how the process can be included in the overall company processes. The Scrum Master acts here as a mediator and advisor who adapts the process individually with the people in the organisation to them and their working reality.

Influence on corporate processes
A Scrum Master also has the responsibility to work on organisational changes to help the team. This means that an experienced Scrum Master recognises problems in processes which, for example, have arisen historically or are new due to restructuring in the company. The Scrum Guide does not explain how collaboration with dedicated product management works. Many companies implementing Scrum for the first time have historically separated product management from the rest of the Scrum context. This results in a variety of problems: Misunderstandings in the implementation, different ideas about budget, time and quality or too large a scope of product features then become common. Pressure is then often put on the Scrum team. Frequently it results in an attitude of defiance or actively working against each other against the „bad management". If you find yourself in this situation, you need to take action, because the problems can be solved. The Scrum Master should intervene here in a mediating and moderating way. Possible approaches range from clarifying discussions to training on how to proceed. In the end, each company has to find its own way. It is important that a role that is not actively involved (Scrum Master) accompanies this path and starts the communication.

What possibilities do you have as a Scrum Master to demand processes?

Documentation of the retro results and decisions on a clear board

A good way to create an overview (both for the existing Scrum team and for new team members) is to collect the decisions and commitments from the retrospectives on a separate board. Results of retrospectives are often documented in separate pages in documentation tools (e.g. Confluence). The decisions then get lost with time. A good basis for cooperation is a board, cumulative with all decisions, which is also regularly reviewed by the team in retrospectives. Are the rules still up to date? Are the rules still appropriate and consistent with the team's process? Do the rules need to be modified or discarded? The Scrum Master should regularly check with the team whether the defined processes fit the company in this form.

This board also can be used as a template that a Scrum Master might use to explain to people in the organisation outside the team how the team works and what it values.

Describe your impressions in retrospective

A Scrum Master should only act as a moderator in retrospectives and not be seen as a participant. However, depending on how the team members talk to each other, it is sometimes necessary for a Scrum Master to raise issues. Of course, a neutral position must be adopted in order to describe observations and present the resulting problems analytically and clearly. This helps to find solutions together in the team. Why retrospectives are needed, what needs to be considered in retrospectives and how they can become a successful and motivating factor for the team, we will describe in a following blog article.

Addressing team members in a conversation of trust

Often people have different ideas or even problems with a process that has been defined together - but do not have the confidence to bring their concerns into the discussion. This can result in individual team members not behaving according to the common process or even actively opposing it. A trust conversation helps here, in which the Scrum Master has to find out what fears are behind the behaviour. The Scrum Master has to be very sensitive to the person's fears and concerns. It may also be useful to try to talk to the team if the concerns relate to the team.

Conclusion

Referring to the title of this article, I draw the following conclusion: based on the experiences shown in everyday project work, the importance of the role of an active Scrum Master becomes clear. This person has to demand compliance with defined processes and procedures in software development from people outside the Scrum team, no matter in which position they act. In other words, if this role is not staffed or if the Scrum Master is only seen as an administrator of the team who creates appointments and moderates meetings, it is missing the neutral role in the company that ensures that different people can work successfully together. Misunderstandings, faulty communication and working against each other instead of together is then often the result. It is also important that Scrum Masters intervene in this process in an objective, calm and argumentative manner, as emotional attitudes are usually already adopted by team members. The Scrum Master should be the voice of the rational here, analytically grounded. Most importantly, however, such a role constantly refers to the Scrum framework and never get tired of consistently reminding people in the company of the rules of the game. Only then is it possible that Scrum is really lived in the company and does not just remain a vision of agile idealists. A company can only be as good as its employees, who work together instead of against each other in efficient processes - and at least one person must demand this: the Scrum Master.

Did you or your company recognise parts of it? Feel free to contact us if you need support. We can help you get the processes up and running again.

Jakob Hofmann is writing for the devlix Blog at https://www.devlix.de/blog
This article was published first here (german): https://www.devlix.de/warum-ein-scrum-master-prozesse-einfordern-muss/

devlix GmbH: quality, consulting, development

Feature image: Photo by Denys Nevozhai on Unsplash

Estimate with PERT

Frank Schillinger — Mon, 31 Oct 2022 10:30:26 +0000

Estimating is a critical part of project management, and the Program Evaluation and Review Technique, PERT for short, is one of the most popular estimating methods for this task. And not without good reason! PERT, in addition to helping you to create a project plan, also helps you to make more accurate estimates by considering different perspectives and estimates for each task in your project.

People often try to compare PERT to the critical path method (CPM). However, the focus here is a bit different. Ultimately, it is about breaking down milestones, requirements, features into small and predictable work packages, or more precisely, clearly defined tasks.

The technique was developed by the U.S. Navy in the 1950s to manage the Polaris missile program, one of the most complex projects carried out at that time. The PERT method is based on three estimates for each work package in a project: the best case, the worst case, and a most likely case. A weighted average is calculated from these three estimates, which is then used as the estimate for the overall cost calculation.

More information:

In this blog post, we’ll walk you through 4 steps of how to use PERT as a tool to estimate your projects more accurately.

Break down your project into smaller topics, features, and tasks to estimate in smaller chunks.
Determine the best, worst, and most likely effort for each activity or task in your project.
Calculate the weighted average for each task.
Add up all the weighted averages to get the overall estimate for a feature, requirement, or the entire project.

Let’s take a closer look at each step.

Step #1: Break down your project into smaller topics, features, and tasks to estimate in smaller working packages.

This step can be very time-consuming, depending on the complexity of the project and the level of detail of the estimate you need. You may also find it helpful to use a visual work breakdown structure (WBS), which breaks down requirements into smaller and smaller packages at different levels. A function-oriented breakdown is usually recommended in software development. The goal is to have estimable tasks instead of having to process vague high-level requirements.

This naturally requires an accurate analysis of all requirements in complex projects. However, the technique can also be used perfectly for individual stories or backlog items in agile projects. In these, a decomposition or a regular refinement of all items is typically planned anyway.

So think about the requirement, necessary tasks and the existing constraints — functional and technical.

More information:

https://en.wikipedia.org/wiki/Work_breakdown_structure

Step #2: Determine the best, worst, and most likely effort for each activity or task in your project.

Once you know the work necessary to implement a requirement, look at it and answer the following questions for each task:

How long does it take to complete this task if the implementation runs perfectly and there are no delays? (Optimistic case)

How long does it take to complete this task if the implementation is likely affected by delays, dependencies or other influences? (Realistic case)

How long might it take to complete this task if the implementation is impacted and disrupted by unexpected influences? (Pessimistic case)

Experience plays a big role for all answers. As soon as you are unsure about answering the questions, you should ask for support. Often a brief discussion about a work package may help. From experience I can say that an estimation session with another person is very valuable. The second person should have a different perspective on the project. Often you can identify gaps in your knowledge in the short term and close them.

Step #3: Calculate the weighted average for each task.

We now have three estimates for a task. So let’s do the math!

To achieve this, take the values for the best case, the worst case, and the most likely case and insert them into this formula:

(optimistic + 4 · likely + pessimistic) / 6.

The calculation gives the time required to implement a task most likely.

Example: we estimate that a validation function for a web form is done in the best case in 1 day. From experience, we can say that we probably have to go through several tests and correction loops and estimate the realistic duration to be 2 days. However, since the implementation depends on a programming library that may not come with all the features we need, the implementation could possibly take up to 5 days.

This results in the following calculation:

(1 + 4 · 2 + 5) / 6 = 2.33 days of likely implementation time.

You can also calculate a possible standard deviation, which you can include in your calculation as a safety buffer:

(pessimistic — optimistic) / 6.

This is always useful if the estimate is based on high or even extreme uncertainty. For the most part, this becomes obvious when the values are widely divergent.

To stay with our example above:

(5–1) / 6 = 0.67 days of likely standard deviation.

If we are uncertain about the details, we can sum the two values to mitigate risk in the planning.

2.33 days + 0.67 days = 3.0 days of likely and planable implementation time for our example.

Step #4: Add up all the weighted averages to get the total estimate for a feature, requirement, or the entire project.

The result is ideally a detailed list of tasks, including their estimated effort. You can use this advantage to create a critical path, for example, to refine and improve your project planning.

We have had excellent experience with this approach. Go for it and make an estimate based on an already implemented project or feature, let the tasks be estimated by people who were not involved in the implementation, and compare the results. Then decide if this technique works for you and your next project.

You can find many templates on the web, mostly for Excel, which can be used as an exceptional tool. In the best case, use them to prepare your upcoming estimates and learn how to apply this technique.

More information:

If you want to learn more about methodologies for estimating projects, read our blog posts at https://www.devlix.de/blog/, https://medium.com/devlix-blog or https://dev.to/devlix-blog!

Frank is writing for the devlix Blog at https://www.devlix.de/blog
This article was published first here (german): https://www.devlix.de/quickie-schatzen-mit-der-pert/

devlix GmbH: quality, consulting, development

Feature image: Photo by Vishwarajsinh Rana on Unsplash

Estimates in everyday project life

Frank Schillinger — Fri, 30 Sep 2022 07:28:01 +0000

A sales consultant, a project manager and a developer walk into a bar.

What sounds like the beginning of a bad joke actually has potential for a lot of drama and mutual misunderstandings galore. Often the drama starts with the topic of this text, estimating the effort or budget of a software project.

I would like to highlight what I consider to be the biggest problems with estimates, present estimation methods and approaches to solving them. In the best case, the text serves for challenging and improving one's own approach to estimation.

What problems do we have with estimates in software development?

Summary:

Estimates based on a thin factual base, or more precisely in the presence of extreme uncertainty, are necessarily inaccurate
Estimates are sometimes communicated based on a problem description; however, reliable estimates can only be based on solution approaches, which in turn requires a proper analysis of the problem
The authority to propose and communicate to the customer is often held by people who do not have sufficient experience in software development
The expectation of the customer is not adjusted to artificially low estimations
Implementation and estimation methods do not match the complexity of the project
Holding on to management and planning methods that do not fit into a complex and ever-changing digital world
A team has to implement features that they have not estimated themselves

Raise your hands: who has ever been asked for a price for a project for which only rudimentary information was available, and a rough estimate was intended to serve "only as an approximate pointer"?

The simple and often quoted example gets to the point: If you ask a car salesman what a car costs, he will not immediately want to give you a fixed price, on which you can even commit him in the worst case. He will first ask you about the brand, basic features and additional configuration features and whether it can also be a pre-owned model. And only once he has all the information he needs, he will give you a price and make you a binding offer. Logical? Of course!

After all: only known and understood(!) requirements and boundary conditions for a project can be estimated.

Problem No. 1 and for me, the most serious, in direct words: Estimates made on a thin factual base, or more precisely in the presence of extreme uncertainty, are necessarily inaccurate.

Photo by Jon Tyson on Unsplash

Unknown information and not articulated requirements cannot be estimated! Do not be tempted to make binding commitments if you have not been provided with sufficient information. The difficulty here is to clearly define "enough information". The amount of information needed depends on a person's experience and skill set directly.

I consider this problem to be always present and extremely critical. We need to keep in mind that we often don't know that we don't know something yet.

We know that we don't have information on certain topics\

→ we request this information from stakeholders, we can analyze it, and we can estimate it
We don't know that we don't have information on certain topics\

→ we stumble upon new information during requirements analysis, in the worst case during implementation, and plan for new features, for instance, that increase the scope of the project/product, putting schedule and budget in risk
We don't know that we don't have information on certain topics and which also influence or challenge our existing knowledge\

→ we stumble upon information that requires re-planning of already specified features, in the worst case making already implemented features obsolete or influencing them and so on, thereby torpedoing the overall project planning

There are surely other manifestations of the problem. However, let's note that with increasing complexity, the one described under number 3 becomes more and more likely. A first hint that we should iterate estimates, whether at the milestone level or by constantly adjusting and refining an existing estimate.

An example from my practical experience. Speaking with the sales department during a conversation about what was predictably a very complex and lengthy project, I requested a workshop with the customer to bring light to the project and learn essential things needed for an estimate. I warned about communicating an approximate budget range before we were provided with key information. After all, we as contractors also wanted budget predictability in the implementation of the project. This request was wiped away with a quick "We can't annoy the customer with questions right from the start." "I see" I thought to myself, "have fun then." And it happened as it had to happen. An estimate based on the available information was "nicely calculated" by the Sales department (= "corrected" downward to be able to stand up to the competition) and manifested in a fixed offer. The order was placed, the sales staff raised their glasses with commission champagne and halfway through the implementation of the project the budget was exhausted. The nerves were on fire -- with our developers, our project manager, our management and, of course, with the customer. Congratulations. If only someone had warned us.

And unfortunately, it's not that unusual for contracts to come about like this. After all, in sales you have to be fast. Otherwise, the competition will run out of the room with the contract.

My example brings two other critical problems to light.

Problem No. 2: The authority to make offers and communicate with the customer often belongs to people who do not have sufficient experience in software development.

A shift in focus from quick promises to secure contract agreements for all parties must be a high priority for the company's own health. Often, a discussion between an experienced IT consultant or software architect and the customer right at the beginning can help. If the persons responsible for contract signing have little or no experience in software development, people who have such experience must be involved in the process for the parties' own safety.

Problem No. 3: The customer's expectation is not adjusted to artificially low estimates.

An estimate of effort always refers to the known pool of information. A change in only one of the two parameters must also result in an adjustment of the other parameter. Development teams are not expected to do the same work in less time. Quality losses and budget overruns are therefore usually unavoidable.

To be clear, if development teams estimate a 15-day effort and a 10-day offer is made to stay competitive, the estimators cannot be expected to complete the implementation in that reduced time. One is thereby shifting all the responsibility regarding the success of the project. An obvious failure and, unfortunately, a not so uncommon phenomenon in agencies.

Problem No. 4: The implementation and estimation methods do not match the complexity of the project.

I have always argued that as the complexity of a software project grows, iterative and agile development must be accompanied by iterative estimation of effort, or at least by refinement of an initial estimate. Whether we divide projects into milestones or whether we actually use an agile framework is secondary. We can only estimate manageable and thus imaginable work packages.\
For small projects, classic approaches like waterfall may make more sense.\
What does not make sense, on the other hand, is a fixed and complete prediction at the beginning of an iteratively developed project. Agile frameworks therefore address these problems with their estimation methods, which should be used.

The fact that customers or management want to make a budget planning that is safe in advance is understandable. However, often this leads to the problems described earlier. And therefore the customer or management is also a problem in this equation.

Problem No. 5: Holding on to management and planning methods that do not fit into an increasingly complex and constantly changing digital world.

It must stop that the conditions of a complex software development adapt to the higher-level management! Instead, management must face reality and adapt, refine, and change its approaches. Only if this happens, problems with estimates of effort can be solved and thereby with the development of complex software as a whole.

A "you must learn to estimate more reliable" often comes easily from those who cause these very problems due to their inflexibility. "Then provide me with further information and adjust your planning" should be the answer here.

One last point I would like to address is the responsibility for estimation.

Problem No. 6: A team has to implement features they themselves have not estimated.

A person who has 10 years of experience in developing complex software will come to a different estimate of the expected effort than a person who has only been "at it" for 2 years. It is the same with theorists and practitioners. If estimation certainty is top priority, then the people who are to implement the project must work out the estimate of the features. The primary focus is on what effort this team is likely to have based on their expertise and specialization. So, it estimates itself -- this should not be done by anyone else. Unfortunately, the situation is often quite different, especially in the classic project approach. Agile frameworks thankfully offer tools to solve this problem.

My conclusion and thesis: People are bad at making reliable estimates of effort. But they are even worse at communicating and processing these estimates. And this lack of ability increases significantly as software solutions become more and more complex.

There are ways and methods to address these problems.

So, how can we minimize problems with estimates in software development?

Summary:

Knowledge is power -- requirements engineering helps to create a foundation for estimation
Project planning must be adapted to the complexity of the solution to be delivered and its environment
Estimates should be regularly reviewed during the entire development of the project and adjusted to the current state of knowledge.
The right estimation and planning method is key to increase reliability and predictability
Estimates from the implementing teams are more valuable than estimates from consultants or planners.
Including estimators in customer communications prevents misunderstandings
Taking responsibility in the context of your roles and knowing your limits are essential and important characteristics for a realistic estimation of a project.

Let's turn away from good and bad practices in project management at this point, let's take a step back and focus on how we can make estimates as realistic as possible.

Knowledge is power -- requirements engineering helps

Foremost, let's keep in mind that an estimate is based on knowledge. In project requests and after the first discussions with the customer, we usually only know "headlines" or requirements that are stated in very general terms and are not specific enough. The more we challenge such "headlines" and go into conversation with the customer or with the stakeholders, the more we learn about the small building blocks, about the "small headlines" if you will.

It is worth mentioning that the idea of "everything being clear" and every required piece of information being available at the start of implementation is pure utopia. It will always be necessary, even during implementation, to analyze new requirements, new information, and so on, and thereby adding them to the knowledge that has been gained.\
Therefore, always plan enough time for requirements management and analysis in your projects. Even if you have ideally planned a requirements analysis phase before implementation in classic implementation projects like waterfall.

Amount of information during progress of project with previous requirements analysis

And yes, consistent requirements management is also immensely important in agile projects. On the one hand, this is a task of a product owner, on the other hand, the requirements analysis in agile frameworks is also mapped with refinements or similar events. In an iterative approach, this work must be planned and executed as a constant and parallel task to the development.

In the last few years, I have heard the most absurd reasons (most commonly time/money) why people would like to skip a properly performed requirements analysis. And I've seen the projects fail just about every time. Mostly by significantly exceeding the agreed budget and timeframe. And this was almost without exception due to countless reworking cycles because drum roll requirements were not understood or not formulated and specified concretely enough.

Adapt project planning to a complex reality

Split complex and expected lengthy projects into small and estimable packages and plan them as sequential milestones, or plan the project as an iterative implementation from the beginning. The more complex a project, the more agile frameworks help -- even with estimating effort!

Smaller packages are easier to plan, reduce the risk of all parties involved, and simplify budget planning. Estimates are greatly simplified and can consider new conditions that have changed or emerged since the start of the project.

A challenge can be to convince your client of these benefits if they have to calculate with fixed budgets from the beginning. Avoid this inflexibility becoming a disadvantage for you, and take this aspect into account when evaluating your risk as a contractor! Occasionally, it may be better to reject a project.

Check and adjust estimates regularly

If an estimate for a complete project or for individual packages was necessary long beforehand, it is worthwhile to look at it periodically. In these cases, the project partners should agree on a regular review of the estimates and adjust them as necessary to reflect any new conditions and requirements. Both the client and the contractor must be aware that this may result in budget or scope changes. It is therefore important that this fact is communicated clearly and transparently.

Use the right estimation and planning method

Photo by Markus Spiske on Unsplash

Depending on the nature of the project, depending on the requirements of the customer and depending on the implementation methodology, certain estimation methods are more suitable than others. In the following, I try to give an overview of these methods. This overview is definitely not complete. It covers methods I have come into contact with in the last few years. Furthermore, you will find methods that are more for planning and not for the actual estimation.

Top-Down method

Classic planning and estimation method
Appropriate, if a fixed project duration or the date of the project end is given, and the implementation is planned in a classic approach
This estimation method assumes that requirements have been analyzed and understood beforehand
The granularity of the estimate determines the time required for the estimate, which also has to be considered

This classic estimation method is primarily suitable for project scenarios with demanding time or budget constraints. This requirement is the starting point for all further steps towards an estimate. The time span can be divided into phases, i.e., smaller time spans, which give us the possibility of control and readjustment in the planning. Requirements/features can now be planned across these phases. This may even be done thematically, i.e., technically related requirements are planned together in a milestone or phase. To make a realistic estimate possible, the requirements must be still divided into tasks and estimated individually. The result is a "top-down" planning and, in the best case, a detailed "bottom-up" estimation. Often, the creation of tasks is omitted and the requirements themselves are estimated, which saves time but brings some inaccuracy. Moreover, in this method, the estimations are often not done by the developers themselves, which again increases the inaccuracy.

If the estimated project duration is longer than specified, adjustments must be made. This means that requirements with the lowest business value are not implemented in order not to exceed the time limit. The rule is therefore: implement as many features as possible in the specified time.

More information: https://en.wikipedia.org/wiki/Top-down_and_bottom-up_design

Bottom-Up Method

Classic planning and estimation method
Appropriate if requirements are known, the project duration is not specified and the implementation is planned in a classical approach
This estimation method assumes that requirements have been analyzed and understood beforehand
The granularity of the estimate determines the time required for the estimate, which also have to be considered

Bottom-Up, project duration results from the sum of all estimates, estimates on task or feature level

Also known in the traditional context, this method relies on an analysis of the requirements beforehand. In contrast to top-down estimation, the starting point here is the pool of known requirements. These can be divided into individual tasks and then estimated. However, for time reasons this is often omitted -- even if this results in more inaccurate estimates.\
The estimates are summed up to give an anticipated duration of the project.

This method is often more accurate than the top-down method. However, it tends to take more time. And as mentioned earlier, the accuracy also depends very much on the knowledge of the estimators.

More information: https://en.wikipedia.org/wiki/Top-down_and_bottom-up_design

Three point/time estimation / Program evaluation and review technique (PERT)

Appropriate for estimating entire projects and individual features
Suitable for classic and iterative process approaches
This estimation method assumes that requirements have been analyzed and understood beforehand
The granularity of the estimate determines the time required for the estimate, which also needs to be considered

Three-point/time estimation / PERT, calculation of estimated values

A technique that aims to take uncertainties into account is three-point estimation, three-time estimation, or simply "PERT". This technique was developed as early as around 1958 and was first applied in a project which had to take extreme uncertainties into consideration and the estimates therefore had to be based on probabilities.

The smaller the packages to be analyzed, the better they can be estimated. Once this has been done, each package is estimated optimistically (ideal case), realistically (possible value from experience) and pessimistically (worst case). Using the formula shown in the illustration, one now calculates an estimated value that "probably" applies to this package. Teams may adjust the formula slightly if the calculated estimated values differ notably, often to the positive or negative side relative to the time actually worked on.

The method is appropriate in both classic and iterative project procedures for estimating the expected effort. It can be applied to large milestones as well as, for example, only for estimates of individual features.

Note: We will discuss this technique in more detail in an upcoming blog article.

More information: https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique

Two point/time estimation

From-to statements are probably the most common form of estimates when it comes to an initial budget size for a feature or project. Contrary to the PERT technique, no realistic value is used here. Only the optimistic and pessimistic estimates are considered. My experience is that in most cases the average of these two values is used for a communication towards the client, although from-to statements would be more honest and would reflect the uncertainty in the estimate. While this technique is suitable for a quick estimate, I believe it is inappropriate for making definite claims or even contractual agreements. I strongly recommend refining such estimates.

Analogue estimate

If you have already implemented similar projects in the past, you can use this information about implementation duration, difficulties, etc. for the estimate. The more accurate this information is, the more accurate the estimate will be.

If you are tasked with implementing software that may use the same components from project to project, this technique is well suited.

Parametric estimation

This technique also uses information from past projects. It attempts to identify differences between the two projects, estimate them, and thereby determine the total effort.

As with analog estimation, this technique is suitable in an environment where the projects are very similar, but there may be differences. This is the case, for example, with customizations of white-label solutions that need to be adapted to different needs.

Story Points, shirt sizes and so on

In my opinion, an estimation statement in hours, days or similar based on Story Points is not applicable. Since Story Points are primarily intended to reflect the expected complexity of a task/requirement, this must first be converted into a time-based statement. Often, Story Points are multiplied by the time spent on a past 1-Story Point requirement to make a statement about time and budget. So if a 1-story point task took 1.5 hours to implement, an 8-story point task will take 12 hours to implement in sum, right? Not necessarily.

What is often ignored is that requirements of comparable complexity do not necessarily take an equally comparable amount of time to implement. Complex tasks, for example, can be implemented more quickly by experienced developers, or they can simply be completed quickly. In contrast, tasks with low complexity may take a long time because they may simply be busywork.

In my eyes, if time estimation is the goal, mapping tasks with shirt sizes or other size specifications makes more sense. In doing so, we can assign a defined number of hours to the sizes. The estimating people assign these sizes to the individual tasks and thus gradually determine the expected effort for a sprint or project.

The use of shirt sizes has the advantage that, for example, "L" can also be used to indicate From-To durations. Of course, these must then be considered in the overall estimate. For the estimator, however, the estimation process is made much easier.

#NoEstimates

A more radical and fundamentally different approach is taken in the idea that has been discussed under the hashtag #NoEstimates and has created quite some buzz. Being radical means nothing more than finding and using an approach that avoids all the mentioned problems from the very beginning.

The idea does not mean that no forecasting can or should be done at all. Rather, this approach does an end to classic techniques in an increasingly complex world of software development. Instead, it relies on historical information and on increasing security over the lifetime of the project.

Under the hashtag mentioned, you can find many articles on this topic, and it is worth taking a look. To summarize, the idea aims at

avoiding efforts for inaccurate estimations in a constantly changing environment
and to use past iterations/cycles and the experience from them (in an agile approach to implementation) for predictions.

Furthermore, various ideas are also discussed that have risk mitigation as a goal. This can be achieved, for example, through chunked funding of milestones or features and also by the resolution to be ready to deliver or finish the project at any time.

Using the knowledge of previous sprints or milestones, predictions become more accurate during implementation. This idea contrasts with classic planning methods that have fixed budgeting over a long period as a goal. To solve this problem, management must be willing to question their approach and take steps towards the operationally involved people.

As with any method, there are proponents and opponents of this approach.

More information:

Estimates from first hand

Following the DevOps approach "You build it, you run it.", I would like to phrase a "You estimate it, you build it.".

Software developers design and implement solutions. They develop the most suitable solution approach from their perspective within the given solution space, which is limited by the given conditions. This solution approach must be estimated!

It does not help if developers are "dictated" a given time frame for the development of a solution. Even worse, if this framework is given by people who do not know the solution space or simply have no experience in development. Such an approach generates many things -- but no motivation among project participants.

Therefore, the following applies: An estimate cannot be made more precisely than by the people implementing the software. Because they can also estimate themselves best and price in the know-how of the team. This is the reason, among other things, estimates by the team are always assumed in the Scrum Framework and are executed regularly.

Inclusion of the estimator in customer communication

Every estimate is followed by questions. Both in internal communication and in external customer communication. Typically, these are queries that want to shed light on the context of the estimate. Understandably, people usually want to know the intended solution approach on which the estimates are based. Even though this may have already been outlined in written or verbal form, detailed questions will always arise. Care should be taken to ensure that these questions are answered primarily by the estimators to avoid misunderstandings and complicated communication paths.

Taking responsibility, know own limits

Different roles mean different responsibilities. And as always, if one is unable to perform a task in one's own area of responsibility, for whatever reason, help must be found. This requires knowing one's own weaknesses and limitations. And yes, it also requires that you sometimes step outside your comfort zone. False pride is of no use to anyone. Last of all, oneself.

The customer, the party requesting estimates for a software solution, must provide information necessary for a realistic estimate upon request. In the best case, missing information is discussed by the client and the contractor on an equal level, i.e., people who are technically or thematically able to discuss the requirements. We have long outgrown the age of "silent post", meaning that communication may only take place through one point, and so has software development.

The contractor must ensure that he uses an estimation method that fits the agreed project approach and that he has the necessary information available in the required level of detail. If knowledge gaps regarding the requirements cannot be addressed internally, information must be gathered with the customer. And this must be done in direct communication, without any detours.

Estimators and developers should at all times request the things they need to realize a task. In the context of estimation, this is information needed to consider requirements. Directly addressed to these individuals: Request information needed to fill knowledge gaps. Your name is associated with your estimates. Remind others of their roles and responsibilities if necessary.

Let's learn -- let's adapt to these complex circumstances

As we have seen, estimates are often complex and time-consuming. However, through estimation cycles, we also contribute our part to risk mitigation. We learn details of the software to be implemented and its environment, and constantly expand our horizons through consistent requirements engineering. If you consider one or the other piece of advice, I would be happy about it. You will notice that you can make estimating and also dealing with it much easier.

Each team has to learn for itself which technique it knows best and when to use it. Experiment, do things differently, challenge yourself, learn what works best for you and your environment.\
The management, which is truly interested in low-risk projects, should give you space, involve you in the communication towards the client and, if necessary, verify and adjust their procedures. Only together, complex software projects succeed.

Be transparent with the customer at all times and challenge him. The customer is the origin of requirements and will help you to eliminate gaps in your knowledge. Never compromise this knowledge for the wrong reasons -- even if this means longer estimation sessions or intensive requirements management.

Estimation will certainly not become easier in the future. As you can see, estimation projects are strongly influenced by external influences. However, it does not help to go into a defensive mode here. We have to keep up with the increasingly complex world and find new ways of dealing with it. This applies equally to top management, project management, consulting, development and operations. Get on board -- there is no other way.

If the problems described above sound familiar to you, and you need support or consulting, please do not hesitate to contact us at https://www.devlix.de/kontakt/.

Frank is writing for the devlix Blog at https://www.devlix.de/blog
This article was published first here (german): https://www.devlix.de/schaetzungen-im-projektalltag/

devlix GmbH: quality, consulting, development

Remote debugging of Java apps in Kubernetes

Michael Weidmann — Thu, 15 Sep 2022 09:36:17 +0000

"It works on my machine ¯_(ツ)_/¯" - the older generation of developers often used this phrase in daily life. With Docker and Kubernetes there are platforms that solve such problems today.

But don’t be too happy about it: sometimes your application does not do what was implemented and tested locally. An experienced developer would turn on the debugger in such a case, but is that so easy on a Kubernetes cluster? Yes, and we'll show you exactly how in this blog post!

For the sake of simplicity, we will use the IntelliJ development environment throughout this post, but that should not be a big limitation - other development environments offer similar features.

Concept

The underlying idea is to enable debugging on a port in the Kubernetes pod (in which the Java app is running). This port must be exposed by the Pod.

Afterwards, a local port must be forwarded to the open debugging port of the pod using Port Forwarding. Last but not least, JVM Remote Debugging must be started in the development environment with the forwarded local port. The following diagram shows the structure of remote debugging in a Kubernetes cluster:

Figure 1: The concept of remote debugging in a Kubernetes cluster

Step 0: Setting up JVM remote debugging in IntelliJ

The first step is to set up remote debugging in IntelliJ. To do this, open please the configuration window for Run Configurations:

Figure 2: New "Remote JVM Debug" Run Configuration

Create a new Run Configuration by clicking on the plus symbol in the upper left corner and selecting Remote JVM Debug from the list.
Then you can give the configuration any name you like.
The standard configuration usually does not need to be adjusted. If the default port 5005 is used elsewhere in your application, you can change it in the configuration.
Now copy the command line arguments, they will be needed in the next step.
Finally, save the configuration, because you will need it later.

Step 1: Enable debugging in the remote JVM

We usually package our applications in Docker Images, which we build with such a Dockerfile:

FROM eclipse-temurin:17-alpine

ARG ARTIFACT
COPY $ARTIFACT app.jar

ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar /app.jar"]

Important is the variable $JAVA_OPTS in the ENTRYPOINT. We use this to insert the previously copied command line arguments. We do this by adapting the deployment resource in Kubernetes. With kubectl get deployments you can display a list of your deployments and with kubectl edit deployment <DEPLOYMENT_NAME> you can adjust the deployment as follows:

spec:
  containers:
    - ...
      env:
        - name: JAVA_OPTS
          value: <COPIED_JAVA_OPTS>
      ports:
        - name: remotedebugging
          containerPort: <PORT>
          protocol: TCP
      ...

Replace <COPIED_JAVA_OPTS> with the copied command line arguments from IntelliJ.
Replace <PORT> with the port you use for debugging, in our case 5005.

Once you have done this, you can close the editor and Kubernetes starts a new deployment for you. You can check this with the command kubectl get pods. A new pod should have been created. Important for the next step: Copy the name of the pod!

Step 2: Port Forwarding

After the Pod has been restarted, the debugging port of the Pod must be forwarded to your local machine. This can be done with the following command: kubectl port-forward <POD_NAME> <LOCAL_PORT>:<POD_PORT>

<POD_NAME> is the name of the pod you should have copied in the previous step.
<LOCAL_PORT> must be replaced with the port used locally for forwarding and to which the development environment connects for debugging.
<POD_PORT> is the port you opened in the deployment configuration in the previous step.

Step 3: Happy Debugging!

Finally, the debugging configuration created in Step 0 must be started and the following message should appear: Listening for transport dt_socket at address: 5005. 🎉

Now you can set breakpoints and find some bugs!

Resources

Michael Weidmann is writing for the devlix Blog at https://www.devlix.de/blog
This article was published first here (german): https://www.devlix.de/remote-debugging-von-java-apps-in-kubernetes/

devlix GmbH: quality, consulting, development

Quickie: Requirements elicitation techniques

Frank Schillinger — Mon, 01 Aug 2022 07:08:48 +0000

Anyone who is involved in the management of requirements in their daily work knows, that every new project/product has different conditions. Technical, professional, human, organizational. You inevitably come to the point where you ask yourself which requirements elicitation technique is most effective and best for the stakeholders.

Since this question is not new, smart people have thought about it before. For some time now, decision tools such as the one shown below have been floating around the Internet, and we would like to introduce one to you here. It is an excellent tool to identify suitable techniques by assessing a few parameters.

Decision matrix on elicitation techniques

Download this matrix!

This matrix can help you enormously with an initial orientation or, in the best case, even give you new ideas. Of course, as always in dealing with stakeholders, a certain amount of empathy will help you in this case as well.

We usually go through the scenarios described in the table header from left to right and decide which of them are relevant when selecting a technique. Then we can go through row by row, focusing on the techniques that have the most matches in the green (very suitable technique) and yellow (also suitable as an alternative technique) area.

We hope this tip helps you. Success to you!

Frank Schillinger is writing for the devlix Blog at https://www.devlix.de/blog
This article was published first here (german): https://www.devlix.de/quickie-erhebungstechniken-fuer-anforderungen/

devlix GmbH: quality, consulting, development

Prioritization with the Kano model

Frank Schillinger — Thu, 08 Apr 2021 13:24:12 +0000

After our articles about the MoSCoW method and the more simpler 100 Dollar and Scale methods, today in the third part of our series we would like to talk about another method that is used successfully when it comes to prioritization of requirement pools. The goal of this method is to maximize the customer satisfaction of your product/project or service. We can achieve this by identifying three parameters against which requirements must be measured: Excitement, Performance and Expectation (or basic characteristic).

Noriaki Kano, developer and namesake of the Kano model and former professor of the Tokyo University of Science, tracked the goal of aligning the (further) development of a product and/or a service and the expected customer satisfaction. This is in contrast to the assumption that any further development of a product automatically increases satisfaction.

The model was developed 1978 and is successfully used in the most different ranges of the economy. Also in software development the model is used and should be considered with an upcoming planning for a new or further development of a product.

By the way, Noriaki Kano was inspired by the two-factor theory of Frederick Herzberg, American professor of industrial science, who already in 1959 described the motivators and hygiene factors that have a direct influence on satisfaction and dissatisfaction at the workplace or on the work situation.

Characteristics of a product

The Kano Model describes five attributes that are assigned to functions or requirements of your product/project. The three most important characteristics that we constantly deal with in everyday project work are:

basic attributes, must-be quality
performance attributes, one-dimensional quality
excitement attributes, attractive quality

Figure: the three main attributes of the Kano Model

In addition, there are two features that we do not consider in detail in this article:

Irrelevant features that are of no concern to the customer, whether they are provided or absent
Rejection features, which have a negative impact on customer satisfaction if they are present, but a positive impact if they are absent

Before we can classify requirements/features in the three dimensions (Basic, Performance, Excitement), let's have a look what these features mean.

Basic attributes

A question to start with: which functions does your customer expect at least to be able to use your product? The answer should be a list of requirements that must be implemented and which, if missing, will most likely lead to irritation for the user.

Figure: basic attributes primarily meet the expectations of your customers

As an example, let's consider an online store. Here, a product list, the display of product information and an ordering option are absolutely essential. These functions are to be evaluated (of course on a high level) as basic features and ensure a basic acceptance of the product.

See these features as a foundation on which you can steadily increase satisfaction through the other two attributes/characteristics. A product does not become a success just by providing basic functionality.

Performance attributes

It gets interesting with the possible top performers of your product/project. These are functions or features that make customer satisfaction grow linearly.

Figure: performance attributes increase satisfaction linearly

To stay with the example of the online store: a sortable and filterable product list contributes just as much to satisfaction as a widely accepted payment method in the ordering process.

These functions don't reinvent the wheel, but they do increase satisfaction enormously - and thus also directly the acceptance of your product.

Excitement attributes

Lastly, let's move on to features that exponentially increase customer satisfaction.

Figure: excitement features increase customer satisfaction enormously

Let's take our online store as an example again: If we present product reviews that not only reflect the opinion of our own customers, but also take into account reviews from external portals or stores, we create more trust in the products we offer. If we offer suitable product recommendations based on a comparison of customer profiles, the customer feels understood and, in the best case, is also grateful for this very product recommendation. This satisfaction is reflected in a higher number of orders.

Whether new functions that no other competitor product offers, or details that make functions unbeatable compared to the competition - they provide the valuable WOW moment, usually exceed expectations and thus inspire the user of your product.

But how do we find out which attribute we can assign to product requirements/functions?

Customer opinions are key

Whether your customers are customers in the sense of buyers in a store or stakeholders who demand functions in your product/project, what is important is their opinion of the planned functions. In this way, we can analyze a possible business value, which in turn helps us prioritize a product backlog.

Did you create personas for your product/project? Use these as well and look at the requirements from the respective perspectives!

How do we now survey our customers to be able to classify requirements and functions into the categories mentioned above?

We help ourselves with a prepared questionnaire, which

lists and describes requirements/functions for which we would like to get a customer opinion,
asks two questions about each requirement (positive and negative) and
allows a classification based on the answers and, in the best case, does this automatically.

As just mentioned, we evaluate two questions:

How would your customer feel when the named requirement would be provided?
How would your customer feel when the mentioned requirement would NOT be provided?

Where there are questions, there must be answers. Provide these pre-written answers for voting and customize them if needed:

I would be very pleased
I assume that
I don't care / I don't attach any special importance to it
I can live with it / I just put up with it
That would bother me

Here is an example of what your questionnaire could look like:

Screenshot: Kano questionnaire in Excel

We achieve a classification of the respective requirement/function by the given answers through a matrix, which is structured like the following example.

Screenshot: Kano Matrix

Let's take our online store as an example again. In our requirements pool, there is a requirement that describes a chat as a support channel that is to be made available to potential customers for communication with the store's employees. We ask a customer about this:

Question: How would you feel about us providing this feature in the store? Answer: I would like it!

Question: How would you feel if we did NOT provide this feature in the store? Answer: I would not like it!

Now let's take a closer look at the answers. According to the matrix presented, the requirement would represent a performance attribute of your product that contributes to customer satisfaction.

If we now apply this method to all collected requirements, we get a sortable and filterable pool that simplifies further planning and makes the product/project clearer and more tangible. However, this will only succeed if you give the results of such an analysis an appropriate weight and also put them above your personal preferences!

By the way: There are enough templates for questionnaires on the Internet. Adapt them to your needs!

Use this instrument to interview all relevant people for an analysis of your product/project. This will give you a more accurate picture across all personas and stakeholders.

If you have a manageable pool of evaluated requirements/functions, it is also a good idea to visualize the results, for example with a scatter plot. This makes discussions about the results much easier.

Make use of the Kano Modell

You can use the Kano model not only with an existing requirement pool.

Product and service strategies

If you are in a dynamic market with your product or service, which always brings new or changing requirements, you can use the Kano model for a constant and continuous analysis. It is important to keep an eye on the competition. Over time, performance characteristics become basic characteristics, enthusiasm characteristics become performance characteristics. You can use this knowledge for the further development and improvement of your product. Only those who know the requirements and their value for the customers will also keep their customer base in the long term.

Business strategies

If we take a broader view and evaluate our own company products instead of the requirements of a single product, for example, the Kano model can also be used to make strategic decisions about the product portfolio. This is particularly important in competitive market segments.

Ultimately, services, organizational units, etc. can also be evaluated, analyzed, and thus planned in the enterprise environment.

Conclusion

The Kano model has proven itself and we recommend you to try it out for your next product or project! It has helped us especially in the agile environment, because you can outline and determine the scope of an MVP very quickly. If you also carry out an evaluation at regular intervals, a big part of the product backlog prioritization is done.

We also observed that an evaluation of the responses of all the stakeholders involved also gives you the opportunity to interesting discussions that may require subsequent prioritization of the requirements. Fortunately, nothing is set in stone here either.

Adapt questionnaires to your needs and your environment! Do not only interview stakeholders but also present the results to them. Any follow-up discussion based on your analysis is important and valuable. Moreover, this is an elegant way to involve stakeholders in the planning process and thus gain more acceptance for your product or project.

More information about the Kano Model: Kano model - Wikipedia

Frank Schillinger is writing for the devlix Blog at https://www.devlix.de/blog
This article was published first here (german): https://www.devlix.de/priorisierung-mit-dem-kano-modell/

devlix GmbH: quality, consulting, development

Feature image: Photo by İrfan Simsar on Unsplash