Remote Agile teams

The Manifesto for Agile Software Development  states explicitly that “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

As we have seen, the idea is that face-to-face communication is the preferred way because it eliminates misunderstandigs, confusion and overhead.
But now remote or hybrid working is becoming the norm and is for sure here to stay.

Is the agile process compatible with people working remotely or distributed teams?

Working and collaborating remotely is coming with specific challenges but is not incompatible with Agile. The agile process can also thrive in a remote format, provided that the challenges are taken care of.
To perform best under these circumstances, it is very important to acknowledge these challenges.
We need to accept and embrace them and find strategies to reduce their undesired effects or we need to find ways to live with them.

Overall, being agile has never been more important than now: we need to continually learn, inspect and adapt to the situation that emerges.

Here are some best practices for smart working.

Establish team working norms

The first things for remote teams is to establish norms how to interact, how to run virtual meetings and also identify which digital communication platforms are most appropriate for each task.
For example, email may be most suitable for formal but non-urgent requests, while instant messaging may be more appropriate for an informal but quick check-in and phone calls can be used for urgent requests.

Because virtual communication can occur at any hour of the day or night, it’s important to establish guidelines on when to communicate to preserve the boundaries between work and non-work responsibilities.
Employees could create rituals that allow transitions (in the absence of commuting) in order to manage those boundaries. Personally I like to have a dedicated work corner and small setups when I start and end (it’s enough to take out the laptop and connects it to the monitor).

Discussing and agreeing on team norms helps to align on how we want to work together.
It anchors expectations on how we want to behave towards each other when remote.
By this it builds a foundation for trust.
The discussion about these norms is as important as the written rules.
You will probably need to iterate through the rules, processes and tools until you have the right approach.

Team leaders should explicitly articulate and encourage the norms they want the team to adopt, but remember that actions speak louder than their words, especially when it comes to creating a climate of psychological safety.
Critical events, especially early in a team’s life, have an oversized influence on team norms.
For example, a single instance of a team leader criticising, talking over or otherwise dismissing a concern raised by a team member can set a precedent for the whole team, increasing the perceived risks of raising such concerns. It is easy for critical incidents to turn into repeated patterns. Once a norm of “not rocking the boat” becomes entrenched, it takes serious effort to reverse it.

Team leaders should not be the only one responsible for creating a healthy climate, however. All team members can actively shape a team’s norm. After all, teams are social systems in which each member plays a role in sustaining or changing the team’s trajectory. For example, in a team where people have tended not to speak up with anything but the safest suggestion, any team member can start to shift this problematic climate.

Fine tuning the meetings

To maintain the short and efficient meeting processes that agile approaches require, virtual meetings just require some fine tuning to the meeting rules that you should already have (a clear agenda, purpose, topic, etc.):

• Check set-up and attendance: start your meeting with 2, 3 minutes technical start-up.
  Invite people to look at their settings and check if everything works: “Now please check that we can see and hear each other.” Do it until you can do a week without an incident.
• Start with how are we going to work together remote: create a working agreement with behaviour norms.
• Be explicit on the meeting format: brainstorming, discussion, presentation, …
• Balance involvement: invite people not to be observers but participants.
  Make sure, people have understood your view.
• Expect misunderstands and ask for confirmation if you are not sure, like “do I understand you correctly that this is …”. Make sure, people have understood your view.
• Breakout sessions when the team is large.
  Large meetings do not work well usually, even less when virtual. If your planned participant count is more than 7-8 people, consider using break out rooms to engage people in working together
  You start together on the same video call, but during the event, you can create and use separate rooms (many meeting platform allow that) for sub-teams to generate insights or decide what to do.
  Or hold meetings with a small, cross-functional group to accelerate decision-making. Once the smaller group has reached some preliminaries, more people can be brought in.
• Use integrated chat for voting and take decisions.
• Leverage remote meetings tools such as sharing screen and the virtual whiteboard.
• Repeat and summarise: write the summary in the calls chat and open it again the next time.
• Use chat at the end of the meeting to collect feedback.

Finally, let’s talk what could be some examples for typical Agile events hold in a virtual way.

A virtual daily stand-up meeting?

The fulcrum of agile teams is the daily stand-up meeting. Remote work requires new customs for these daily stand-up meetings and a little more orchestration is needed.
For in-person teams, it is customary to have someone present their work and people chime in directly. The effectiveness of this approach depends in part on people’s ability to read social cues and see that somebody else is about to speak. Clearly, that no longer works in virtual meetings.
Web cams help only a little. Tend to over communicate in this case.
If someone disagrees or would like to express something, remind that they should do it explicitly by voicing a statement.

Then there is the problem of people unintentionally talking over one another or waiting to read a virtual room that is not readable. One option is to give each person a dedicated time to speak without interruption and explicitly handing the virtual baton to the next person when is finished.
Finally, daily meeting are stand-up because you want them to be quick; well, that could be stretched for virtual meetings as people usually attend seated from their remote place.
In this case it’s even more important for the Scrum Master to control the timing and avoid people talking too long or the meeting dragging on. Split the meeting into separate break rooms if a discussion around a specific point arises.

How to virtually brainstorm?

Because virtual meeting platforms fail to provide the natural conditions for real-time brainstorming, asking team members to write down thoughts on a shared platform prior to group brainstorming is a useful practice to make. Team members can make comments in a shared document whenever a thought comes to them on their own time.
When the team gathers, members can immediately start evaluating certain ideas or dive into challenges that they need to resolve rather than spend valuable time hashing out ideas in the first place.
Using collaboration tools, this allows the team to constantly iterate without the boundaries of a conventional in-person workshop. Team members don’t need to wait to bring up the subject with colleagues in the office during scheduled meetings or when a colleague doesn’t appear to be busy.
Shared documents can be a particularly useful way to socialize an idea and get a team to make a quick decision on it, letting people engage with the content on their own time. After everyone has had a chance to comment and offer input, the team can be assembled for a virtual meeting to discuss any remaining concerns or comments. Because everyone has had a chance to communicate their thoughts in writing that the rest of the team has seen and that can be saved for future reference, coming to a decision is often much easier.
Personally I like to have wiki-style pages used for internal brainstorming and jotting down ideas. Much more flexible than presentation slides.

A format for a remote Iteration Planning / Retrospective

This is a generic framework, similar to the one used for the Retrospective:

• Check in – introduce everyone and gather expectations
• Set the stage – get everyone on the same page about the purpose of the event
• Generate insights – inspect different elements: increment, backlog, DoD, etc.
• Decide what to do – adapt what have been inspected
• Check-out – Conclude what has been achieved and what are we going to do next
• Inspect and adapt the event – invite people to think what can do better next time for the specific event

Iteration planning

• Start event with a check in, e.g.  ask people to express how did the last iteration planning go.
  Ask how much energy they have now as emoji; or their current mood as cat (show images of grumpy cats, happy cats, etc)
• Set the stage. Invite people to share a word or two on the intention you hold for today’s meeting to be a success.
• Generate insights. Show / collect data on people availability as well as DoD, team velocity and last Retrospective agreed actions. 
  Invite PO to tell /write in the chat what will be the focus/purpose of the Iteration. 
• Decide what to do. Craft the Iteration Goal together. Invite people to individual brainstorm and write one sentence describing the Goal. If bigger team do this in break-out rooms and ask each break-out to select one by voting. Present goal option and decide on one in the main call/chat.
  Now add the Iteration Goal-related items to the Sprint Backlog in your planning / tracking tool. Do it in break-outs or even individually. Present results in main call using the planning tool.
  Create sub-tasks. There should be enough sub-tasks for the first couple of days of the sprint. Create those individually and in break-outs. Present in a main call.
• Check out. Check planned workload and invite people to vote  how realistic it is to do this using a scale of 1-5.
• Inspect and adapt. Ask people to vote in the chat 1-5 if it was achieved the purpose of the event. Invite people that want to comment to do so. Ask to answer how do we run it next time so that can be improved.
  Invite people to check-out with emoji or one two words in the chat – how do you feel now.

Retrospective

• Check in. Ask the team to  draw the emoji that captures their feeling about the most recent iteration on the white board or to type the emoji in chat.
• set the stage. Congratulate team on a job well done with finishing the iteration and invite everyone to go over the stats together.
• Generate insights. Open the Iteration metrics to show the team their progress over the course of two weeks. What do the trends look like? Is it a consistent pattern from other iterations before or did something happen in the most recent one? Invite the team to voice their thoughts and write them into the chat as well. It might be a good idea to have smaller breakouts for 5-10 minutes at this point and come back to the main call after.
• Decide what to do. Ask the team what they believe they could have changed from the most recent iteration. It is important that the coach or Scrum Master raises at least one thing to focus on for change in the upcoming sprint. There could be more behaviors or innovation ideas put forward from this call.  It might be a good idea to have smaller breakouts for 5-10 minutes at this point and come back to the main call after.
• Check out. Ask people to vote in the chat 1-5 (put number) return on time invested.
  Invite people to check-out with three words – What’s my #1 takeaway from today?
• Inspect and adapt. Ask to answer how do we run it next time so that can be improved.

PoS tagging using a Hidden Markov model

Parts-of-Speech Tagging (POS)

In the first part we have seen how to build a simple tagger using the probability that a word belongs to a specific tag.
Part-of-speech refers to the category of words (Noun, Verb, Adjective…) in the language.
The part-of-speech (POS) tagging is the process of assigning a part-of-speech tag to each word in an input text.
Tagging is difficult because some words can represent more than one part of speech at different times. They are ambiguous.

We have seen that a simple tagger based on occurence probabilities reached a good accuracy but failed at correctly tagging a sentence like “I work in Shanghai” because it tagged work as a noun and not – in this case – as a verb.

The goal

We will use now a different approach based on the Viterbi algorithm and the Hidden Markov model, that hopefully will improve the tagging accuracy.

The code and the datasets are available also on my GitHub repository.

Parts-of-Speech (POS) Tagging

Part-of-speech refers to the category of words (Noun, Verb, Adjective…) in the language.
The part-of-speech (POS) tagging is the process of assigning a part-of-speech tag to each word in an input text. Tagging is difficult because some words can represent more than one part of speech at different times. They are Ambiguous. Let’s look at the following example:

• The whole team played well. [adverb]
• You are doing well for yourself. [adjective]
• Well, this assignment took me forever to complete. [interjection]
• The well is dry. [noun]
• Tears were beginning to well in her eyes. [verb]

POS are useful because you can use them to make assumptions about semantics. This would be critically important in search queries. Identifying the proper noun, the organization, the stock symbol, or anything similar would greatly improve everything ranging from speech recognition to search. They’re used for identifying named entities too.

Here is an example ‘tag-set’ or Part of Speech designation describing the two or three letter tag and their meaning.

The goal

A simple tagger can be built using the probability that a word belongs to a specific tag.
To find out the probabilities we can use an existing dataset of sentences (articles from the WSJ) whose words have been properly tagged. Unambiguous words will have a probability near 100% of belonging to a tag, while for ambiguous words, it depends on how often they are used according to each tag.

Saving and loading models in Tensorflow

Saving models

We look now at one very useful feature in Tensorflow: saving and loading a model.
We will use as an example a subset of CIFAR, an image dataset whose images can be classified with a description label.

As usual, the code is also on my GitHub notebook.

import tensorflow as tf
print(tf.__version__)

2.0.0

Load and inspect CIFAR-10 dataset

The CIFAR-10 dataset consists of 60K color images, each with one of 10 labels: airplane, automobile, bird, cat, deer, dog, frog, horse, ship, truck.
The dataset is availbale inside Tensorflow and you can see an introduction and download it, on the Toronto University web site.

Innovation and Planning Iteration

The Innovation and Planning (IP from now) is a special iteration planned at the end of a Program Increment and is a critical phase to improve the process before the next Program Increment (PI).

It is a concept originated from SAFe but is generally valid and can be applied to most Agile scaled frameworks.
It serves two main purposes:

• Innovation: reserve dedicated time and opportunity for innovation spikes, hackathons or infrastructure improvements 

• Planning: reserve a buffer for meeting the PI Objectives and providing an estimating guard band for cadence- based delivery and enhancing the predictability of PI performance. 

Innovation and planning iterations provide a regular, cadence-based opportunity – every Program Increment (PI) – for teams to work on activities (plans, demo, improving together) that are difficult to fit into a continuous, incremental value delivery pattern, always under the tyranny of urgency.

Without the IP Iteration there is a risk of little innovation and the technical debt growing uncontrollably but also of having people burning out.

Let’s say the iterations are two weeks long, then an IP iteration (also two-weeks long) could look like this:

• the first week can be dedicated to:
  • a buffer for leftover work (if you need more time than you did something wrong in the PI Planning), 
  • the final verification, validation and integration, 
  • innovation (spikes, hackatons, studies, …), 
  • prepare the next PI planning (PI readiness)
• the second week can be more structured with
  • the Inspect & Adapt workshop and
  • the PI planning

Let’s see the main parts.

Reviews and Retro in Scaled Agile

After having seen the Plan and Do parts, now we concentrate on the the Check & Adjust parts which is central in Agile practices.

PDCA learning cycle

The Iteration Review 

The review happens at the end of each Iteration (each team organises its own) and provides the true measure of progress by showing a working and tested team’s increment; the increment being one or more software or other components functionalities.