How Do you Eat a Mastodon?

… one piece of the time. Really. Don’t worry about it – it’s similar to eating an elephant.

While Discord and Slack sites can be places to go for communities with the faill of Twitter – they are closed systems. You need an invite and communication closed within the instance. This is good for closed discussions you want to gatekeep. Mastodon seems to be the place for serendipity and cross-collaboration across topics and communities. It’s not new, the framework started in 2016 gaining 1 million users in 2017. There are a number of great and extensive guides – one of them is fedi.tips. Another great guide is Mastodon Lessons Learned by Lisi Hocke (@lisihocke@mastodon.social).

Hi I’m Jesper🧷🌻🐐📕🗺🇩🇰 (@Jo2sn@mastodon.social)

Signup and Servers

For Mastodon, you create accounts on a server (or instance) in the Mastodon-based network. Through a shared protocol the people on the servers can communicate with posts, threads, likes, and resharing as known from other platforms. Mastodon is really the software framework (on GitHub) and the network called “Fediverse” – but people mostly call it “on Mastodon”.

Someone wrote that picking a Mastodon Server feels like selecting a character in a new video game. You don’t really know what you’re looking into and how you will play the game. Luckily you are not fixed to one account on the Mastodon network. You can have multiple and easily redirect from the old to the newer. I have tried jumping profiles myself, as the first one I made was on a server with too few general topics. One of the elements of Mastodon is that each server has a timeline – besides the ability to communicate across.  

Some servers are topic-based on Open-source software, others on art and LGBT, you can pick a specific server and expect the local content mostly on that topic. Or you can pick a general-purpose server – if one topic doesn’t define you. There are some tools, like debirdify that can help you in the process – but not yet a 1-click tool to move over. 

Two ways to select a server:

People can and will move to many places – there is yet to be a primary test community instance. 

Profile and Settings

  • Your username is text-based, but you can go crazy with emojis in the profile name field
  • Create your profile with a picture, banner, and profile text
  • Profile meta-data and hashtags will help people find you and recognize you
  • Add 2-factor authentication and save the password and keys
  • If English is not your native language, there are other languages available (German is rather prominent). Selecting a language seems to give you more content in that language.
  • Enabling the “slow mode” setting is recommended. It forces you manually to reload the feeds and not have the dreaded firehose. 
  • Make an #introduction post and write your favorite hashtags, that will help people find you.
  • Write your Mastodon username @user@server.name in your Twitter bio so that others can follow you

General Use

As there is no algorithm to drive engagement, so use hashtags and reshare content from others. Likes are only posted to the author – so reshare/retoot great posts. Similarly to following people you can follow hashtags like #MinistryOfTesting and #TwitterTestingPeople. The culture of Mastodon is to be inclusive. Use Content-Warnings and hide images as a common rule – and ALT-text on images as a general rule. 

Mastodon has free apps (Android, iOS) for casual use and some pay-to-use apps. Currently, it seems you can’t follow hashtags in the iOS app, so I tend to use the browser more. There is a range of choices – see what bests fit you. You can get a long way with just the primary site.

Servers are run by small teams of admins, so in peak periods there might be suboptimal performance. Most servers seem to be funded by patreons or similar fundraising. 

In theory, an instance could close down and take everything away. If you have content that is more permanent and you want to own, put it somewhere you control. The same challenge is true for ad-based social media (Facebook) and subscription-based platforms like Medium. 

If you feel like organizing the content coming your way, enabling the advanced web GUI setting will give you columns like “TweetDeck” – but the setting is global for your login. Sometimes I just want a quick read over the timelines, other times I want to monitor specific topics. To monitor topics I have set up columns in Sengi https://sengi.nicolas-constant.com/. It’s a per-browser setting, so it’s more of a topic radar that can be different across my devices. Personal lists are a feature too, but it seems based on people not so much on topics. 

Do notice that direct messages aren’t private messages. All the people you tag can read the messages. So don’t tag the people you want to rant about. 

The visibility of a toot/post follows the flowchart below. 

Via @geekyMary@Mastodon.social: https://mastodon.social/@Geekymary/109290888512800541

Taking My Own Medicine

Recently I had the chance to apply my own templates to myself and my active project – as I had to mentor a new test manager. I was challenged in explaining how I read the upcoming IT environment project. After looking into resources for new test leads, I realized I could take my own medicine.

Photo by PhotoMIX Company on Pexels.com
Photo by PhotoMIX Company on Pexels.com

A year ago, I created a new test plan format – the Situational Aware Test Plan. While mind-maps and one-page test plan canvases exist, I wanted to elaborate using the evolution principles from Wardley mapping and stop writing test plan documents.

The table structure is there to provide guard rails for the elaboration. I will use the Darlings, Pets, Cattle, and GUID -mnemonic as headlines. Our strategic decisions emerge as we use the worksheet based on the current situation and state. The strategies will be the decisions to push a field in the grid to another state. 

Delivery and Situation

DarlingsPetsCattleGUID’s
New projectFixed date
Existing delivery speedScheduled
Quarterly
Test Environments, internalRepeatable
Test environments with integrationsCraftedSome existing know-how
Environment InfrastructureHosted data center practices
Test dataKnown but cumbersome

While this project introduces new test environments, there is an existing environment with a quarterly delivery pace. This is a classic example of the core chronic conflict of pursuing both: responding to the rapidly changing competitive landscape and providing stable, reliable, and secure services (DevOps handbook introduction xxv) as elaborated on Align your Test Strategy to your Business Strategy.

The test team allocated beside me and the new test lead is a new junior and senior tester. We are in the same team, and most are even in the same office. So collaboration will be collaborative and pervasive, with a focus on helping the new people grow.

The test team

DarlingsPetsCattleGUID’s
Test team collaborationGrowingPervasive
Test leadGrowing
MentoringEnabling
Domain know-howGetting there

Test tools and approach

DarlingsPetsCattleGUID’s
Test activityExplore integrationsConfirm internal requirements
Test casesExisting can be updated.
Test case reproCreate new repository

As mentioned in the blog post about visualization, we can now use the map to discuss why we need CT and ET for the project. Based on the project’s layout, I would advise having an expert exploration of the integrations and more standard scripts for the known construction of the internal environments.

Why Do We Fall, Master Bruce?

… So that we can learn to pick ourselves up, Alfred! I was recently reminded of this quote from watching the “Batman Begins” movie with my 16yo. I really needed that reminder. Then I read the two blog posts by Beren on “Those who Failed” and “Versus the Endboss“. Let’s put it out there that we fall – and fail to remember that we fall.

I had been part of a large project – but had read the culture all wrong and we had failed hard. For a number of reasons and maybe mostly for systemic reasons. The team expected one mindset and one way of tooling – we provided another one. Even with all my best intentions and know-how of change management, this crashed. As Hannes elegantly put it, we had cycled too far ahead of the team:

  • The team expected minutes of meetings and agendas, we worked for making things visible and shared
  • The team expected testing to be checking the requirements, we worked for testing to support critical decision making
  • The team worked political with back channels, we worked open and power-lifting
  • The team participants had agendas that didn’t align with the project’s purpose
  • The team expected all things equally important, we worked by priority and deadline
  • The team expected detailed test cases to be approved at all steps, we provided intentions and purpose
  • The team expected detailed handovers, we worked entrepreneurially to set things in motion
  • The team expected an error-free lead, we worked knowing I wouldn’t remember everything

At one point I was arguing that the team needed to read Hofstede’s cultural dimensions theory – to read up on the different cultures we would be interacting with (our customers). In retrospect, we should have used it on ourselves first of all.

Hofstede’s cultural dimensions theory

It’s a little more detailed than Westrum – and even Westrum might have helped. That is if we had been able to articulate the conflict well in advance. Perhaps a senior hire should have spotted the signals beforehand. As an outsider, I relied on people telling me things. I couldn’t hear or see the back-channel communications. This is a struggle for many staff people when switching roles:

Initially, no one from the operations organization and latest implementation opted for the leading the activity. As we had no playbook or project plan (only the produced artifacts) – I made a scrum-board-inspired work tracking system. Perhaps I should have used a Wardley map first of all as recommended by John Cutler in “TBM 18/52: We Need Someone Who Has Done “It” Before

What is Wardley Mapping doing for us here? It is letting us explore a more nuanced view of the problem space. Instead of treating things as one problem, we break the problem apart into a bunch of capabilities. When we do this exercise we typically find:

Not everything is an existing playbook. Not everything is a new playbook.

To solve new problems, we need a foundation of stable playbooks. For example, to solve that crazy new problem, the team might need a foundation of trustworthy data.

Yes, you can break things apart to see them better. But you’re also dealing with the whole thing.

But then again the team would probably have stalled over the very concept of a strategy map. People are weird. No matter how it looks at first, it’s always a people problem. And even if you do try to take the first steps – your steps could be in the wrong direction. Even Master Bruce will fall in that situation.

The Mechanics of Modern Meetings

In these days of virtual meetings, the very structures of formal meetings are under change. It’s definitely forged by extensive work-from-home and working with people not in the same locations. It challenges the people that are used to having everything in documents and actions/assignments tracked as part of a “Minutes of Meetings” document. They seem to mistake the absence of document artifacts with no structure. But if you look closer you will see that even a circus is a choreographed act.

The Agenda is always the Current State of Affairs

A key observation from the agile and collaborative way of working is the principle of making work visible. Put tasks and assignments on a shared board for the team. The tool is not so important, as long as it reasonably supports the kanban/scrum-board mechanics. You can use Trello, Podio, Miro, Azure DevOps, or Jira – whatever is available to you in your organization.

Among the benefits of a shared digital board is that it additionally supports the team with the ability to work on items asynchronously, independent of timezones, working hours, and locations. The state of affairs is whatever state the board depicts – so make sure it’s always as truthful as it can be. It takes practice for the team members to learn to update the board outside of the meeting. But this small step is really key in making the meetings more effective and reducing the time to information.

The status board challenges the fact that an agenda can be locked prior to a meeting. All items are moving pieces – so the agenda can only be “look at the board“. If someone is working on something – put it on the board. This also helps if a team member runs off to join a circus – or is temporarily away from this very circus.

Boards help to streamline getting things done. Items might not be perfect – but the focus is on getting them done. “Stop starting – Start stopping” is a recurring mantra. Secondly using a board and agile backlogs and work limits help to prioritize the work according to the team’s availability and speed of delivery. Bottlenecks and overloaded staff can be more easily identified.

Recurring touchpoints, though, are still needed for the team, but the latest status of the work items is no longer at the end of a Minutes of Meetings document.

Recorded Minutes of Meetings

Originally, the MoM (Minutes of Meetings) documents hold the decision items and action items after every meeting. As discussed a shared task board can replace much of the MoM. Is Alice joining Bob on a task? Did Charles agree to deliver X by Friday? All of those actions can be activities on the task board, as long as it’s added during the meeting. A meeting notetaker could do this during the meeting on the board, and not focus on writing down every minute. Adding ideas to the board’s “to-do” column is also a powerful way to remember things for the future.

A strong trend I see in the use of virtual meeting platforms is a default recording of most meetings. You have to get used to it, also privacy vise. Be careful in political organizations – the spoken word is now recorded. Among the benefits of recorded meetings is that everyone can rewind into the meetings and that previous meeting content is available for new team members. This goes especially well for content that is more “show and tell” than status calls.

My preferred leadership style is to set direction, provide what I have of relevant information, and follow up indirectly via the board. I don’t need to meet for a status message that can be read from the board. But I will use the information on the board to reflect on where we are and where we’re supposed to be heading.

Reframe meetings as Collaborative Conversations

When I set up a meeting in someone’s calendar, it’s not always with the intention to have the formal mechanics of a Capital-M Meeting. The scheduling in the calendar is a way to respect people’s time and to make sure key participants can be available at the same time. It’s out of the same respect for people’s variety of availability that meetings need to be effective.

I rarely invoke the formalities of a Meeting. When we (small-m) meet it’s to collaborate and interact and discover serendipity. Sometimes it seems that the name “meeting” is taken literally as a formal structure, while to me it’s more like a placeholder for collaborative conversations.

It may look like a circus – but that is on purpose. There is a choreography behind it all.

The Circus by Alex Herreru00edas is licensed under CC-BY-NC-ND 4.0

#267 – Reminder – it’s about Story Shaping

In agile delivery teams, it’s recommended that stories and features are discussed before being developed. A checklist called “Definition of Done” can be used as a reminder to check that the delivery team has everything needed to prepare the delivery of the feature. A key ingredient is a shared understanding of how to confirm the delivery – for the whole team.

Story shaping requires at least three people to get together. They are not amigos nor amigas. They are often three, sometimes two people, and often more. They represent the different viewpoints needed to deliver: builders mindset, testing mindset, security mindset, operations mindset, business mindset, etc.

No one person can hold all these viewpoints – at least a builders mindset and a requester/business mindset is needed.

If you skip doing story shaping your acceptance criteria and testing activities will be misaligned. And you will either have overdone the effort needed or underestimated the challenges of the story.

Thank you to all who have replied to the tweet below.

One customer, three people to do the story shaping

Stop Writing Overdone Test Plans

While I have previously talked about writing down expectations and alignments – I would much prefer a more lean and up-to-date approach to test plan documents. Looking at what we know now, an separate test is more of a sign of missing trust between parties than a collaborative value add for the business needs.

Continue reading

You Cannot Be Everywhere

A key lesson with the whole situation is, that there is no Nirvana, no steady state nor closure to everything. The only constant is that life is ever changing. Coming up around the corner is a new change – some can be planned for and others not so much. Imagining that things can be different is the first step to dealing with change (Thank you, Virginia Satir).

There will always be more things needing attention. Sometimes it’s based on the fear of missing out (FOMO) and the urge to be involved in everything. You will very easily find yourself stretched too thin – and needing a way to scale the effort, both professionally and personally. Clocking more hours will only work in the short run. Remember, it’s ok not to scale – sometimes it’s actually the best solution.

Continue reading

Darlings, Pets, Cattle and GUID’s

Kill your darlings and treat your tests more like cattle than pets, are among some of the heuristics currently around for managing your environments and automation test suites. These heuristics tells me that the environments and automation are in a state of product or even commodity, while previously the tests and environments where like darlings and pets – named and nurtured.

Continue reading

Where Does Testers Fit In?

We often discuss where the “testing people” fit into the organisation – are they part of a delivery team or an enablement team independently of the delivery teams? The Team Topologies model enables a discussion about this challenge and a guidance on what goes where and why.

I can see the benefits of having a central Test Center of all the testing people – and, on the other hand, having them spread out in the delivery units. I work in an IT services company, sometimes a project does not require full-time test attention. So we work on a range of customers, at the same time. On the other hand, sometimes projects lasts for years and years – and the testing people become dedicated towards a specific company IT stack and delivery team.

Notice that I use the term “testing people” to cover testing specialists, test analysts, automation specialists, test engineers and test managers like myself. Besides the moniker “testers” in the blog title, I try to avoid calling us “testers”. First of all, “testing people” do more than testing and secondly other people do testing too.

The Test Center I’m in is an organisational unit of “test consultants” of various of the mentioned roles working for various of projects. But considering the “whole team approach to quality“, the Test Center unit sounds a bit .. off. Would it be better to assign everyone to a delivery unit? – What would be the reasoning behind what goes where where and why?

I have found the Team Topologies model, which identifies these teams:

  • Stream-aligned team: aligned to a flow of work from (usually) a segment of the business domain [yellow]
  • Enabling team: helps a Stream-aligned team to overcome obstacles. Also detects missing capabilities [cyan]
  • Complicated Subsystem team: where significant mathematics/calculation/technical expertise is needed [red]
  • Platform team: a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams [purple]
The 3 interaction modes of the Team Topologies model

The model identifies three modes of interaction during the flow of change:

  • Collaboration: working together for a defined period of time to discover new things (APIs, practices, technologies, etc.)
  • X-as-a-Service: one team provides and one team consumes something “as a Service”
  • Facilitation: one team helps and mentors another team

Based on this model the dedicated testing staff should be part of the stream-aligned delivery unit. While everyone working ideally to enable the team – testing coaches etc – should be part of an enablement team, aka. a center/unit/group/staff team for enablement (Accelerate the Achievement of Shippable Quality). I read into it, that the enablement team’s primary focus would be to build self-reliance in the team and get out of dodge. A key principle in Modern Testing.

How “testing people” could fit into the other two teams (Subsystem & Platform), I would have to consider a bit more. The testing activity is in both, and the Enablement team also facilitate (testing) into those two team modes/units. So perhaps it’s not that different. What do you think?

The findings of the model also aligns with the “Product Team” and “Competence Team” of this article (in Danish): Hvilke karakteristika og udfordringer har dit team?

Reality, though, is a bit more complex. Even the Team Topology Model – is just a model, and wrong a some point. It is though still useful in enabling a discussion on where the testing people fit it, and why.