Introducing Weekly Updates for a Transparent Future
We are putting in a lot of hours in the background, working on many areas. This includes integrating community feedback, as well developing our own ideas and partnerships. However, we have realised this work is going unnoticed. This is mainly due to us not fully sharing our internal process. This is why our announcements are typically tied to ‘major’ events. This also explains the large gaps between you hearing from us. This is where “Changelogs” come into play.
As part of the new phase related to the website launch we are going to change how and when we announce work. This approach also aligns to the aspect of Integrity that is a key theme for us.
So, what follows is the process that we are developing and using internally. Mostly, how we will use this process itself to provide weekly announcements. That way we can shine a light on what we worked on in the previous week and our progress.
Our hope is that this will also give you the ability to provide feedback in a timely way that can shape how and what we are doing.
To start with we would also like to give you a short explanation on the method we are using.
We are developing a scrum/kanban methodology which is an effective way of improving our alignment, communication and performance across a number of tasks. To support this we are using a number of Trello boards which provides us with an overview of all the assignments to be completed. The boards are divided into sets of monthly objectives. We link these objectives to project areas, as well as weekly “sprint” boards.
The weekly sprint boards are currently defined as a week of work, which has measurable objectives that are defined in a discrete set of “user stories”.
Whilst our exact process is still developing, in general what happens is that every monday morning, a “product owner” responsible for a sprint board, has some prepared stories and their objectives. We collate these stories from monthly Scrum boards.
Story difficulty is rated through the fibonacci scale (1, 2, 3, 5, 8, 13 to 21). We are using this approach as research finds that we work better through relative rather than absolute sizing (Just this approach itself deserves a separate post which we may do in the future if there is an interest).
The more difficult a user story is, the higher the number given to the story. If the size of the story exceeds the amount possible in that week long sprint, we break the story down into smaller stories. Using a story approach leads to a cross-functional team view as it focuses on the end user benefit rather than the functional tasks.
Relevant team members do a scrum meeting with the product owner for a maximum of one hour. During the meeting they go through the stories and break these down into tasks. The team then collectively works on identifying the tasks that need to be completed.
We work with a Kanban-style method to work on each task, with just five lists:
- Backlog — Shows all items to be done during the week.
- Doing — Shows items that are currently being completed
- Blocked — Tells the entire team which objectives can not be completed and why
- QA — Peer review to make sure quality/success levels have been met
- Done — The objectives that have been successfully completed
Every weekday, we are holding a sprint stand-up. We are working towards keeping this to just 15 minutes (we still have so drift around this that we are working on!). Keeping the meeting short means that everyone who should attend does so, because they know that it is only 15 minutes of their time. This lets us pick up on blockages quickly and resolve them faster. Finally, everyone can see a cohesive view of what exactly is happening.
This stand-up is only for those involved with the current sprint and responsible for completing stories. It is a short timeframe where they will be able to communicate on what work they have done since the previous day, what their focus for the current day is and whether or not there are any blockers.
We develop a sprint retrospective on Friday afternoon. This serves to provide feedback and/or suggesting improvements for the ensueing sprint.
The sprint method ensures everybody knows exactly what needs to be done. After having taken on a task, the responsible person can execute his task in whichever way he deems appropriate. The only requisite is that it aligns to the overarching story. It must add benefit to an end user in a verifiable manner.
Breaking down the stories makes sure we do not get too overflowed by work assignments. Furthermore, it ensures a steady, continuous flow of visible progress. Simultaneously, this visible flow of progress is motivational for us as well. This method also prevents large stacks of assignments piling up at any given time.
Obviously, our work has been going on for some time now and some key partners are helping us. So, to kick off, we would also like to introduce our current partners that are contributing to us navigate through this next phase and give a small explanation on the areas they have been working on with us. We will provide follow up posts that provide more information later.
ODIN Blockchain Core Team
To reiterate one major benefit of this method is being able to present our progress in a concise manner each week. We will explain our progress made over the past week. The purpose of this is to provide our community with at least some insights to the inner workings and progress from the Foundation’s perspective.
Also, we are looking at the possibility of making monthly “mini-roadmaps”. You can contribute to these through suggestions and pitch ideas. In this manner, you can ensure your community involvement.
We aim to have these updates and progress reports published every Monday. Following that, we will announce and link to them on release.
We look forward to sharing our progress with you. Most of all, we hope you keep pushing your ideas for improvements and fresh ideas onto our social media channels:
Discord, Telegram, Reddit and Twitter.