Getting things done...

More complicated than it looks, but Klaro can help!

Photo by Kolleen Gladden on Unsplash

Many project management tools shape organizing work around the key Done status.

Getting things Done

Maybe you've heard about it, read it in agile books, talked about it in conferences, or more recently seen it exemplified as the Holy Grail of project management in great marketing videos?

It seems simple enough but do you know, do we know, does anyone actually know what Done is supposed to mean? What does the Done status signify after all? Does your favorite tool help your team really to understand the definition of Done?

As the founder of Klaro, I created this software because I felt uncomfortable with the ways that existing project management software dealt with the notion of Done. As a team leader, agile coach, software engineer, or meeting facilitator, I frequently help others to understand what Done means. This happens so often that the subject clearly deserves a blog post.

It's all about making Done precise

"Gettings things Done" has to begin with clarifying what Done actually means:

Done means that results are visible to the outside world

Focussing on the outside world is very important. Very few individuals and teams work for themselves or use the results of their own work. Instead, in most cases, the work we do is to help others to meet their own goals. Let's call them your users. Focussing on and understanding your users and their goals is key in understanding what Done means in your project. Even when you do enjoy and use the results of your own work (when you are your own user) drawing a boundary between you "the worker" and you "the user" is very important.
Defining Done requires identifying clear domain-specific target states

Done means nothing by itself. In general, using Todo, Ongoing, Done as task statuses should therefore be avoided. Instead we need to listen to users and always look for terms that better capture the states that they would like eventually to reach: a car is washed, a book published, a document reviewed, an idea shared, a meal tasted, a physical design tested, and so on.

A few examples

Let's look at a few examples to illustrate the two points above.

When using a tool like Klaro to manage a blog,

Outside world: a blog post can hardly be considered "Done" unless an external reader can read it. It must therefore be made accessible on the Internet.
Target states: therefore, a "Done" blog post must certainly be "Published". Yet, it might also require being "Reviewed", "Illustrated" or even "Translated".

As another example, let's say you use Klaro to follow the development of software features (also called "user stories")

Outside world: a feature can hardly be "Done" unless an external stakeholder can use it.
Target states: therefore, the feature must certainly be "Deployed" (e.g. in production). It might also need to be "Tested" and "Documented".

As a last example, let's say you use Klaro to track small repairs in your house.

Outside world: this one is a bit trickier because you might have both roles: worker and user. You could use your partner, children, or friends as external users as a way to help you check that...
Target states: ...the enhancements you target are indeed "Repaired", "Fixed" or "Usable again". Maybe some of them need to be checked or reviewed by experts (e.g. electricity work)? Or documents need to be sent to your insurance company? The repair work cannot be considered Done until all these real-world requirements have also been done.

The devil is in the detail

If you are lucky enough to have a simple process then things proceed sequentially. For instance, a blog post is first an Idea, then Written, then Reviewed, then Illustrated, and eventually Published. Using a Kanban board makes a lot of sense in this case. Using one column per state, it is clear that ideas are those blog posts that need to be written, written blog posts are those to be reviewed, and so on. You might even refine the process for tracking states that take a little longer, e.g. Ongoing write, Under review.

If your process is not that simple, or should I say when your process starts becoming more complex, then your simple Kanban board won't scale. Here are a few typical reasons we have identified:

Lack of parallel steps

Things are rarely purely sequential; this is especially true when many people collaborate. In the blog example, maybe the Illustration and Review steps can both proceed as soon as the blog post is Written. A digital tool that enforces a sequence when the real world proceeds differently tends to be harmful: your Kanban and reality will quickly diverge, and unnecessary bottlenecks will appear.

No holistic support for requirements

A Kanban board helps a team to achieve a single high-level goal through a strategy that we call "by milestone". In our example: "Every blog post Idea shall eventually be Published" is the high-level goal; the strategy uses the Written, Reviewed, and Illustrated milestones.

In general, though, many high-level goals are in fact intertwined. A few examples:

Every English blog post with more than 50 likes must be eventually Translated to French and that translation Published.
Every blog post in Ongoing write state for more than 10 days must be either moved back to Idea, or marked Abandoned. That decision must be taken by the editorial team.
Ideas should be selected for writing based on an estimation of the blog post success.
Blog posts may not appear on the actual website without being marked Published and their publication date must be in the past.

Lack of support for separation of concerns

A naïve Kanban is very quickly overloaded with cards. Cards tend to accumulate in various columns, depending on the maturity of the underlying idea, on the effort needed to make the process move on, and on available people and also on their workloads.

When this happens, organisational decisions are needed, and a software solution that tracks processes needs to support enforcing those decisions by separating concerns:

Maybe the editorial team needs to choose what blog Ideas are worth being written. Then they need a board that shows only those cards to make editorial decisions.
Maybe the translator(s) would like to see only blog posts that need translations. And maybe she would like to track her own translation sub-processes.

Lack of support for priorities

Even if you separate different concerns, it is still normal to have too many cards and not enough people to work on them. It might seem like a good thing: having too much work might mean that you are successful. It may not be that great: having too much work might mean that you cannot focus on what's important. In both cases, you need to define fine-grained priorities:

The strategy to write blog posts should favor Ideas with high estimated success. They should be on top of the writers board.
Translators should translate blog posts frequently visited. They should be at the top of the translators board.
Blog posts might be illustrated with a first-in-first-out strategy. Alternatively a publication date might be set by the editorial team and used to prioritize which blog posts to illustrate.

How Klaro helps?

Our work on Klaro is driven by the analysis just outlined and by rich experience with various teams having non-trivial process requirements. Our roadmap covers many ideas to make team work more precise, more effective, and more automated. At the time of writing, this is the list of features that we already have:

Unlike many tools, Klaro does not limit processes to a single sequential Kanban. Our flexible support for dimensions means that many processes can be tracked at once, within the same project.
You choose your Done definition, and your target states. Done can be any conjuction of parallel sub-states to cover complex cases.
Klaro's dynamic boards strongly support separating concerns. Each board displays a subset of cards and is aimed at supporting one particular high-level goal or sub-goal. Create as many boards as needed; they automatically synchronize.
Workspaces allow different teams to collaborate on the same project without each team being overwhelmed by the cards they are not supposed to work on.
Each board can be fine-tuned to show specific cards and highlight the most important ones for a specific team. Your priority definitions may depend on states, on numbers, on dates. It's up to you to decide.
Changing your mind is easy. Because processes and teams evolve continuously, you can easily create and re-organize dimensions, cards, boards, workspaces, etc.

Is it really that simple?

Good question. At Klaro, we are working hard to provide simple software support for both simple and complex workflows.

Obviously, the more you can understand and simplify the process itself in the real world, the better you and your software support will be. That's always true. In that sense, Klaro is both a tool to get things done, and a tool that helps you to think precisely about your processes, with the main aim of keeping it simple.

At the same time, over-simplifying processes is harmful. At some point, the real world is intrinsically complex, and denying that complexity through naïve software support does not help. Our strategy to tackle that complexity is to invest in abstraction: we offer a few simple features, yet a lot of possibilities around them.

We hope this strategy is a winning one for all teams, and are open to be proved wrong: challenge us by sharing your complex team requirements and we will configure Klaro for you.