Off the Traditional Workflow
why Agile alone is not enough
Over the past few years, most Start-ups have been introducing Agile to their workflow. Agile which aim for making a high-efficiency performance through pressuring from short sprints is one of the workflow methodologies. Pluto team also had aggressively applied it using Kanban which is a tool of Agile workflow during the initial development of Scinapse. In Kanban-based workflow, tasks are visualized to give the team a view of progress and process, from start to finish — usually via a Kanban board. Kanban-based workflow had worked well until we made the basic feature of the academic search engine. But when we had tried to build up new features onto Scinapse for moving next step, we had started to feel something wrong.
The workflow using Kanban only concentrates on quickly completing individual tasks and delivering them to users(or our goals). There are only tasks within this workflow, but there are no understandings of why tasks are needed or the objectives of tasks. That is, this was just ‘work’, not ‘workflow’ to us. Certainly, it could help improve individual productivity, but simply completing meaningless tasks do not help us achieve our goals. Another problem with this workflow was that we were stuck with a microscopic viewpoint. Therefore, we needed a new workflow that allowed us to accurately recognize our goals and to make various attempts. Of course, it should include our team culture.
There are roughly three types of workflow that we had tried. These are Kanban, Task Force(TF), and Focus. As mentioned above, we first had used Kanban, the most popular workflow tool. But after we encountered the problem with using Kanban, we implemented new workflows based on TFs and Focuses. Now, let’s take a closer look at TF-based workflow and Focus-based workflow.
The Workflow based on Task Force
The biggest problem of Kanban-based workflow was that it was difficult to think deeply about our goals. We thought that a new workflow focusing on establishing and verifying hypotheses could solve this problem, and TF came out.
In general, TF is defined as “a unit or formation that is established to work on a single defined task or activity(project)”, and is one of the ways in which large organizations are operated. Using this concept, we had redefined TF as a unit of a project to verify one hypothesis and had made a new workflow based on that definition.
Briefly introducing the TF-based workflow, it is the process that some team member(units) who empathized on a hypothesis(unit of a project) come together and verify it. The purpose of this workflow is to verify a hypothesis so as to identify whether that hypothesis should be true or false. In case of a correct (or maybe well-stated) hypothesis, it will be possible to help us reach our goals, and if not, we could modify the hypothesis and make a new TF based on what is learned. Therefore, TF-based workflow leads us to make trials and errors for reaching our goals.
TF-based workflow which uses Hypothesis-Verification model can help us quickly verify hypotheses and actively use results to flexibly determine the direction of our project. We can also stay focused on our goals with this workflow.
The process of TF-based workflow
1. Hypothesis(Idea) suggestion
- Anyone can suggest ideas at any time in Idea board.
- It should be documented: Idea documentation should clarify what is being verified through this hypothesis, specify resources(e.g. the expected duration of the TF) and acceptance criteria(i.e. upon which we can assure that the hypothesis is verified).
- The hypothesis should correspond to the OKR(Objectives and Key Results)
2. Performance
- Based on one hypothesis in Idea board, organizing a TF. Anyone who agrees with the idea can engage in the TF.
- The tasks for verifying the hypothesis are conducted under the TF.
3. Check
- Check progress based on idea documentation in the weekly sprint meeting.
- The history of the verified TFs should be kept well.
Problems with TF-based workflow
This TF-based workflow helped us suggest diverse ideas and lead to new attempts, but it had side effects as well. We were trying out a lot of ideas as we were free to test new hypotheses without any constraint, but only few TFs had been completed. And with a lot of TFs being initiated, we had lost our focus and momentum on our goals.
We realized that we should be focusing on “making results and learning” rather than simply “trying a lot”. We wanted the direction of the workflow to be:
— Learning from a few attempts (but not Trying as many as we can)
— Concentrating a few tasks (but not Doing various tasks at once)
— Separating into short projects (but not Operating as single, long-term project)
Therefore we needed yet another workflow that could divide large-size projects into small unit projects for continuously making results. With this background, we made Focus-based workflow which adds some constraints while maintaining the advantages of TF-based workflow.
The Workflow based on Focus
Focus is the unit of a project that attempts an idea based on the agreed goal, instead of the existing TF. This Focus-based workflow focuses on finishing attempts(project) and making the results, while it maintains the advantages of TF-based workflow that verifies a variety of hypotheses. Focus-based workflow has the following basic rules:
1. Get Things Done, and Learn
2. Members can engage in a maximum of 2 Focuses at the same time
3. Share what you’ve learned from the Focus on every Sprint Meeting
The process of Focus-based workflow
- List ideas that fit our goals. (In TF-based workflow, we randomly generated TFs based on Idea board) Set priorities among ideas listed. When selecting a priority, we consider several factors such as the relationship with the goal and how much resources are needed.
- Have kick-off meetings for ideas selected based on the priorities. The purpose of these meetings is to refine and to subdivide ideas. An idea that went through this process becomes a Focus, a project unit.
- Focus can consist of team members who agree with the idea, like TF-based workflow, or a single member can work on alone. The tasks are managed by the team members who are in the Focus, and the progress and results must be clearly documented. And members who are not involved in the Focus can also give a hand if they receive any request.
In summary, TF is the unit of a project based on large hypotheses (ideas). For example, “improving the Collection feature in Scinapse” becomes a TF. But in Focus-based workflow, Focus is the unit of a project based on small-sized ideas. For example, if “improving the Collection feature in Scinapse” is the goal of the month, “adding a Memo feature to Collection” becomes a Focus. In other words, the advantage of Focus-based workflow compared to TF-based workflow is that it makes a series of short attempts and leads to results within the monthly cycle based on our goal. Another difference is that there are following constraints:
- A member must not engage in more than two Focuses at the same time.
Focus has the meaning “I’m focusing all my resources on this project to make a result.” - A Focus must be completed within a maximum of 2 weeks.
If starting with a big idea, that idea has to be cut into projects that can be completed in 2 weeks. If a Focus is not completed within 2 weeks, finish with getting minimal results and continue with a new Focus. - Once started, a Focus must be shared to the whole team in Sprint Meetings with the progress and what’s learned through this Focus. This is different from TF-based workflow where we simply checked only the progress.
Through this Focus-based workflow,
- We could clearly recognize our goals, and this leads us to make meaningful attempts.
- We are growing together by making results from Focuses and sharing it with our team.
We are currently applying this workflow using a workspace tool called Notion. Our Notion space has been customized to effectively manage and monitor Focuses and individual Tasks. That means, the advantage of visualization in Kanban-based workflow is also included in our Focus-based workflow. We might probably introduce how we’re using Notion for our workflow with another post.
