Kim Arnett [she/her] leads the mobile team at Deque Systems, bringing expertise in iOS development and a strong focus on accessibility, user experience, and team dynamics.
Admittedly, all the teams I've worked on share the same struggle.
We all seem to have our core strength, but we're all in a place where if Fred, for example, left the team, the team would be able to continue on..even if limping along.
Here's a few of the things that get us along-
Use a team wiki (i.e.: Confluence)
Whenever we are learning something new - we put instructions/guides/user names/passwords/urls all on a shared site. It's up to us to maintain it, but the team lead will remind us whenever something comes up that "that should be on confluence". Or when we're looking for something late and find it's not there, we'll be sure to ask the developer to get it on there.
Lunch n learns
These can definitely be inconvenient if too frequent, but even 1 a month is an improvement. If the company is able to provide lunch, that's a incentive for people to show up. We've done sessions on unit testing, a demo on something we felt was really cool, a demo on a framework, or product, or x is all fair game. Keeping it casual is also key. Building powerpoints takes a lot of time.. but having your key points laid out and demonstrating them is a lot more interesting and interactive.
Open working area
Everyone has their own space, but I can easily turn around and ask someone, in person, to clarify x, y, z. This has enabled the lines of communication. If we're stuck, we'll sit at each others desks until we're both understanding, etc.
I've always liked the idea of a team wiki that functioned at a higher level than one particular project. For example, perhaps I could write an article that breaks down a common pitfall we always run into or tips for improving productivity while using a particular tool. I remember pitching Confluence at one point, too.
The open working area concept isn't my cup of tea. I understand the appeal of that for some, but I enjoy the relative privacy of my cube fort. Personally, I feel that our team manages to communicate freely enough despite the chest-high walls which separate us.
One thing we are trying to strive for more of is the interactive demo like you mentioned in point two. Since our sprints most often don't end with a code deployment, we hope that instead of a deliverable product we can present our accomplished work. Not only do we get to feel like we're "delivering" something but everyone on the team or involved in the project can see the progress we're making.
We have a team wiki that we could be better about being updated. We've do internal presentations that everyone benefits from. But I don't think people are always psyched about carving the time to prepare these.
I'd love to get into mob programming a bit. It's like pair programming, but the code is projected and the whole room drives.
Kim Arnett [she/her] leads the mobile team at Deque Systems, bringing expertise in iOS development and a strong focus on accessibility, user experience, and team dynamics.
Well the idea is that the person typing does not drive, mostly takes instructions, and everyone else collaborates on the solution. Still would be a bit nerve-racking but mostly on a "do I know all the proper keyboard shortcuts" kind of way.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Admittedly, all the teams I've worked on share the same struggle.
We all seem to have our core strength, but we're all in a place where if Fred, for example, left the team, the team would be able to continue on..even if limping along.
Here's a few of the things that get us along-
Use a team wiki (i.e.: Confluence)
Whenever we are learning something new - we put instructions/guides/user names/passwords/urls all on a shared site. It's up to us to maintain it, but the team lead will remind us whenever something comes up that "that should be on confluence". Or when we're looking for something late and find it's not there, we'll be sure to ask the developer to get it on there.
Lunch n learns
These can definitely be inconvenient if too frequent, but even 1 a month is an improvement. If the company is able to provide lunch, that's a incentive for people to show up. We've done sessions on unit testing, a demo on something we felt was really cool, a demo on a framework, or product, or x is all fair game. Keeping it casual is also key. Building powerpoints takes a lot of time.. but having your key points laid out and demonstrating them is a lot more interesting and interactive.
Open working area
Everyone has their own space, but I can easily turn around and ask someone, in person, to clarify x, y, z. This has enabled the lines of communication. If we're stuck, we'll sit at each others desks until we're both understanding, etc.
I've always liked the idea of a team wiki that functioned at a higher level than one particular project. For example, perhaps I could write an article that breaks down a common pitfall we always run into or tips for improving productivity while using a particular tool. I remember pitching Confluence at one point, too.
The open working area concept isn't my cup of tea. I understand the appeal of that for some, but I enjoy the relative privacy of my cube fort. Personally, I feel that our team manages to communicate freely enough despite the chest-high walls which separate us.
One thing we are trying to strive for more of is the interactive demo like you mentioned in point two. Since our sprints most often don't end with a code deployment, we hope that instead of a deliverable product we can present our accomplished work. Not only do we get to feel like we're "delivering" something but everyone on the team or involved in the project can see the progress we're making.
We have a team wiki that we could be better about being updated. We've do internal presentations that everyone benefits from. But I don't think people are always psyched about carving the time to prepare these.
I'd love to get into mob programming a bit. It's like pair programming, but the code is projected and the whole room drives.
I'd be interested in trying it, but my anxiety would die if I had to code in front of a room of people judging me while in front of a giant screen. 😶😶
Well the idea is that the person typing does not drive, mostly takes instructions, and everyone else collaborates on the solution. Still would be a bit nerve-racking but mostly on a "do I know all the proper keyboard shortcuts" kind of way.