Sunday, February 10, 2019

Mobs in the real world

Discussion prompt:

Mob programming is a fantastic tool, and having mobbed for two years on a software engineering team I have great buy in for its effectiveness in serving the needs of a company. However, myself and colleagues have continued to struggle with individual recognition, in particular how our companies recognize the various types of work that happens in a mob, and the work it takes to maintain a healthy mob.


To begin, we used the lense of "who benefits and who is burdened?" to discuss the merits of mob programming.


Who benefits?

  • Early engineers benefit from a quick feedback loop as they start learning; if they have questions, it is not long until they are addressed and answered.

  • Engineers looking to learn a language or stack in order to effectively support a service; and vice versa, whoever is teaching benefits from sharing their knowledge and breaking down a knowledge silo.

  • Support team, QA, Product Owners, Managers who participate (or at least co-work) with a mob are more engaged in the software development process, and they experience a quick feedback loop for changes.

  • The company; this came up over and over again, the company benefits when engineers work in a mob.


Who is burdened?

  • Senior engineers can feel the limitations of the structure and prescribed methods of mobbing.

  • Managers who are not embedded on the team have a great deal of work to do to understand individual contributions.

  • Early engineers who find themselves overwhelmed, but unable to self-advocate effectively.

  • Mob organizers; this can be anyone in the mob who tends to spend more time facilitating retros and hard conversations, coordinating work to be done or communicating with stakeholders. This is especially concerning if an early career engineer, or underrepresented voice is taking this work on as it is extremely challenging to get recognition.


What are ways to lessen the burdens listed above?

  • As a colleague, make specific call outs of the work your peers do that contributes to the health of the mobbing team.

  • Support early engineers by providing a single go-to mentor, or on-boarding buddy, who will help contextualize work being done, fill in knowledge gaps, and help the mob adapt to their needs.

  • Call out roles that you see being played that are not traditional driver/navigator mob roles. Maybe you see a starter - who can motivate everyone to get started each day and while it just may be minutes each day, over time it has a big impact. In pointing out a new role, you can then ask: "Is this role valuable to the team?" and let the conversation lead you to recognition, and sharing of the role.

  • Recognize the management hierarchy. Successful mob teams self-organize, and self-critique, which is a flat structure that often reports to a hierarchical management structure. We tracked that this difference in structure may be an impacting factor when trying to track and understand the impact of individual contributions.

  • Performance reviews: Have a very clear understanding of who is conducting reviews, and to what end. Reviews often identify strengths, and weaknesses. In a healthy mob, there is a near continuous feedback loop for what is working, and what is not, but it is important that this conversation is also had between the individual and the company they work in.

  • The example of a manager who embeds with the team (a player/coach). We heard a great example of a manager mobbing with the team, with the intention to help each individual grow. They have to keep a dual focus, on the work being done, and individuals needs, but the general sense was a manager in this role is particularly empowered to put individuals needs and recognition first. (A concern we didn't address is whether a manager in a mob limits individuals from taking on more responsibility).

  • Because a mob is so focused on work, individuals themselves may find it hard to recognize and explore their own interests and needs. Maintaining regular 1-1s seemed like an option to give time and space to reflect on individual needs.

  • Being an expert in a mob can be a burden. Technical experts may be the most aware when colleagues are not grasping a subject and work needs to slow down. Organization experts may be most aware when interpersonal issues are causing friction that endangers work in progress. We collectively called out that this burden is ok to be carried by senior engineers, but that it should be carefully called out and assessed if non-senior engineers take on either of these roles consistently.

  • Mob teams tend to manage up. Managing up is a huge help for manager to put into perspective subtle differences in assessing individual performance in a mob. If a manager is used to reviewing code contributions on github for example, the mob members have to explain that this data doesn't characterize the work being done, and offer alternatives. Remember, that if you manage up for yourself, it likely applies to the rest of your team as well.

  • Mob teams need their management hierarchy to opt in to a different set of evaluation practices on the technical, organizational, mentorship, and self-determination practices that individuals cultivate. Without reinforcement of mob best practices, mob members can lose their motivation to continue doing critical work that has turned burdensome.

  • Mobs need to also allow time for deep thought to grasp complex subjects.

  • Early engineers are easily overwhelmed, and least likely to speak up

    • If diving into a difficult domain, this can compound the effect

    • The pace of a mob can be difficult for one person to influence

    • There is persistent peer pressure to continue at the current pace

  • Mobs must continually improve through experimentation; the grown mindset is incredibly important and a mob that doesn't change proces often may be experiencing problems they are unaware of.

  • Carefully consider the neurodiversity of a team. Individuals focus needs are different, and if the common denominator isn't working for an individual, flexibility is required.

  • Allow team members to opt in and opt out of the mob with fluidity. This can be on a day by day, and hour by hour basis, but most importantly, if a mob is not accommodating an individuals needs then allow flexibility.

No comments:

Post a Comment