Health is more than you think

When it comes to the health topic, the majority has physical health in mind. Biased by the daily business, in organisation the health topic is reduced to available meaning healthy, not-available meaning sick. This simple view is tricky because it only reflects the current state and with this the current personal costs. In times, where costs of employees are a key factor to success, I like to use the term human asset over human resources.

The WHO constitution states: "Health is a state of complete physical, mental and social well-being and not merely the absence of disease or infirmity." An important implication of this definition is that mental health is more than just the absence of mental disorders or disabilities.

Additionally, the WHO enriches the mental health definition with

• Mental health is more than the absence of mental disorders.
• Mental health is an integral part of health; indeed, there is no health without mental health.
• Mental health is determined by a range of socioeconomic, biological and environmental factors.

 What does that mean now regarding staying healthy and care about human assets?

Taking the picture from above, all three categories interact with each other. Imagine you have a broken leg and cannot prepare for your run and you cannot meet your friends. In that case physical sickness effects on your mental sickness as you might get sad to miss the running event and you miss interaction with your friends.

If you loose a family member, this probably effects on your mental and also on your physical heath.

If you are extremely stressed in the company, you probably get physical sick and/or you start isolating yourself at home as you want to regenerate.

There are plenty of examples showing these interactions. As individual, a key take away is, if there is a physical issue, think larger for the solution. The core issue might be on the social or the mental part.

As organisation, also think larger to prevent sick leaves as these costs money, either directly or indirectly through lower throughput and release delays and react on global changes. A very good example is here Home Office. While it burst all level of Health by less traffic stress and more time with the family, it reduces social interaction within the company and reduced communication leads to missing know how. Mental health, but also social health, is an important topic for leadership. Good leadership reduces the risk of mental sick leaves and this reduces risks and costs. The key is to actively prevent or mitigate  over just reacting on health issues.

Physical health can be supported my medical offers, (team) sport activities and adjustable tables.

Social health can be supported by face to face events and bringing employees together, starting from a coffee kitchen to team sport events.

Mutation Testing

 Out of a good discussion within the team about testing, in special about mutation testing, I want to share a good insight from Uncle Bob about that topic

https://blog.cleancoder.com/uncle-bob/2016/06/10/MutationTesting.html

Do not let your tester be the bottleneck!

 

You might know the situation, when it is a stressful time with a lot of features to implement and developer focus on coding while the tester takes the tickets after coding and tests the ticket. This is a classic waterfall approach.

In software development time to deliver got a high focus through Agile and the previous role concept of tester has changed. This article shows the advantages of spreading testing tasks and explores strategies to ensure that the tester in your team does not become the bottleneck in your process.

Spreading the testing responsibility across the team can bring you several advantages:

• Faster feedback: With more team members who are involved in testing, other developers get feedback earlier. The higher your ratio of devs to testers is, the higher is the value of this feedback loop
• Reduce risk: Even if the tester is highly skilled, other persons have different approaches to test something. By having different perspectives on the product, risks of bugs can reduce
• Balanced workload: In Scrum, when a number of developer starts at the beginning of the sprint with coding and get finished close togehter with their first task, you have then a high peak of workload for your tester, while devs "wait" for feedback. The longer your release cycles are the more imbalanced are the workloads. Shifting reduce the health risks for your tester. As a leader, beware that developer get the work additionally to their coding tasks. Even if there is a big benefit in this balancing, it needs a lot of leader support to avoid misunderstandings.
• Skill development: When developer are coding their tickets, the have a hard focus on the code view of the product. Having developer who avoid testing and working on requirements, I would rename them to coders instead of developer. Developer crafting solutions. To craft solutions, you should know the customers perspective and you perfectly get this by using the product during tests.

What are the strategies to shift 

• Shift-Left Testing: Integrate testing early in the development cycle. By involving testers from the beginning, potential issues can be identified and addressed sooner, reducing the load during the final stages.
• Automated Testing: Implement automated testing tools to handle repetitive and time-consuming tasks. This allows testers to focus on more complex and critical testing activities.
• Cross-Functional Teams: Encourage developers to take on some testing responsibilities. This not only distributes the workload more evenly but also fosters a culture of quality across the team.
• Test-Driven Development: Encourage developers to write tests before coding. This practice ensures that testing is an integral part of the development process and helps catch issues early.
• Regular Training: Provide ongoing training for testers to keep them updated with the latest testing tools and methodologies. Skilled testers can work more efficiently and effectively.

Do I need then a pure tester at all when developer are testing?

I put this questions here as in the past 20 years, I often heard that. Of course it is possible to remove the role from the list of available roles in the company and shift the tasks of this role completely to the developers. But beware of just cutting of the quality guy as there is no need anymore. Developers need of course also time to test and probably will do the tests less efficient as a pure tester. 

The probably better questions are

• Do I need somebody who has a focus on the quality through the whole development process
• Who checks non-functional requirements
• Do I want to have a person with a focus on specific tests like load tests

Getting more clarity of tasks helps to find your team setup.

Story Mapping: A Powerful Tool for (Agile) Product Development

 

Jira is a trap. When a less experienced real product owner is working with Jira, there is a high chance that the PO is creating an epic, out of the epic some storys or requirements and starts the discussion about that. At this time, you already lost as product owner the momentum of the power of a story map.

What is Story Mapping?

Story mapping, created by agile pioneer Jeff Patton (see https://jpattonassociates.com/story-mapping/), is a visual exercise to help product teams understand the customer’s journey and define what the product needs to do. It's a method that organizes and prioritizes user stories by mapping them along two dimensions: activities over time (typically from top to bottom) and goals/features from high-priority to low-priority (left to right).

This approach not only clarifies how each part of the product contributes to the overall experience but also helps teams identify gaps, prioritize the backlog, and deliver in stages.

Benefits of Story Mapping

1. User-Centric Focus: Ensures features align with real user needs.
2. Effective Prioritization: Helps focus on what's most important.
3. Team Alignment: Brings teams together to build a shared understanding.
4. Roadmap Planning: Clearly defines what goes in each release, helping to avoid scope creep.

How to Create a Story Map

Bring in specialists which have a connection to the story map. 

1. Identify the User’s Journey

Start by defining high-level user goals or activities (in a webshop this could be “make a purchase”). Place these activities in sequence, representing the stages a user goes through when interacting with the product.

2. Break Down Activities into Tasks

For each high-level goal, break it down into specific tasks or steps that the user needs to accomplish. This breakdown will highlight what the product must enable the user to do, giving your team a detailed view of required functionality.

3. Organize Tasks by Priority

Sort tasks vertically by priority. The most critical tasks go to the top, defining the Minimum Viable Product (MVP). Subsequent rows represent less essential features or those that can be added later.

4. Define Releases or Sprints

Story mapping also help organize releases. Group tasks horizontally into what will be included in the next release or sprint, ensuring that each release delivers value by enabling a full user journey through one or more stages of the map.

5. Regularly Review and Update the Map

Story maps are dynamic tools. As the team learns more about the user’s needs, the map should evolve. This flexibility allows teams to pivot based on user feedback without losing sight of the big picture.

It is really a powerful tool to focus on the user perspective and creates more understanding for delivering value to a customer. Using personas can make the user story mapping even better.

Satisfaction in a change process

Have you ever been angry or at least annoyed about something at home today? In the morning? In traffic? At work or school? How many times have you heard or read about war news this week? Is the end near and everything was better before?

Really?

It's simply time to say thank you.

Thank you that I have great people.

Thank you for a wonderful family.

Thank you that I can live in a beautiful region.

Thank you that I have something to eat and drink every day and a home.

Photographers know it - sometimes it's necessary to take a step back to get a better overview. It's similar in life. Gaining an overview requires breaking out of the hammock and sometimes asking for opposing opinions, listening and asking yourself whether you are actually right, whether the information you are consuming is correct or whether you are trapped in a bubble.

After a long period of stability and security, you start to be cosy in your comfort zone. Every change appears to be an intervention or even an attack.

The same behaviour can be observed in an agile transformation in a company. Processes that have been lived for years or decades require much more energy, even if the process is of little value in a modern environment. Change is associated with fear and this is an essential aspect to consider as an agile coach. The bigger a change is and therefore the more people are affected, the more likely it is that there will be dissatisfied people. - That's ok. Building consensus with 100 people, for example, leads to sluggish change behaviour. Here, the departmental or company management is required to demand responsibility from the employees, but to bear the accountability themselves. If you hand over both to those involved in the change process even though you have made the decision yourself, there is a high chance that the change will fail.

Another important aspect is to clearly define and communicate the goal. Is it okay that old schemes no longer work in the new process. The question is, how do you deal with this? Does it require employees to adapt? Uncertainties such as these must be addressed. In this way, momentum can be used to increase motivation. Use this momentum which you can get by changes to level up the company over staying at the same motivation and satisfaction level.