Author: Matthias K\u00fcnzi, visuellklar<\/p>\n
Transparency is essential for developing efficient and effective software and system solutions, or for managing demanding projects effectively. It is fundamental that all stakeholders understand the issues at hand, the risks, dependencies, and tasks involved. This presentation demonstrates how visual tools can restore this transparency. Participants will receive practical ideas, methods, and examples for making projects and system developments more visible, tangible, and comprehensible.<\/strong><\/p>\n What does visible work mean? It's about seeing the current state or status of a task or activity. In skilled trades and activities where tangible products are created, visibility is usually automatic. For example, a pastry chef making a tray full of tarts can see at a glance which steps have already been completed for each tart and where work is still needed (see...).\u00a0PDF<\/a>, Fig. 1)<\/p>\n But what does that look like in our environment? We tend to have more mentally demanding jobs. A lot of work has shifted from manual labor to knowledge work. For example, what is the status of the following code snippet? Is it finished? What's still missing? Which steps have already been completed?<\/p>\n (see.\u00a0PDF<\/a>, Fig. 2: Work that is not (or poorly) visible \u2013 programming a C++ class)<\/p>\n That's not so easy to answer. Even if we could take a closer look at the code and take the time to do so, it would still be very difficult to define the exact status of this artifact.<\/p>\n The following activities that arise in a software project are similar:<\/p>\n Just like a master baker, it's important for us as knowledge workers to know the progress of work on a project. Our work is interconnected. Results depend on one another. Therefore, it's crucial to know when something will be finished, or how long it will take to complete. In short \u2013 it's about planning.<\/p>\n In project work, risks, dependencies, and all project deliverables, such as documents, functions, use cases, requirements, etc., should also be made visible. Because, as Tom DeMarco says, "You can't control what you can't measure," it is essential to have control, i.e., an active means of steering, in project work. The following questions arise: What is the status of the work? What is finished, what is not yet? What is going well, what is not? Where do I, as project manager, need to intervene? Where are measures necessary?<\/p>\n What are the criteria for visible work? In other words, when is the status of a job transparent and visible?<\/p>\n Four criteria must be met.<\/p>\n In agile and lean environments, it's common to create Kanban boards to make work visible. Visualization is, after all, one of the general principles of Kanban. Below is a simple Kanban board with a visualization of work units (tasks):<\/p>\n (see.\u00a0PDF<\/a>, Fig. 3: Simple Kanban board to make work visible)<\/p>\n But is it enough to create a Kanban board and list each work item as a card (real or digital) in the "Todo", "In Progress" or "Done" column?<\/p>\n Let's look at the visibility criteria \u2013 and check whether they are met:<\/p>\n Regarding criterion 1:<\/strong> Regarding criterion 2:<\/strong> Regarding criterion 3:<\/strong> Regarding criterion 4:<\/strong> In summary, this means that simply adding cards for each task to a basic Kanban board is usually not enough to achieve sufficient visibility.<\/p>\n Improved visibility would be achieved through the following definitions\/measures:<\/p>\n It makes sense not only to talk about generalized tasks, but also about the specific artifacts to which the activities and work refer. This means, for example, that if the goal is to implement a use case, it should also be visualized as a tangible work unit. (See illustrations in the...)\u00a0PDF<\/a>)<\/p>\n Even more complex topics like architectural work are worth making visible, especially in larger systems, to achieve predictability, shared understanding, and thus effectiveness and efficiency. Through systematic architecture creation, the work unit here becomes an architecture driver to be considered within the architecture. (See figures in the...)\u00a0PDF<\/a>)<\/p>\n In summary, the following can be stated:<\/p>\n Matthias K\u00fcnzi (Dipl. El. Ing. HTL, Dipl. Software Ing. FH) has been working at Belimo AG since 2015. In his current role as Head of Software, he brings over 20 years of experience in the implementation of critical software systems in embedded environments. With his own company, "visuellklar," Matthias K\u00fcnzi advises and supports companies in addressing complex challenges in project and software development, primarily employing visual and agile methodologies.<\/p>\n Contact<\/strong><\/p>\n Download the article as a PDF<\/strong><\/a><\/p>\n Do you want to bring yourself up to date with the latest technology?<\/strong><\/p>\n Then find out more\u00a0here<\/strong>\u00a0<\/a>MircoConsult offers training courses\/seminars\/workshops and individual coaching on the topics of management \/ process, project and product management.<\/p>\n Training & coaching on the other topics in our portfolio can be found here.\u00a0here<\/a>.<\/strong><\/p>\n Valuable expertise in management \/ process, project and product management is available.\u00a0here<\/strong>\u00a0<\/a>Available for you to download free of charge.<\/p>\nVisible and invisible work<\/h2>\n
\n
Why is visibility important?<\/h3>\n
Criteria for visible work<\/h3>\n
\n
\n<\/strong>How can invisible work be made visible?<\/h2>\n\n
\nIs the type of work unit clearly defined? In my view, no. It's unclear whether all of this is implementation work. Or perhaps error analysis? Or troubleshooting? Or even documentation work? Of course, I can represent everything in a generalized way as tasks. But does that really give me the required visibility and therefore the ability to plan?<\/p>\n
\nIs the workflow known and defined? Yes. The workflow is "To Do" -> "In Progress" -> "Done". But is this really the right workflow that gives us enough visibility?<\/p>\n
\nIs the context known? A Kanban board alone probably isn't enough. Does the board show all the work of a project? From which team? In which sprint? In which sub-area? It's important to know the context or scope here.<\/p>\n
\nYes, the status of each work unit is visible in the workflow.<\/p>\n\n
\n\u201eTesting in Progress\u201c \u2013> \u201eReviewed\u201c \u2013> \u201eDone\u201c<\/li>\nExample: Achieving visibility of use cases to be implemented<\/h3>\n
\n
Example: Achieving visibility of software architecture work<\/h3>\n
\n
\nThis also clarifies and defines how the architectural design process should proceed.<\/li>\nSummary<\/h2>\n
\n
List of illustrations<\/h2>\n
\n
author<\/h2>\n
\n
\nManagement \u2013 our training & coaching<\/h2>\n
\nManagement \u2013 Expertise<\/h2>\n