OKI Agile: Scrum and sprints in open data

This is the third in a series of blogs on how we are using the Agile methodology at Open Knowledge International. Originating from software development, the Agile manifesto describes a set of principles that prioritise agility in work processes: for example through continuous development, self-organised teams with frequent interactions and quick responses to change (http://agilemanifesto.org). In this blogging series we go into the different ways Agile can be used to work better in teams and to create more efficiency in how to deliver projects. The first posts dealt with user stories and methodologies: this time we go into using scrum and sprints to manage delivery of projects.

Throughout my time as a project manager of open data projects in The Public Knowledge Workshop in Israel and in Open Knowledge International, I have used various tools and methods to manage delivery of software and content development. I have used Trello, Asana and even a Google spreadsheet, but at the end of the day I am always going back to Github to run all of the project tasks, assisted by Waffle.

Many people that I spoke to are afraid of using GitHub for project management. To be fair, I am still afraid of Git, but GitHub is a different concept: It is not a code language, it is a repo site, and it has got really good functions and a very friendly user interface to use for it. So do not fear the Octocat!

Why Github?

• As an organisation facing products, our code is always managed on Github. Adding another platform to deal with non-code tasks just adding more complications and syncing.
• It is open to the community to contribute and see the progress and does not need permissions management (like Trello).
• Unlike what people think – it is really easy to learn how to use Github web version, and it’s labels and milestones feature are helpful for delivery.

Why Waffle?

• It syncs with Github and allows to show the tasks as Kanban.  
• It allows to write estimates that hours of work for each task.

So far, working on Github for the project showed the following:

1. Better cooperation between different streams of work
   Having one platform helps the team to understand what each function in the project is doing.  I believe that the coder should understand the content strategy and the community lead should understand the technical constraints while working on a project  It gives back better feedback and ideas for improving the product.
2. Better documentation
   Having all in one place allows to create better documentation for the future.

So what did we do for GODI (the Global Open Data index) 2016?

• Firstly, I have gathered all the tasks from the Trello and moved it to the Github.
• I created tags that allow to differentiate between different types of tasks – content, design, code and community.
• I added milestones and sorted out all tasks to fit their respective milestones of the project. I also created a “backlog” for all tasks that are not prioritise for the project but need to be done one day in the future. Each milestone got a deadline that responds to the project general deadlines.
• I made sure that all the team members are part of the repository.
• I organised Waffle to create columns – we use the default Waffle ones: Backlog, Ready, In Progress and Done.

Using one system and changing the work culture means that I needed to be strict on how the team communicates. It is sometimes unpleasant and needed me to be the “bad cop” but it is a crucial part of the process of enforcing a new way of working.  It means repetitive reminders to document issues on the issue tracker, ignoring issues that are not on GitHub and commenting on the Github when issues are not well documented.

Now, after all is in one system, we can move to the daily management of tasks.

Sprints

• Before the sprint call
  • Make sure all issues are clear –  Before each sprint, the scrum master (in this case, also the project manager), make sure that all issues are clear and not vague. The SM will also add tasks that they think are needed to this sprint.
  • Organise issues – In this stage, prior to the sprint call, use the Waffle to move tasks to represent where you as a project manager think they are currently.
• During the sprint call:
  • Explain to the team the main details about the sprint:  
    • Length of the milestone or how many weeks this milestone will take
    • Length of the sprint
    • Team members – who are they? Are they working part time or not?
    • Objectives for the sprint these derive from the milestone
    • Potential risks and mitigation

• • Go through the issues: yes, you did it before, but going through the issues with the team helps you as PM or SM to understand where the team is, what blocks them and creates a true representation of the tasks for the delivery team.
  • Give time estimates – Waffle allows to give rough time estimates between 1-100 hours. Use it to forecast work for the project.
  • Create new tasks – speaking together gets the creative juices going. This will lead to creation of new issues. This is a good thing. Make sure they are labeled correctly.
  • Make sure that everyone understand their tasks: In the last 10 minutes of the sprint, repeat the division of work and who is doing what.

• After the sprint call and during the sprint:
  • Make sure to have regular stand ups –  I have 30 minute stand ups, to allow the team to have more time to share issues. However, make sure not to have more than 30 minutes. If an issue demands more time to discuss, this means it needs its own dedicated call to untangle it, so set a call with the relevant team members for that issue.
  • Create issues as they arise – Don’t wait for the stand up or sprint kick-off call to create issues. Encourage the team and the community to create issues as well.
  • Always have a look at the issue tracker – Making sure all issues are there is a key action in agile work. I start everyday with checking the issues to make sure that I don’t miss critical work.
  • Hyper communicate – Since we are a remote team, it is best to repeat a message than not say it at all. I use Slack to make sure that the team knows that a new issue arise or if there is an outside blocker. I will repeat it on the team stand ups to make sure all team members are up-to-date.

How do you manage you sprints and projects? Leave us a comment below!