Thursday, November 17, 2016

Mob Programming, Flat Structure, and Technical Development Q&A

I received more questions from Nicholas U in a previous blog and once again his questions are great ones and I would like to answer them as another blog post.

You said that you put in place a flat organization, with team members taking care of managerial tasks. Can you tell more about this? It' not so common in the software world, even in agile teams. What managerial tasks are done by the team members, and how?

This system came about when our former manager Woody left the team. We retrospected about it and rather than asking the upper management to put in a new manager or promote one of us we decided to simply share the manager role with everyone on the team. So, we as a Mob we began to report out to the rest of the organization as a manager would rather than through an individual. Since then our org has created a new software development department and I have been moved into a director position. We hired to create between 6 and 8 full time mobs and as we grew this format stuck. Aside from a few small tasks essentially every management task is handled by the mobs themselves.

Thus, every meeting a manager would attend we would send either 1 or 2 people from the mob to attend the meeting. We eventually created a Kanban board for management tasks and did a round robin to have each people gain some management related experience. This meant that junior level developers would gain this type of experience as well. Over time through retrospectives we found that some tasks had better results when we had a whole mob take them on. For example, we had a much more complete and thorough look at conference budgeting with 4 people looking at the details. This ultimately lead to fewer mistakes and better use of every one’s time. This also leads to the automation of as many management tasks as possible. For example, reporting the status of a project to the rest of the org has been fully automated now. Since we were being frequently asked about status by loosely involved stakeholders we have put together a status dashboard and we use our Gherkin scenarios to report out what recently has been completed in an application. We also mine our continuous integration server to report out release frequency other key items. This has so far fully satisfied those counterparts.

When I made the transition to director of the software development department we as a group were concerned about the HIPPO effect in the office and my word taking too much weight. I am the closest thing to a manager in the group right now but I do my best to involve the entire department in the decisions that I am responsible for. We also make sure that all new employees know that when I give technical or managerial advice it is only a suggestion and not a command. With a team our size we would likely have a few managers in the group under me but instead we automate or distribute the work. This has led to a higher level of engagement from the entire team, higher psychological safety, and exposure of the developers to the rest of the organization.

What resources inspired you to set-up this flat hierarchy model?

We knew about organizations like Valve and Gore-Tex that have flat structures but we did not set out explicitly to create a flat structure. Initially we arrived at a flat structure because we wanted to experiment with it and see if it could work. We frequently retrospect and each time we have an opportunity for an experiment we usually take it. In this case, we went 6 months after the former manager had left and before I was put into the director position. During that 6-month period, we were very successful in keeping up with everything we needed to. After I became director we felt we were more effective without managers still and as the team grew we found that automation and collaboration on management tasks was making our group better to interact with. Our developers have more context and the organization has more insight into the inner workings of the team.
Reflecting on the decisions we made I can identify many advantages that simply emerged out of our retrospectives within this flat structure.

First, we have put in place measures to disrupt pecking orders. When we started Mob Programming we quickly retrospected toward a heuristic that states the most knowledgeable or senior developer should defer to anyone more junior that has an alternate approach unless that person can be convinced why it is not the correct approach. The team can always later reflect on the validity of the approach and everyone learns something about the team and the technical detail. This heuristic grew into and more general idea that influenced our job descriptions. To be promoted within our group, you not only need the technical knowledge yourself but you also need to be coaching and teaching the rest of the team. We optimize the department and not the individual, contributions to that end have tangible rewards.

When ever I bring up pecking order in an organization I have to show this Ted talk:

Second, we have always been fond of the idea of self-organizing teams. This concept also grew with us as we found that having self-organizing teams around management tasks or anything out of band like minor maintenance updates made us much more effective rather than assigning these items to an individual or interrupt an entire mob to accomplish these tasks.

Finally, it quickly became apparent that self-organizing around management tasks lead to a higher level to trust between team members and the management related decisions made within the group. Not only did all of our developers get a chance to work with each other regardless of teams but the decisions were all made either by a small committee or a larger consensus giving no single person ultimate power over the groups direction.

You said that you are mostly inspired by the Agile Manifesto. Does it mean you don't adopt mainstream agile methodologies? Are you mainly setting up the process by verifying that it is guided by the Manifesto?

So, I should have instead said we relentlessly retrospect. We experiment frequently and with that we find out way to better quickly. I have nothing against main stream agile methodologies and I believe that any framework is a great starting point. I feel however that the most important thing we are doing is the inspect and adapt loop. Beyond that everything is up for experimentation including the agile manifesto, it just happens that we are not following a specific framework but we do incorporate known schema that fit our current work methods. Schema like Kanban, the Agile Manifesto, Continuous Delivery, Behavior Driven Development etc... If our practices begin to follow scrum we would say we are using scrum but we would need to arrive there by retrospection to it instead of “adopting” a framework. So to answer your questions we are simply guiding our decisions by asking “Can we be better than we are now?” and then running an experiment on our process followed by a retrospective. So with that in mind we do not verify that all our decisions are guided by the manifesto we just usually end up coinciding with the manifesto.

I understood that there are no architects in your teams, so the architecture is really an emergent one. However, is there kind of an inception phase before a new project begins, where the backlog is set up and discussed, and the main technical solutions are discussed and evaluated? I think I guess the answer, but I would like to hear that :)

Anyone in the team could potentially contribute to the architecture of a solution, architecture is part of the mobs set of responsibilities, however we are big fans of refactoring to patterns and code by intention. That is we refactor constantly as part of the work we do. It is expected that a team continuously refactors toward better. (Loosely coupled, highly cohesive, Unit tested, Behavior tested etc.) We have had many systems start as an experiment or a 10-year-old legacy project that transformed over time into a clean and well architected solution. One thing we do avoid doing however is looking too far into the backlog. We Kanban our features each to product a completed product ready for delivery, even if there is nothing of substance yet. The ideas is that as we build, we will have descriptive Unit and Behavior tests that will allow us to safely refactor with low rest and a fast feedback loop. This allows for truly emergent architecture.

Another great Q&A and I enjoy answering these questions. Please leave questions in the comments and I will line them up for future blogs if I have not answered them already.


  1. Hi, great post.
    Emergent architecture really is a tough topic.
    You certainly have much experience on this field, and you view on the emergent architecture process looks quite extreme, that is, really emergent.
    I would be interested in having some examples of how you successfuly applied it, and if there are some "limits" that you encountered regarding the emerging architecture.

    1. Working on a blog to respond to this question.

    2. here is the response let me know your thoughts!