Thank you very much for your guidance @tobiaseigen regarding Discourse for Teams. Also, those are awesome news @david! Managing outstanding work will be even easier now. I would love to use this post to tell you which where the killer features that made us switch to discourse.
Background
We are a team of software developers, functional analysts and sysadmins devoted to build business management solutions for the Colombian market, however, the whole world is in our roadmap ;). We build custom software for our customers and do have our own original products, but currently our main line of business is delivering services and extensions on top of Odoo ERP. Amongst all the applications that Odoo includes, we have specialized in the Accounting, Inventory and Human Resources management ones. As you might expect, we extensively use Odoo ourselves and since our inception in 2015, its Project Management application has been our best ally, which with its
Kanban interface (à la Trello) enables our team to manage the workflow of the agreed-upon tasks of each implementation project. However, a project implementation is just the beginning of the relationship with a customer company and it is in the maintenance period that things can become hairy if efficient management and front-facing communication is not provided. But Odoo has a Helpdesk application that you can use to manage a ticket-based communication with your software’s users through email and of course, again, we’ve been using it to deliver our support services. Quick answers to functional questions have been easy to manage through this tool, but when a convoluted bug report is received, there’s a separate document that must be generated to
aid in the development process. In these cases we have been using Gitlab and Github Issues and even custom version controlled restructuredtext files (parsed with Python in-house developed tools) to establish a vendor agnostic issue reporting format. In the end, we found ourselves in a position in which work to be done had to be searched in at least three different places, using
different interfaces and different workflows. Both external and internal communication to fulfill our daily activities was at jeopardy and that pushed us to look for alternative processes and tools, even if that implied fracturing our “Odoo centrism”. Discourse has been very famous as a forum software since many years ago, but we knew about its activities management features only very recently after performing some research. What moved us to try it were 3 things:
asynchronous communication, work definition homogenization and WIP control.
Asynchronous Communication
Discourse posts are just like email, but better. In a world of Whatsapp, Slack, Messenger, Mattermost, Odoo Chat and many others, we have grown accustomed to always be in “alert” mode. As everything seems to be urgent you are pushed to answer with short, quick and shallow responses. No time to think, no time to amend. Just write and send. Writing this post, for example, has taken me way more time than I would have anticipated, but I’m doing it after finishing other more pressing duties, so I can concentrate in giving my most sincere and elaborated feedback (the least I can do indeed for such a nice tool as Discourse). Writing a post is just like sending an email, but reading it is a whole different story. A much better one. Posts are centralized and shared between all the members of a team (or the authorized ones). They can be searched by their content or location (i.e. topics and categories) and even be accessible to external users or staff members which didn’t participate in the original conversation, which is great for storing the historical record of how decisions are made and what has been their context. Quick Note: Looking at how python.org embraced Discourse as their community management application, instead of mailing lists or other Python based solutions, shows that what we have here is truly outstanding in terms of suitability, performance and accessibility.
Work Definition Homogenization
This is the main reason why we are moving to Discourse. From the background given earlier you might have pictured a very colorful and intricate work setting. I certainly was a little too dramatic because we have effectively had documented processes and digital tools to manage our activities since our foundation. But what happened to us as time passed by is that we couldn’t manage to have a single representation of work inside the company. Yes, we had tasks for consultancy activities and tickets for support. Development was driven through plain-text documented requirements or the well known Git-related issues. It wasn’t a matter of lack, but on the contrary, of excess. There were too many sources of information and even inside a common application (e.g. Odoo) there were multiple formats of it (e.g Task, Ticket, Issue). Of course we could have decided on choosing any of the aforementioned instruments as our sole source of truth, but none of them provided us with one crucial element: integrated external feedback. With only one month of using Discourse we are finally feeling that we are connecting with the users of our products. There is not a distinction between them and us as we all use the same interface. However, we don’t have to render control on how we manage our work as some areas and capabilities can be restricted. But the best of all is that through Discourse’s Topics those same artifacts, which are akin to blog comments or helpdesk tickets, that we are using to understand our customers’ needs, can be used by us in private internal use categories to represent planned tasks to be done, issues to be attended or operational activities to be performed. For us, a topic has multiple synonyms, all of them valid depending on their context: Issue, Task, Ticket, Activity, Checklist, you name it. A homogenous shape of work which is open, approachable and centrally managed. I read that with Discourse for Teams you are planning to deliver a separate product, different from the discourse forum, or in other words, that Discourse (Forum) and Discourse for Teams are intended to be deployed as two different instances. I would recommend you to patiently think about it, because that design will inevitably fracture the currently provided integration between external and internal parties of an organization.
WIP Control
Finally, one of the best surprises that we’ve had through the use of Discourse is that we can finally establish a control over the work in progress in the organization. Because work to be done has all the same “shape”, it is easy to define policies to limit the amount of work that in any moment the organization should have. Through the Assign plugin, tasks are given a unique responsible who should look for help as needed (which is an ‘@’ afar) and then, using a unified interface (found at ‘/g/staff/assigned/everyone’) the amount of ongoing activities (i.e. WIP) in the whole system can be controlled. Right now, for example, we are iterating with a per person WIP of 5 tasks/topics/issues. As we are 14, that means that our maximum capacity as a team should be 70. This is very important for us because it aids in providing stability to one of the most difficult endeavors in life: estimation. According to Little’s Law (Little's law - Wikipedia) the long term average number of elements in a queue is equal to its average arrival rate or throughput, multiplied by the average waiting time that each of those elements stay in the system. So, with a 70 elements constrained WIP, if we receive 140 tickets per week, they will in average be completed in 0.5 weeks and it would have to be 0.33 weeks in average if we received 210. This assumes of course that the system is in a stable state and the backlog is not growing indefinitely so a proper calibration of the WIP must be conducted in an iterative manner. We still (and will always) have lesser amounts of types of work that won’t be able to be represented in Discourse, such as managing our email messages or our CRM pipeline, but as the majority of our work to be done has now a single shape as Discourse Topics implementing Kanban and Agile practices such as constraining the WIP will be much easier. That is why I would advise that if Discourse for Teams is intended to be a separate instance of Discourse Forum, it would be a shame not to have at a federated way to keep a centralized and compound view of the WIP in both systems.
Hope this post helps in improving Discourse as a communication and community building platform. Again, thanks a lot for it and wish you all the best!
displays search with “Search posts by @tobiaseigen” tickbox. It would make more sense to see “Search assigned to @tobiaseigen”.
