Jump to content

Wikimedia Product/Inclusive Product Development/program management resources

From mediawiki.org

This page contains resources suggested by program management.

DACI

[edit]

This decision-making framework is represented in a chart.

Types of decisions are represented as rows

[edit]

Examples include:

  • determine technical approach
  • define acceptance criteria
  • maintain testing infrastructure
  • conduct user research

Different disciplines are represented as columns

[edit]

On a cross-function team, this might include:

  • Product Manager
  • Designer
  • Technical Program Manager
  • Data Analyst
  • QA
  • Community Relations Specialist
  • Engineering Manager

Each cell represents the 4 distinct DACI roles

[edit]

Driver, Approver, Consulted, Informed for that decision in which:

  • Driver = who will ensure that the decision is enacted (a single person)
  • Approver = who owns the decision (a single person)
  • Consulted = might have information that could help inform a decision but no veto power (could be a few people) Please note that Consulted comes from RACI and in the Wikipedia definition of DACI that the C= contributors, or the people who do the work.
  • Informed = anyone affected by the decision or has an interest in the decision (could be many people)

RACI vs DACI

[edit]

Note: Sometimes, there is confusion on when to use RACI vs. DACI. Both of the tools are useful for making sure that everyone knows who participates in finishing an activity and who makes a decision about a particular topic. However, in order to decide when to use RACI or DACI, you should be asking yourself the questions below:

  • RACI: Who is responsible for completing certain tasks?
  • DACI: Who decides on a course of action for a particular task or function?

Depending on whether the issue is one for responsibility or decision making, it will inform you what tool to use.

How to run a retrospective

[edit]

The Agile Manifesto is based on 12 principles.  One of them is: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”  

Most feature teams work in two week intervals and convene retrospectives every 2 weeks.  Some teams only hold retrospectives once a month.

The point is to learn by inspecting and then adapting to highlight what is working and what is not.

[edit]

By putting Stop at the beginning of the sequence, the discussion starts with what is not working.  Some teams can be shy when it comes to identifying problems.  So the position in the sequence can help spark discussion.  Because Agile favors learning, knowing that something does not work is valuable information.

By ending with Continue, the discussion can end on a high note that we might miss if we ended with a discussion of what to Stop.

Some good practices are:

  • Ask participants to write their responses to Stop, Start, Continue prompts ahead of time with each point starting with their initials
    • Example, Start: GG : threading messages in our team Slack channel
    • This approach helps introverts
    • Also, when we write something down, we commit to it
  • In the Retrospective, the facilitator says, “1-2-3 paste!”
    • This is intended to reduce the self-censorship that can come from seeing others’ responses before adding our own
    • It is useful to know how many people felt the same way - something we’d miss if we didn’t copy our own content in because we saw that somebody else already mentioned it
    • It’s also useful to identify the outliers
    • This approach distributes the notetaking responsibility :)
  • Participants paste their responses to each of the Stop/Start/Continue prompts into the notes doc
  • Once all responses are in the doc, the group can self-organize to cluster responses into themes
  • Then they can decide which themes to discuss during the synchronous meeting time
  • Finally, the group commits to which actions they’ll take as a result of the discussion of themes

When there is a concern that a retrospective could become contentious, that retrospective could use this modified format:

[edit]
  • The facilitator sends a Google Form with Stop/Start/Continue sections to participants ahead of time
  • Configure the Form to collect email addresses
  • Inform participants that the Form will collect their email address as a means to track who has submitted content
  • Encourage them to be as candid as they feel comfortable while still being respectful to their colleagues
    • Do not share any raw attributed responses
  • The facilitator reviews the content submitted and synthesizes the concerns into themes
    • Note how many responses feed into a given theme.  For example, “8 people expressed a concern about norms”
  • Before the meeting, the facilitator informs participants of the themes that will be discussed in the retrospective
  • This method allows participants to let their thoughts out which can be cathartic
    • Knowing how many other participants share the same concerns can make people feel heard
Retrieved from "https://www.mediawiki.org/w/index.php?title=Wikimedia_Product/Inclusive_Product_Development/program_management_resources&oldid=5198501"