Challenges in the  — a guide to how we handle them

Close cooperation imposes other demands on members in the mob. You can not hide from conflicts …

Challenge: different wills and ideas

To handle different wills, listen and compromise.
Team Processes and communication are essential to make mob development work. Mobb involves more interactions with each other in the team. To handle all interactions and close collaboration, we use Core Protocols, a communication tool for focusing, raising awareness, making decisions and getting better at incorporating what others say in the team (positive bias).

Team agreements to lean against. Concrete and can be questioned. Not least by new team members.

Challenge: Keeping focus

It is easy to fall into everlasting discussions, trying to find the perfect solution, or zone out when we are many. The more chefs the worse the soup …

Mobb rotations in 10-minute intervals. We are strict about rotating within the mob. When we forget to rotate and one and the same person stays at the keyboard (usually stuck in the role of both driver and navigator), the focus and commitment is quickly reduced in the mob. We keep track of time using our mob timer. And for a quick change at the turn, we have a common computer.

Two “mob rules” that we above all stick to are the rotation within the mob and that everyone should take part in the mob, even if everyone does not do it full time. I can for example prepare some user research-parts outside the mob.

Mob-rules. We have agreed on a few mob-rules. These work a bit like team agreements but for the mob.

The team’s mob rules.

Daily Retro. We do not have a daily standup (except for a brief check-in to know if anyone will be away on meetings or leave early) since the whole team is working on the same problem and common goal. Instead, we have a short daily retro where we ask three questions:

1.) Are we getting any closer to the goal? 2.) Whatever, are we working on the right things? 3.) How do we proceed in the loop?

Good enough for now, safe enough to try. Try a solution instead of trying to discuss your way to the “best” solution.

Time-Boxing discussions. When we where new as a team, we had a tendency to end up in long (exhaustive) discussions about how to proceed. We had not embraced Good enough, safe two try but tried to discuss our way to the “best” solution instead of trying one hypothesis. The team is now more self-conscious. We know that we need to time-box our discussions, or park them if they are not relevant right now.

Challenge: Common understanding

What are we doing? Where are we heading?

Learning from each other’s areas of expertise. Stepping out of one’s comfort zone and feeling committed to what’s beyond ones expertise.

Visualize. Visualization of concepts, ideas and solutions will be important in order to explain to everyone in the mob. In order for everyone to follow where we are and where we are heading. Often on a whiteboard.

High level of abstraction. When we code, we keep it at a high level of abstraction. The navigator needs to articulate what she or he wants to accomplish to the whole mob, more than precise commands to the driver. This allows others in the mob to further develop an idea, addressing potential risks or problems with a proposal, at an early stage. In addition, as a designer who lack good code syntax knowledge, I will be able to understand and contribute.

Lean UX as a work method: Helping us navigate towards the goal.

Challenge: When shared responsibility becomes nobody’s responsibility

Still a challenge at the time of writing.

Guardians. We are good at sharing responsibilities when it comes to team processes and work processes. Other things that we need to do outside the mob are more difficult. However, action points from our team retrospectives are each assigned a Guardian, responsible for follow-up. Works most of the time …

Challenge: Ego and the need for control

Dare to let control over design details and gain control over the whole picture.

Facilitate rather then controlling design in detail. And what can I do now when I do not need to check every design implementation, when the team is self-going and focused on goals and usability? Take a vacation? I had to rethink my role. My role is now more about facilitating. There is more room for user research, better UX strategy and innovation that provide value and feels meaningful. But on and off, I still have to fight with uncertainty about what my role in the team is.

Challenge: Further development within one’s area of expertise.

How can I be able to feel that I contribute in the mob although we sometimes work in areas far from my own area of expertise. Is there time to learn these areas as well, while maintaining my expert level in my own field?

Time for recess outside the mob. In order to maintain my UX perspective in the mob, I still need to be able to immerse myself in my field of expertise. It is no less important to stay up to date in one’s area of expertise in order to be able to contribute in the mob. (And the mob can make this time possible, but it is my responsibility to take it.)

Challenge: Motivation.

To feel motivation even during periods when we do not work in “my” area.

Agile UX — to work in small “waterfalls” between discovery and delivery. Aiming for short iterations, so you’re never away from what motivates you the most for long periods.

Solo time. The hardest thing about working in a mob. Mob as a way of working does not suit everyone and it is important to be aware of this. To know if it works, the team needs to give it an honest chance, a period to be evaluated, in the same way you would try other ways of working. You do not know until you’ve tried! And if mob development does not work full-time for everyone in the team, create a more flexible way of mobbing. Do what works well even more. “Turn up the good”, Woody Zuill should say.



Source link https://blog.prototypr.io/-of-the-team-in-a-mob-for---taking-mob--a--of--further-62d1e9962f37?source=rss—-eb297ea1161a—4

LEAVE A REPLY

Please enter your comment!
Please enter your name here