Categories
Agile

Agile Speakers meets for lunch

Lana, Daniel, Stefan and I kicked off Agile Speakers in 2024 at the Schlosswirtschaft Schwaige. The last session of Agile Speakers met for breakfast and we discussed Kural and Testing: Breakfast & Speak – Moss and Lichens. And the time before that we met for Wine & Speak and had Ineke, Mikaela and Vera present a wine and talk about different things Agile: How to fail like a Scrum Master? – Moss and Lichens

Stefan started off sharing ideas from his newsletter.

I liked his premise of using medical terms to explain and diagnose things in the testing world. The discussion around Incident (or Issue) to Defect and journey which takes us there. Is finding and fixing a bug enough? Should we be looking into why the bug happened in the first place? Is there a connection between the nature of the defects and and the nature of the product or service itself?

I liked the way Daniel noticed the Medical Metaphors!

For a more detailed reading of Stefan’s ideas you can read further here: Activity | Stefan Dirnstorfer | LinkedIn

I shared my learnings from the course on Resilience from the London Business School. We had representation from three different domains – Testing, Medical and Online marketplace and it was interesting to see how they reacted with stories from the Strategic, Operational and Behavioral resilience areas.

We talked about how Accenture had identified the trend towards successful outsourcing and how in the Testing domain AI supported test case automation is available. Will products and services survive if they do not keep an eye of the trends?

We talked about how Netflix had anticipated the disruption in online streaming and how in the Online marketplace domain Quoka did verticalisation (vertical specialisation) on pet products.

We talked about how the Covid vaccine was created by companies which had the right conditions for a strategic response based on years of research beforehand.

We talked about how chip manufacturers like Intel at some points need to take care of not just direct risks but also keep an eye on multi-chain risks.

Tech Stack Diagnosis and Resilience kept us busy for 2 hours in this Agile Speakers meetup! What will we discuss next time?

You can join us in the future here: Agile Speakers @ Moss and Lichens | Groups | LinkedIn

Categories
Collaboration

Knowledge base and transfer

Photo by Scott Graham on Unsplash

Knowledge bases are important for teams. They help teams to document the history, current state and planned future of software products and services.

Ideally knowledge bases are maintained in collaboration platforms (eg: SharePoint, Confluence). They are ideally online, searchable and well maintained.

Very often knowledge bases are outdated and not kept uptodate. This is because teams rarely have documentation in their checklist (Scrum: Definition of Done) before marking a task as Done.

This results in a technical debt that is coming back to catch you when you really need it. For example, when a team member leaves, a knowledge transfer needs to happen.

  1. The knowledge transfer would be easy if a knowledge base existed and is constantly kept uptodate.
  2. The knowledge transfer would be easy if every task follows the two person rule (or four eyes principle).
  3. Every active product or service has a technical documentation with setup, configuration, changes and support
  4. Every active product or service has a user manual with usage scenarios and expectations

Now let us see how we can make the above things part of our daily routine.

Step 1:

Every task completed by the team is considered DONE only when two things are satisfied

  1. There is documentation for the product or service feature
  2. There is second person who read and approved of the documentation

Step 2:

Every product or service which goes to Production is considered DONE only when two things are satisfied

  1. There is technical documentation for developers on the team to support and extend it
  2. There is a user (friendly) manual for customers to be able to use the product or service

Even when the above two steps are complete when a person leaves a team a handover needs to be done. Here is a sample list of some of the items we check for handovers.

Handover checklist:

  • Project name
  • Project status (active, inactive)
  • People
  • Priority
  • Handover to (person)
  • Handover activities
  • Due date
  • Status (not started, in progress, completed)
  • Documentation links
  • Notes

Using the handover checklist a team can do a kickoff for the handover where all the projects that need a handover are identified. The important parts are being able to identify the People and the Handover to person.

If a project has only one person on the People, it is already a sign that the handover will be difficult. However with enough planning this can be remedied.

In the kickoff the Handover activities need not be detailed. This can be done between the person doing the handover and the person receiving the handover.

Depending on the priority and the time available the due dates may be timeboxed and a knowledge transfer may be done.

You have a Handover to be done?

With the knowledge base, two person rule, technical documentation and user manual you are ready to handle it with ease.