Mob Programming Q&A: Product Owners
(Video from: https://www.youtube.com/watch?v=dVqUcNKVbYg)
Another great set of
comments on one of the Q&A blogs this set comes from Nicholas U.
His question started with
the comment “Mob Programming requires a great availability form the business,
because they have to validate the many baby steps that you do.”
Q: How is the business organized to work with the Mob Programming teams?
A: As a
method for communicating with executives, recently we have started to equate the
Mobs within the team to “work streams”. It works as a great metaphor to explain
that we have 1 Kanban board per mob and each mob has 1 task WIP. We can work on
1 feature per Mob and the business can decide if how many Mobs per project they
would like to allocate.
For example,
Project 1 can have 2 Mobs which means we will parallelize 2 tasks at any one
time for that project. While Project 2 can have 1 Mob and that project can only
handle 1 item WIP. This Mobs can always be re-prioritized once a task is done
but the cost of thrashing is made clear to the org.
Q: Do you use the traditional scrum pattern?
We use the systems and practices that are incorporated as a result of retrospectives. Some can be found in traditional scrum and others cannot.
Q: Do you have one Product Owner per product, that represents all the different business stakeholders and that is empowered to make all decisions about the product?
A: When we first started Mob Programming
we already had dedicated product owners. We want a funnel of highest priority
features fed to the Mobs though one person. Each product owner is responsible
for distilling down the MVP items for a project
Q: Or do you have several business representatives for one product, that can come and validate what you are doing?
A: Given
that we have one product owner distilling down the tasks to most important, it
does not mean that we are not incorporating input from everyone in the
organization. One thing we had retrospected on in the past was product owner
siloing. We found that having a single product owner was not enough since they
may be not communicating their decisions throughout the org. We had to make
sure that their choices were visible to all the stakeholders no matter how
minimal the stakeholders input is on the project. The complete features are
communicated to anyone who has any input to give at all at least once a month
if not more.
Q: Are the business representatives co-located
with the team all day long?
A: We try for co-location and Mob participation first. Ideally
if we can the Product Owner is collocated with the team and even better is
mobbing with the team. However, we understand that this is not always possible
so we use the most face to face like communication method possible.
Q: Did you have to coach the business to have them working in a proper way with the programming team?
A: From an executive level we gained buy
in through our successes. We went from a team that released at best once every
6 months to daily or bi daily releases to production. We were also able to get
rid of our bug database because we no longer needed to track any bugs (fixed
immediately). For the product owner the most difficult thing to gain trust on
was the concept of #NoEstimates. This did take a dedicated presentation or
explanation of why we are practicing #NoEstimates and what the benefits are.
Q: Did you ask them to follow some specific rules
to communicate with the team?
A: We
asked them to communicate with us using the following structure:
- Favor Face to Face over Skype
- Favor Screen Share over Phone
- Favor Phone over Email
- Favor Email over waiting
Ultimately we go for the best possible fidelity in
communication as possible with our product owners but we make exceptions due to
the difficulty of colocation in certain situations. The proximity and the
frequency of communication with the product owner is communicated as a metric
when there are questions around decision making.
Q: What did the team do to have a great communication with the business?
A: The
short answer is massive amounts of transparency. We communicate out to anyone
who is interested the release frequency, progress, quality, team work feature
set etc.. of any project or team.
For the Mobs performance the primary metrics we use
currently are as follows:
- Time since last release to production
- Time since last retrospective
- Zero Bugs in production
We encourage the product owner to
re-prioritize each completed task in order to avoid working on stale work.
Hi,
ReplyDeleteI've got several questions regarding the organization that you would in place within the mob programming teams at Hunter.
1/
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?
What ressources inspired you to set-up this flat hierarchy model?
2/ 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?
3/
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 solultions are discussed and evaluated? I think I guess the answer, but I would like to hear that :)
Here is the reply! Thanks for the great questions! http://www.chrislucian.com/2016/11/mob-programming-flat-structure-and.html
Delete