Pages

Monday, October 26, 2020

Agile basics and working remote

The research version of our Capgemini post ‘Out-of-office-agile - Agile basics in a remote world

Working from home is becoming more and more common nowadays. People increasingly want to work from home. This change has been boosted by the Covid-19 pandemic. Due to the consequences of the pandemic, we were forced to work from home. Mankind ran quickly into solutions to keep the work going but took little time to inspect and adapt. As this situation was expected to be temporary, people didn’t feel the urge, did it superficially or focused only on the obvious. Still the situation and its urgency, might have caused overlooking the basics of working agile and its underlying principles.

As it now turns out not be a temporary thing, we need to have a deeper dive into what’s needed to improve working remote or even from home. In this article we will reflect on remote working using the agile practice of Inspect and Adapt.

The inspection results are based on our own experiences on projects and signals we get from our fellow Agile coaches. To deepen our inspection we choose to use the Agile Manifesto and the Scrum guide.

Inspect

Let’s start with an inspect first. In the inspection we have taken the basics of the Agile Manifesto and Scrum as leading source to reflect to.

The Agile Manifesto has been the foundation for all agile ways of working we know now and will likely will remain to be for future agile methods or processes. That’s why we used the Manifesto and the underlying agile principles as a source for our inspection. Because we see that Scrum is kind of the starting standard, we also took the pillars and values of Scrum into account.

We have done the assessment on the possible risks, by evaluating these agile basics one by one as a viewpoint to identify risks. As the next step we grouped them into potential common grounds. The ‘brown paper’ inspection results are in the appendix. The communality is presented in this chapter in four common grounds.

Not being together

Well, this is of course the obvious one. Because of working from home, the interactions between people can be hampered and we become more reliant on tools. We run the risk of not picking up conversations between two other people in the room where we might have a valuable contribution. Natural discussions aren’t popping up the way we want it. And we even miss out on possible improvements that can be made to the product we are working on.

The tools used can be broken or people have the fear of using them and by that don’t give (all) the input they could give and are less open.

But there is also the risk, like we see on social media, that people are less restrained in their outings and by that cross the line of respectful interaction with others.

Plan and control from outside the team

Many agile projects still live in an environment in transition from a plan and control culture to an Agile culture. Because of the remote way of working the team’s result become less visible, the management gets less information.

Organizations might fall back on the traditional plan and control to track progress. And even fall back to contract negotiations. But also, because the team dynamics might be disturbed, the team itself loses it trust in being self-organizing and falls back into asking the manager what to do.

Focus issues

We see people either losing their focus when working from home or going in hyper focus. Losing focus because of missing the stimulus from colleagues keeping a person sharp or disturbances in the working from home situation. Hyper focus because of the lack of healthy disturbances. Both disturb a sustainable process flow.

Skip inspect and adapt

The last major thing which might happen is that teams are skipping the inspect and adapt cycles. Reviews are not happening because the tools don’t work, or people have a fear to use them. Or even worse, they use it as an excuse not to attend.
But even when the official inspect and adapt moments are planned, people are just going through the motions and are not really focused and committed to the event. Being unable to look each other in the eyes, we get limited information and we miss the signs triggering to ask a deepening question. This causes the real reasons and possible solutions for problems not to surface.

Adapt

During our inspection we have identified four possible common grounds of problems arising with remote working. We now can take measures to reduce their impact or even prevent them to happen.

Not being together

Because this is the most obvious root cause, most teams have taken already some action. Like using live meeting tools for at least the standard ceremonies. Still, inside and outside these ceremonies a team can take measures to come as close as possible to being together. Examples of these measures are:

  • Setting up one single team chat channel, where every team member is taking part. And to use this channel to start a discussion, even if the question is directed to one special person. So, everybody can jump in, if he feels the urge. It might even be good to jump in when one doesn’t feel the urge as you might hear interesting discussions.
  • As a discussion lengthens, go separate with only the people involved. Or, go into a direct call, when a discussion intensifies. Like if you talk too long when in the office and by that disturbing the people around you, you go into a meeting room.
  • People that attend a session or ceremony should have their video on. This increases the feeling of being present and reduces the chance of being distracted by unimportant matters for the session. The microphones should be muted if participants are not speaking to reduce background noise that could distract others.
Plan and control from outside the team

The main reason for managers to go into a plan and control mode is the lack of visibility of the team and its progress. Therefor the counter measure can be found in this area.

  • Invite these managers more frequently to the sprint review than you are used to. During the review they can see the team at work while showing the progress made.
  • Because the review becomes of more value to managers, it should be prepared with more care, to make it a smooth journey. However, this doesn’t imply that more preparation time should be taken. Rather the development team keeps the review in mind during the sprint while working on the backlog items. This could result in a slightly extended Definition of Done.
  • In a face-to-face situation a physical Kanban board is often somewhere in the room on a wall. If managers walk by, they can look at it and ask the product owner questions about the team progress or a specific backlog item. To keep the visibility at an as high as possible level, one could consider providing them access to the online boards. Be aware that they cannot change it unwantedly.
Focus issues

Preventing losing focus or going into a hyper focus, is a hard job in a remote situation. You cannot see and feel the tension people are facing just by being present. What you could do is trying to reduce the chance that team members are having focus issues, or the impact when they actually do.

  • As an agile coach, stay in frequent contact with the team members. Have a regular chat, of course with video on, about everything that is going on in the team member’s mind. Be alert on signals of focus issues. Like home mates asking for attention regularly, cats or children making noise, but also if they look tired or have a loss of concentration. So, not only listen to the words but watch the environment.
  • Make monitoring this a team effort. Let everybody be aware of this risk and stimulate the social cohesion by inviting them to look after each other.
  • And when having team meetings try to put in some fun factor. Things like playing a short game, some team member giving a virtual tour through the house, emulate a lunch walk with everybody in a live audio meeting. Ask people questions about other things in life, next to the job they are on. Like you do in the office.
Skip inspect and adapt

The worst thing you could do in an agile way of working is skip inspect and adapt activity. It will reduce the team’s capability to learn and improve tremendously. So, the only measure to take, and the only advise is: Just don’t!

There are some measures to take to have a smooth Inspect and Adapt session:

  • Have the proper tools in place. These tools should facilitate collaboration. You could consider tools for sharing and updating sticky notes, whiteboards or supporting specific purposes of scaled ceremonies.
  • Be sure to have tested these before. Especially for meetings where stakeholders outside the team are attending, whose valuable input you really need.
  • The measure for ‘Not being together’ related to video and voice, always have it on and be muted when you have nothing to share, also applies to this topic.

Conclusion

There are a lot of pitfalls while working remote in an agile environment. Luckily, the Agile Manifesto and its principles as well as the Scrum pillars and values provide us enough guidance in detecting (see the appendix) these pitfalls. Based on our analysis we have been able to identify common measures that could possibly help you in your specific situation. To find the most valuable and useful measure when you work remote, especially now most of you must work from home during the current pandemic, you should frequently do an Inspect and Adapt yourselves.

[Authors: Jan Klabbers and Christo Martens]


Appendix: Inspection brown papers

For the inspect we have done some brainstorming. We have set up a brown paper per subject to inspect the Agile Manifesto and principles, and the scrum pillars and values. These papers contain per item the risk or facts that we came up with. Afterwards we grouped these to find the common grounds. We have found four common grounds: Not being together (NBT); plan and control from outside the team (P&C); Focus issues (FI); Skip inspect and adapt (SIA). The result is shown in the next tables.

Agile Manifesto

Manifesto

Risk / Fact

Common ground

Individuals and interactions over processes and tools

We need more tools for communication to bridge the physical gap between team members. That’s for sure.

-


When using communication tools so often people might only meet live in a synchronous mode (calls, online meetings) during the standard events and use a-synchronous modes (chat, e-mail) for all other communication due to an overload of online meetings. The latter causes a delay in the communication

NBT


As the physical visibility of the work team members are doing decreases, people might tend to put emphasis on control mechanisms in stricter processes

P&C


People that aren’t at the same physical location are missing out on conversations between other team members and by that missing the opportunity to provide spontaneous valuable insights and contributions

NBT


With less interaction people might get distracted by other matters in their private space

FI


People that are unwilling to participate in meetings might blame the tools for not being able to contribute to discussions. Press your moustache – to use a Dutch saying.

SIA

Working Software over comprehensive documentation

The impact of working from home is very little. Still a proper adaption could be to be more reliant on documentation. If adaptation is done consciously, there no problem.

-

Customer collaboration over contract negotiation

As the physical distance between team and customer increases, people might tend to put emphasis on control mechanisms in stricter processes. And by that more emphasis on contracts

P&C

Responding to change over following a plan

When communication tools malfunction during events, like reviews, demos, stakeholders might not see the needed change on product or process and the team continues working based on the incorrect knowledge

SIA


Because discussions between team members and between team and business is less effective and efficient, they might not see the needed change on product or process and the team continues working with the wrong knowledge

NBT

Agile principles

As the agile principles form the foundation the Manifesto is built on, we only mention the new insights below.

Agile principles

Risk / Fact

Common ground

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Nothing special here

-

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Nothing special here

-

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Nothing special here

-

Business people and developers must work together daily throughout the project.

Malfunctioning tools will cause a (strongly) reduced effectivity on customer contact moments like some ceremonies

NBT

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

If less visibility or transparency, reduces trust by management and causes them to tend to more plan and control, the team will become less self- organizing and make fewer decentralized decisions.

P&C

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

That’s the issue and main topic of this document

NBT

Working software is the primary measure of progress.

Nothing special here

-

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Social risk of people being distracted from home

FI


The opposite of being constantly in the zone and don’t take a break or don’t stop in time.

FI

Continuous attention to technical excellence and good design enhances agility.

People might be wandering off because they aren’t corrected by team members

NBT

Simplicity – the art of maximizing the amount of work not done – is essential.

Risk of skipping ‘natural’ peer review, less pair programming/designing/story writing, which can lead to people not seeing the simple solution.

NBT

The best architectures, requirements, and designs emerge from self-organizing teams.

Natural discussion on these topics might be skipped. See former point

NBT

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Risk of not being open due to communication through tools

NBT


People that are unwilling to participate in meetings might blame the tools for not being able to contribute to discussions. Press your moustache – to use a Dutch saying.

SIA

Scrum pillars

Pillars

Risk / Fact

Common ground

Transparency

Risk of team going under the radar

P&C


Risk of team members to be distracted when they aren’t visible to others

FI


Risk of management wanting to have daily evidence of progress (progress reports on tasks hours spent and estimated) else than working software.

P&C

Inspection

Risk of skipping events – as they are ‘not effective remote’

SIA


Inspections not as effective as being in one room

NBT

Adaption

Risk of going through the motions and settling down with solutions without commitment

SIA

Scrum values

Values

Risk / Fact

Common ground

Commitment

Courage

Not being together, can undermine the team spirit and by that the commitment

NBT


You can’t look people in the eyes, the moment they say they are committed – no indication whether they are pressing their moustache (people saying yes and doing no).

NBT


People have a fear of speaking up through tools

SIA


Management might want to increase influence on the process as they cannot see team members showing their courage

P&C

Focus

Risk of lack of focus or hyperfocus because of working conditions

FI


Risk of wandering off while not being corrected by team members

NBT

Openness

Communication by tools might either cause people to not say the things they have on their mind. Or on the opposite state their opinions in an improper way.

SIA

Respect

Distance might cause people to lose respect

NBT

No comments:

Post a Comment