DEV Community: jakobhofmann

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

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

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