Agile work from home tools for large organizations
Which tools can facilitate working from home in large agile organizations?
Working from home, also called telework, has increased significantly over the last years. Approximately 40% of the workforce in the United States works remotely at some frequency.
Teleworking motivates staff to better manage their work-life balance.
Home working is also a necessity in case of crisis, such as the Corona virus:
The WHO issued an advice on February 2020 to promote regular teleworking.
When people, schools, regions or companies are in quarantine, working from home is often the only option to continue the services.
But how to set up home working in an agile scrum organization? What if you are using physical boards and sticky notes?
I’d like to share my experience on agile work from home tools and best practices for:
Internal team communication
Agile team planning
Agile program planning
Use group chat and video calls for internal communication
E-mail is a trivial tool to use when working from home.
But who doesn’t complain that they receive too much e-mails?
Wouldn’t it be great to remove all internal textual communication with something better?
There is such a thing: ‘group chat’ (also called ‘instant messaging with channel functionalities’).
Why replace e-mails with group chat?
First reason: reduce the number of persons that don’t need to read your e-mail immediately.
Instead of putting persons in CC, the conversation can become transparent in a channel for all interested persons. With group chat, each team member decides which topics (=channels) to follow.
Private channels and direct messages can still be used for more sensitive discussions.
Second reason: less waste
When creating an e-mail, there is little room for interaction. The author is never sure if the messages are clearly understood. There is a risk that one provides more information in an e-mail than needed (waste of energy) or too little information (risk of quality).
With a chat, you have an interactive discussion.
Can we reduce automatic e-mails?
Replacing internal e-mail with chat is a good step forward, but what can we do about automated e-mails created by other tools? What about e-mails from the build system, incident ticketing system, scrum planning tools?
There is good news.
Popular group chat tools have plugins for the most common intranet tools.
So you can for example include the build system status and messages in channels, and disable the e-mails coming from that system.
Slack group chat tool. Channels are visible on the left side. Integration with github source control management in the central panel. Threads are visible on the right panel.
How does group chat works?
To start, physical teams are configured as teams in the tool. Simply use a one to one mapping.
Each team can then organize the channels according to the topics they want to discuss. I think between ten and twenty channels is good for an average team. Use threads to further separate discussions within one channel.
Some example of channels used in my teams:
General: for general announcements (e.g. management updates, persons being ill, …)
Development: technical discussions about software engineering, code coverage, …
Analysis: exchange information to get scrum tickets ready for development
Testing: for testing, test automation, …
Incidents: handling incidents and crisis situations
Architecture: long term technical vision
Sprint-day: preparation of the sprint demo, sprint review, retrospective & planning
Bigroom/PI Plan: preparation of the next large Program Period
Random: non-work related discussions between team members
Don’t stick to a fixed channel list. Agile teams are self-organizing, so let them find their own way. Let your teams add channels for the challenges they are facing.
But group chat tools also has its limits. It’s not a silver bullet tool for agile teleworking.
Importance of voice and video calls
In 1971, Albert Mehrabian published his study on non-verbal communication.
He found 93% of the communication to be nonverbal in nature:
55 percent of the weight of communication is assigned to body language and visuals
38 percent is assigned to the tone and music of their voice
So visuals and voice are very important in communication.
When calling someone, share the screen to co-work on a document, presentation or drawing, or use a webcam to share visual expressions when discussing more sensitive matter (people, conflicts, etc.).
Some teams keep webcams open during the entire working day. This to facilitate visual communication and social contacts with colleagues. A working day starts by joining the online web-meeting.
Calls become counterproductive when the quality is bad. It is important to take appropriate technical measures.
Talk with your system administrators to check if there is enough technical capacity (network bandwidth, firewall capacity, VPN licenses, etc.) to let everyone work from home at the same time. If you want to be sure, organize a test run within your organization.
Rooms are noisy, so you’ll need a good microphone and speaker. Usually the microphone and speaker from a laptop aren’t enough to filter out the background noises. Cheap models even deform the voice.
Which tool to use inside the organization?
There are plenty of tools in the market. My teams successfully worked with the following tools for group chat and video calls:
Jira has a server, cloud and data center variant. The cloud version can be used instantly without any need of a server. The server solution needs to be installed on your own server. You’ll need to do the system administration as well then.
Larger organizations usually use the server variant, for integration with other server applications and server plugin support.
A trial of 1 month can be requested. So you can first try out teleworking with the agile tool, before rolling it out in the organization.
How to get started with Jira?
Agile teams are self-organizing. Finding a volunteering team shouldn’t be too hard if they see the benefits.
I’ve noticed that a “one Jira project per team” approach works best in agile companies because of:
self-organizing teams. The workflow is at the heart of the internal organization of a team. You can’t be self-organizing without your own workflow. In order to have a workflow, a team needs its own Jira project.
clear ownership. All tickets from a specific project are owned by one team. And one team only has one project to manage.
For efficiency. Combining multiple project on one team board is possible but can cause subtle hustles. For example: if the permissions are not aligned, some tickets are not visible for team members. If the workflows are not aligned, you could have unusable columns on the board. This can be avoided with a dedicated Jira project per team.
A Jira project contains tickets, also called issues.
The standards scrum ticket types are available:
Story: work to be done that generates business value
Bug: issue detected after the release of the code
Spike: investigation of a new technology or functionality
Epic: large group of functionalities with business value
Jira has digital Scrum and Kanban boards.
Create at least one electronic board per project. I’d advice to create as many boards as you want. Some examples:
A Scrum Board for the Backlog Refinement, Sprint Planning and Sprint Review
A Kanban (or Scrum) board for the incidents in a team
A board to group all stories related to a specific topic
A board for all incidents cross teams
A board for all incidents cross teams for one client
Atlassian Jira. A scrum board of a team is visible. The workflow of this team contains 3 basic steps (to do, in progress and done). At the right hand side, details of the selected ticket are visible.
Jira best practices
Unfortunately, Jira can be badly configured and slow down your organization.
Pay attention to the following.
Each team should have its own workflow. A workflow contains the flow of statuses per issue. Don’t define a central workflow for all teams. I’ve seen it a few times, and a central flow never works. Why?
Because a central workflow becomes too heavy when trying to combine the needs from all teams.
At the same time, a central workflow can become too light when it doesn’t include the specific challenges of one team.
Because central also means static. Agile teams aren’t static: they are continuously learning and experimenting. Agile teams can’t work with a static workflow. They need their own workflows and adapt continuously.
There is no such thing as a balanced central workflow: it is too heavy for some teams while being too light for other teams.
Update the screens to include all relevant fields. A screen is what you see when opening an issue in Jira. It contains a subset of all the fields for the issue. Unfortunately, not all important fields are included by default in the screen. Story points being a notable example! So when creating an new Jira project, update the screens accordingly.
Adding the story point field to the screen of a Jira Project of a team.
Some companies restrict the rights of users. Agile organizations put trust in people. For example, give users the possibility to create as many boards as they want. Jira can handle this easily.
Agile promotes transparency. Unless needed for legal reasons, keep projects visible for all users. This will facilitate cooperation and communication cross teams.
Distribute Jira administrator rights in the organization. Teams will often need to interact with Jira administrators to update workflow and screens. Putting Jira configuration behind a help desk limits the growth of teams. I’d advice at least one administrator per 25 users to support the growth of teams. The central Jira administration community or help desk only needs to focus on global administration (e.g. keeping user lists up to date, version updates, plugin installations and updates, etc.).
What about security and privacy?
Atlassian complies with EU-U.S. and Swiss-U.S. Privacy Shield Frameworks.
Plan iteratively on program level – plan ahead at program level (e.g. like the Program Increment planning in Safe )
Because I couldn’t find one that suites, we’ve released a new tool ourselves : the Agile Programs for Jira plugin, based on 10+ years of experience managing critical programs in large organizations (https://ativo.io/solutions/).
How does Agile Programs for Jira work?
The tool supports the two main activities in program management: planning and follow-up.
The Program planning is done in following steps:
Product Management creates a prioritized list of feature tickets for the major functionality to be added
Teams refine the features and break them down into stories. Stories are linked to feature epics.
Teams plan the features and stories for the next Period
Teams align their dependencies
Teams highlight risks and confirm commitments
Progress follow up (e.g. via weekly Scrum of Scrum or Art Sync meeting) is done as follows:
Teams update the RAG (Red Amber Green) status and comment prior to the meeting
Teams show progress on features and team level
Teams raise issues and risks.
Management and teams review the issues and risks, take decisions and define mitigation actions.
The good news?
Progress is consolidated automatically. The tool uses the link between features, stories and teams to consolidate progress per feature, team and program. No need to add the same data twice.
In the same way, dependencies are detected automatically and visualized on the Program Board.
The data of the program fields can be used to create standard Jira boards. Some examples:
Agile Programs for Jira demo. Navigation between planning and progress is done in the left navigation bar. The progress dashboard per team shows pie charts of features and dependencies, a burn-up per team with forecasts and a sprint planning with progress and status per feature and dependency.
How to get started?
Installing Agile Program for Jira requires the following:
Edwin is Master in Engineering and Master of Management. He has 10 years of experience managing strategic IT programs. His focus is on agile planning, clear communication, leading teams and mitigating issues. He is certified SAFe Advanced Scrum Master, MSP (Managing Successful Programmes) Practitioner and Prince 2 Practitioner.