Tuesday, January 30, 2018

Case Study: Advocates for Human Rights

Advocates and Wendy prioritizing user stories

Agile looks like people hunched over index cards.

Thank you Michele, Rosalyn, Sarah, Jinath, and the rest of the Advocates staff for your hospitality.


Last month, I had an opportunity to do some pro-bono work with the Advocates for Human Rights.

They KNEW there was a better way to run their internal operations and become more effective at executing their mission.

A few things impressed me about Advocates when I met them:

  • They were already effective with the resources they had.  They thought they could do better.
  • Their mission was VERY clear to everyone around the table.  And everyone around the table was passionate about that mission.
  • Their diagnosis as to what their issue was and what was most important to address was also very clear.  In multiple conversations, in multiple environments and across time, everyone said the same thing. I found that impressive.

Where they have been getting stuck is where most organizations get stuck – lots of ideas, uncertain about how to proceed, and limited time to execute on those ideas.


The Advocates staff are used to agility.  Their operating environment is incredibly dynamic, especially in today’s global climate.

They also had limited and unpredictable time availability for improving their internal operations.  Priority has to go to fulfilling the mission.  However, they also understood that they would be able to show greater value to their contributors if they tightened up their processes.

After getting to know them, I thought that an agile-style approach would work best for their volunteer database project.

An agile-like approach will accommodate their dynamic environment, created a system to deal with changing priorities, provided a way to track progress, and encouraged them to prioritize and focus their ideas for later execution.  It gives them a fighting chance at getting things done.

The team will be doing their own project management.  They clearly defined the roles each member of the team will play (Project Champion, Product Owner (plus subs), Subject Matter Experts). I was thrilled to see the level of ownership they are taking over this process.

Here’s what they are doing:

  • Sprints are in two -week cycles.  They let me know that they could more accurately predict time availability for two weeks and that is was a short enough time frame for accountability.  They also have staff meetings in 2-week cycles, so they already have time blocked out for internal operations that they can leverage for this effort.

 

  • We broke the user stories down into small enough chunks where they could define “done.”  As in – “is it done – yes/no.”  If they couldn’t get to a yes/no definition of done, I asked them to break the task down further.
    • Their user stories are classic -As a [user type] I want [activity] so I can [goal].
      • Example: Staff can see all volunteers who have completed training so I can assign them to volunteer opportunities.
      • Many of the stories they created are closer to –  [user type] can [activity].
        • This works too.  The business unit (Advocates) is running this project. As a result, they didn’t really need to specify the “goal.” They pretty much know why they want the functionality listed in the story.
    • Advocates will continue to work with the developer if they need help defining certain user stories and breaking them down into manageable pieces.

 

  • I put together a Kanban-style board for them using Trello.  Categories are:
    • Backlog – all new ideas go here
    • Prioritized – for an upcoming sprint.  This is where they determine the level of effort required for the item.
    • Next sprint – activities for the next sprint. They will re-evaluate the “next sprint” items before they move them to the current sprint to see if they have the time and bandwidth to execute on that sprint.
    • Current sprint – what they need to focus on this week
    • Ready for development – items that are ready to go to the volunteer developing their database
    • Ready for test – the volunteer moves the deliverable over to this column when it is ready
      • If the deliverable passes the acceptance criteria – it goes to Done
      • If the deliverable needs work – it goes back into the Backlog.  Advocates understood that any activity in the project would need some of their bandwidth.  The developer is going to guide them through the prioritization of any fixes and whether it can be dealt with immediately or should be re-prioritized.
    • Done – I told them to celebrate when things go to “done”.  Plus – it allows them to better see when they are making progress.
  • Advocates agreed to make their staff meeting day (also held every two weeks) their sprint planning day.  This way, they knew everyone would be in the office and if staffers outside the project team needed to make a decision, they were available.   Their sprint day agenda:
    • Work on deliverables for the current sprint to hand off to the developer (if they were not able to complete them prior to the meeting)
    • Confirm the status of items and update the board
    • Determine project team availability and capacity for the next 2-week cycle
    • Move the appropriate items to the current sprint
    • Make a high-level decision on “next sprint” – to be re-evaluated at the next sprint meeting. This includes backlog review.

At the end of the time we had together – they were excited to see a path forward.

Incredibly satisfying.


Please donate to the Advocates for Human Rights.

The mission of The Advocates for Human Rights is to implement international human rights standards to promote civil society and reinforce the rule of law. By involving volunteers in research, education, and advocacy, we build broad constituencies in the United States and select global communities.

No comments: