DEV Community: Frank Schillinger

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

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

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

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

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

Prioritization: 100 Dollar Method and Scale

Frank Schillinger — Thu, 11 Mar 2021 08:25:05 +0000

In our introduction of the article about the MoSCoW method we have already pointed out the importance of a good prioritization of requirements. Now we would like to present two more methods that can greatly simplify project planning: The 100 dollar method and prioritization by ranking on a numerical scale.

The 100 Dollar Method

The 100 dollar method is great for prioritizing a manageable requirements pool with multiple or even many stakeholders.

Photo by Alexander Mils on Unsplash

The approach is simple: each stakeholder or voter receives 100 "dollars" or points. Requirements can be "purchased" with this limited budget. The stakeholder himself decides how much the realization of a specific requirement is worth to him. If all dollars or points are spent, the prioritization of the stakeholder is finished. All other stakeholders also go shopping with their dollars and prioritize the requirements that are important to them.

The result is usually a well-spread priority list. The limitation with only 100 dollars/points forces a prioritazion with caution. It is important that stakeholders from all involved departments participate in this prioritization process. The marketing department and IT will certainly bring different perspectives into play. For example, we had a good experience with a project in which more than 5 departments were involved. The distribution of the dollars/points was not made by a representative stakeholder. Instead, this task was assigned to the departments and teams. This triggered an internal discussion and evaluation of the individual topics within the departments, in which everyone could participate. The teams themselves also used the method described above to complete the evaluation and reported the results.

By the way, this method can also be combined well with other prioritization methods. For example, thresholds can be used to illustrate an association with the different categories of the MoSCoW method. Example:

the requirement receives $500 or more in total: "Must"
the requirement will receive between $200 and $500 in total: "Should"
the requirement receives between $50 and $200 in total: "Could"
the requirement receives $50 or less in total: "Won't"

Our experience is that this method is very well suited in situations where you have to work with many stakeholders and detailed discussions would take an immense amount of time due to this high number of people.

It is important that the results are not fixed. There should be space for fine-tuning and follow-up discussions.

Prioritization on a numerical scale

A widely used method for prioritizing requirements is to rank individual topics on a numerical scale from e.g. 1 (not important) to 10 (really important). The higher the number, the more significant this requirement is within the product/project. In the best case, requirements have been recorded in tabular form and the "weight" can be added as a new column. This ensures filterability and sortability.

Photo by Joshua Golde on Unsplash

Even though this type of evaluation is one of the simplest, we often observe that requirements are always very strongly ranked at the lower or upper limit of the scale. Requirements that are in the middle range are found proportionally less often, for the following reasons:

Numbers are abstract. A classification with e.g. "important", "not important" is more concrete.
A scale that is too large leads to uncertainty. The ratings are mostly oriented to the edges and the middle of the scale. There is hardly any rating in between.

A simple way to prevent this is to shorten the numeric scale to e.g. 1 to 5. Our experience is that this makes evaluations easier and eliminates insecurities.

However, this method also carries the risk that requirements are generally classified as very important for the project. It is up to the project managers to judge the final prioritization.

One advantage of assigning numbers is that each stakeholder can do this for themselves. For a final result, the rounded average value of each considered requirement is used.

Again, think about what thresholds should be used to differentiate requirements in the context of the project! Very low-rated requirements should either be excluded immediately or at least formulated as nice-to-have features. Transparent communication with the stakeholders is extremely important here! This avoids uncertainties and disappointments during the project.

Conclusion

Looking at the two prioritization methods introduced, we highly recommend the 100 dollar method. It has been shown that stakeholders make a more accurate judgement of the business value of a requirement with a limited number of "votes". In addition, the method can be adapted and fine-tuned to your own taste.

Evaluation with numbers is particularly effective for a manageable number of requirements and stakeholders. Here, almost nothing has to be explained and the results arrive more quickly.

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-100-dollar-methode-und-skala/

devlix GmbH: quality, consulting, development

Feature image: Photo by Alvaro Reyes on Unsplash

Methodical prioritization with the MoSCoW method

Frank Schillinger — Thu, 25 Feb 2021 06:48:55 +0000

Choosing priorities means deciding what will remain undone.
Helmar Nahr (*1931), german Mathematician & Economist

Whether in a classic or agile project context - those who do not know the focus points and what is important for achieving success are acting blindly. It's extremely important for all project members to get the focus points communicated in a transparent manner. However, the way to achieve this is often difficult. Starting with incomplete knowledge of the core requirements of the planned product and ending with the everything-is-important scenario: how can we resolve these issues and achieve a rational prioritization of the requirements to be realized?

Figure 1: Unsorted pool of requirements that leaves the most important questions unanswered

Especially for large and multidisciplinary projects and products, the inclusion of important stakeholders from every department involved is crucial. We can classify requirements in a workshop or ask each stakeholder to do so individually.

We strongly recommend the collaborative development of this requirements prioritization in form of a workshop. Here we have the chance to ensure and promote communication and transparency between the stakeholders. This is the only way to achieve fundamental acceptance of the requirements from other business units or departments.

Important note: On the way to prioritization, you may often identify new requirements that emerge simply through communication between the project members. Under no circumstances should these requirements be put on top of a pile of "issues to be discussed"! Try to clearly document these new requirements immediately and add them to the pool of topics still to be prioritized. This way you can avoid a potentially very time-consuming reprioritization cycle.

In this and following articles, we want to highlight selected methods for prioritization. The result in each case is a transparently defined project scope or a rough topic prioritization of a product backlog.

By the way: in separate articles we will show you how to create a prioritizable topic pool.

MoSCoW

This method is helpful for a classification by criticality. MoSCoW is an acronym for the words "Must", "Should", "Could" and "Would/Won't/Want". The first letters of these words are combined with two "o". However, these have no meaning and only serve the purpose of forming a pronounceable term.

With the MoSCoW method, we assign requirements to the mentioned categories. This can be done in a wide variety of ways.

If the project is small, this can also be done with sticky notes or a bulletin board. Draw a grid that will allow you to classify the requirements. Write the requirements or higher topics with the desired degree of details on the sticky notes and put them into order after a proper discussion.

Figure 2: Tabular overview of requirements, sorted with the MoSCoW method

In case of an large pool of topics/requirements, you will have documented this information clearly in the best case. Perhaps even in tabular form. In this case you need only one more column, in which you can enter the respective classification. The advantage of a tabular documentation is for example filterabilty and sortability. Use appropriate tools, e.g. the classic Excel, and document clearly and precisely beginning with the first discussions with stakeholders.

Present the results of the prioritization to each stakeholder. This guarantees transparency and avoids "unpleasant surprises" during the project.

Achieve an agreement regarding the ranking of the individual categories! All stakeholders must be aware that a "could" requirement may not be included in the project scope. However, this does not mean that it cannot be made available in a future release!

Must

Requirements in the category "must" are, of course, to be considered absolutely necessary and are essential for the success of the product/project. Here, nice-to-have features are just as wrong as requirements that can easily be moved to a future release. Only requirements that have been classified as absolutely critical to the acceptance of the stakeholders and the targeted user group should be included in this category.

Simplified: What is the use of an online store in which I cannot enter a shipping address? What is the use of an appointment management application that doesn't allow me to manage these events properly? Products without central and essential functions miss their purpose.

Requirements in this category that have not been implemented by the end of the project usually affect the acceptance of the product/project. Under certain circumstances, the project is also considered to have failed - depending on the criticality.

Make sure that no more than 60 percent of the requirements are assigned to this category. Of course, this varies greatly depending on the project and the level of the requirements. Set individual goals so that you can plan the project well.

It should be mentioned again: a requirements pool that consists only of absolutely important topics is usually incomplete or not analyzed well!

Should

"Should" is considered as a category of critical and important requirements. These requirements strongly contribute to the acceptance and success and are definitely worth aiming for. However, they are not show stoppers if not met and do not cause an unavoidable failure of the project. In the simplest case, these requirements can be delivered in a future release.

Simplified example: In addition to the primary payment methods, another payment method needs to be available. Even if it makes sense from a strategic point of view to offer this payment method, it is not vital for completing an order or for the functionality of the online store.

Requirements in this category are very often candidates for a future release. This allows more space for the "Must" category and makes a project more predictable. Make sure that about 20 to 30 percent of the requirements go into this category. Again, of course, this depends on various circumstances and constraints.

Could

Requirements that are not crucial for success are the classic nice-to-have features, which are assigned to the "could" category. However, this does not mean that they are "worthless". If resource planning allows it, these requirements should also be implemented. They often increase acceptance - and for this reason alone, they should not simply be dropped.

Simplified example: When the customer signs in to the online store, he or she can be shown personalized product suggestions. This leads to higher acceptance of the store, but does not affect the basic functionality of the platform if the requirement is not met.

10 to 20 percent of the requirements should be optional requirements. As mentioned above, this depends on many factors.

Won't

Whether "Would", "Won't" or "Want" - the "W" is not clearly defined. However, it is obvious that this category should include all requirements that are excluded in the current project scope. Therefore, we mostly use "Won't" as an explanation. This does not mean that they will not play a significant role in the future! Especially in dynamic markets, priorities can change faster than some product owners or project managers would like.

This category can also be used for a general definition of requirements or features that are not to be implemented in relation to the planned project scope. Often the effort of documentation for this is questioned, since these topics are not being followed up anyway. We would like to point out that this information clearly contributes to transparency and understanding! In the simplest case, you can prove that features have not been forgotten, but have been wisely kept out of the project planning. The information that a feature will not be implemented is just as important as a project plan that shows all functionalities to be implemented!

Simplified: The online store should not offer a language selection "Chinese", as this market is currently irrelevant.

Conclusion

Use the potential of prioritization using the MoSCoW method presented here to be able to outline your project more clearly. A transparent definition of priorities is the foundation for a successful project planning and realization! And it does not matter if you plan it in a classical or agile way.

The next logical step would be to build a product backlog or define a project scope. By classifying the requirements, we have set ourselves some boundaries, so this step should now be much easier.

More information can be found at: https://en.wikipedia.org/wiki/MoSCoW_method

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/methodische-priorisierung-mit-der-moscow-methode/

devlix GmbH: quality, consulting, development

Feature image: Photo by Irina Grotkjaer on Unsplash