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:
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.
Hi, great post.
ReplyDeleteEmergent 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.
Working on a blog to respond to this question.
Deletehere is the response let me know your thoughts! http://www.chrislucian.com/2017/05/q-emergent-architecture-mob-programming.html
DeleteExcellent post. By the way, I think Hunter has developed a far better culture than other companies that claim to be flat. If you look at the Valve employee manual, it all sounds great. If you read Glassdoor, it is not.
ReplyDelete