在看板方法中第一步需要将一个团队的实际工作流程可视化。这是实现精益的“看到全貌”原则和需要看到实际的工作流程，而不是用文档来描述一个理想的版本或者使用其他什么模型来描述工作过程。一个有用的可视化模型表达了什么将会实际发生。
一旦可视化的工作存在，工作过程就可以用它来追踪。一个典型的入口（stage-gated），或瀑布模型，开发过程可以被在过程中使用如下几个特征所展示。
Scrum团队已经使用多年的可视化工作流程来展示Sprint的工作。在Scrum开发团队中最常见的可视化工作流程形式是Scrum的“任务板”或简单的“Scrum Board”。这种可视化模型使用起来比上述的模型简单，并且看上去也符合下面的模型。
这种典型的工作流可视化的形式受到Scrum跨功能开发团队规则的强烈影响。关注跨职能开发团队是Scrum框架的一个定义特性。跨职能团队拥有在每一个Sprint迭代中交付完整的可工作的软件增量所需要的所有开发能力。团队成员同时进行多项软件开发活动。
跨职能团队可以一起做一些事情，因为他们一起实现一个功能。这是与计划驱动的模型有很大的差别的，其中专家专注于在一次做所有的活动。此外，跨职能团队的成员可能有专业特点，但所有团队成员为交付所需要的软件而在一起执行常规的工作活动，无论这些活动是否属于个人的专业领域。跨职能的软件开发团队倾向于表现突出的专家团队。
开发团队正在交付增量的工作软件，但团队成员的协同工作并不好。程序员在把代码交付给测试人员之前他们孤立的工作，而这些测试人员必须在Sprint结束之前完成所有的测试。
这样在Sprint结束的时候就不会有太多时间进行测试，所以开发团队有时会跳过这一点，并通过不完全回归测试以后交付增量。这样做导致在产品交付后发现了缺陷，而这些缺陷本应该在功能性回归测试中就已经被发现。
Scrum Master与开发团队一起工作，模拟在每个Sprint过程中发生的实际工作流程。尽管团队在每日站立会议上使用一个典型的任务版，但是很快就发现实际工作流程是一个阶段性的过程。团队创建以下模型来反映它的真实工作流：
Scrum Master帮助团队理解通过跨职能工作所获得的生产率的潜在增加。虽然不确定，团队成员同意尝试改善他们的工作流程，以便于能够更加以跨职能的方式来工作。
开发团队保留可视化完整，并使用它在Sprint中来控制工作，并寻找每一个可能合并工作阶段的机会。也就是说，团队寻找机会，其中两个阶段可以合并成为一个阶段，从而替换合作过程中的工作切换。他们通过深思熟虑考虑开发团队中的个人如何在团队中进行合作而一步一步的做出改变。在每一次Sprint回顾中，他们重新修改模型以反映团队的改进措施。
首先，Arnie和Kyle同意将设计和编码阶段进行合并。他们尝试了几种技术来提高协作，并很快了解他们的工作流程已经改变到以下：
这个开发团队很快就学会了在代码开发之前从失败的功能性回归测试开发代码，这导致了以下的变化：
在接下来的几个月中，开发团队寻求机会来减少交付阶段的数量。团队文化实际上随着专家共享知识而改变，每个人都在努力帮助团队更顺畅地工作。团队成员开始考虑自己的“专业通才”特点，于是团队成员之间出现了更多的合作。
随着团队协作的增加，对所创建的软件的集体知识和团队成员对彼此职责的理解也随之增加。这种自然的合作在Sprint中减少了工作过程阶段，这在Sprint迭代中表现为一个简单的可视化的工作流程中。现在开发团队是一种跨职能的团队，并且其实际的工作流程如下所示。
团队对消除过程阶段的迭代思考最终导致了在Scrum流程中执行的第一步工作，一个正在进行的开发阶段。这显示了一个完全优化的看板最终如何表现为一个传统的Scrum看板。
连载（六）