Job Opening: Principal Software Engineer - Mob (US, CAN, MX)
Hunter Industries Careers

Mob Programming Q&A: Product Owners

Mob Programming Q&A: Product Owners

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?


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.
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.
                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

 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?

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.
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.


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:
  1. Time since last release to production
  2. Time since last retrospective
  3. Zero Bugs in production

We encourage the product owner to re-prioritize each completed task in order to avoid working on stale work.


 We encourage the product owner to re-prioritize each completed task in order to avoid working on stale work.       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        I believe you can reach this result through retrospectives about product owner interactions.



I believe you can reach this result through retrospectives about product owner interactions. If you are transparent in decision making but have someone responsible for setting Kanban priority, then you will be able to practice continuous delivery well. Good continuous delivery will lead to great customer feedback which can feed into your future decisions. Keeping good metrics about product use can speak to value of product owner decisions which can lead to great discussions about priority that the product owner can then use to prevent themselves from making siloed decisions. In turn this all comes together to facilitate building great products.

2 comments:

  1. Hi,

    I'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 :)





    ReplyDelete
    Replies
    1. Here is the reply! Thanks for the great questions! http://www.chrislucian.com/2016/11/mob-programming-flat-structure-and.html

      Delete

 

Follow