Human beings have two basic kinds of capabilities. One is knowing, including learning, making decisions, and planning. Making decisions and planning are based on using past experience to judge the future. The other capability is doing, including execution, action, and adjustment. That means following a plan, and then adjusting it according to both reality and perception.
The Scrum Guide says that three pillars uphold every implementation of empirical process control: transparency, inspection, and adaption. Inspection is pretty much about knowing. Adaption is pretty much about doing. Transparency is to unite inspection and adaption. It's the unity of knowing and doing.
From a team perspective, knowing comes in the form of consensus. Consensus means composing a team point of view out of different individual points of view. Consensus is involved in lots of Agile activities, such as pair programming, team planning, and collective code ownership.
From a team perspective, doing is in the form of flow. There are two level of flow: The base level is work flow. The key to make work flow is to identify and remove obstacles. The higher level is psychological flow. It's a state of mind, that you are fully committed to your work, forgetting time and other worries. We need flow in many Agile activities, including test-driven development, continuous integration, following team code standard, and task-pulling management.
Knowing is about planning, decisions, requirements, inspection, definition of done, goal setting, discipline, and a proactive mind. Doing is about execution, action, implementation, adaption, flow, competency development, and team synergy. In Scrum we can observe the unity of knowing and doing everywhere.
- Everyone unity of knowing and doing: Everyone is involved in the planning, and everyone is involved in the execution.
- Any time unity of knowing and doing: The plan is made at any time, and execution occurs at any time.
- Team unity of knowing and doing: The team makes decision, and the team executes it.
- Agile unity of knowing and doing: The team makes decisions quickly and acts quickly.
- Requirement unity of knowing and doing: Developers work closely with the customer and master the real requirements.
- Pillar unity of knowing and doing: Inspection is to know, and adaption is to do.
- Done unity of knowing and doing: Define definition of done, and reach consensus on Sprint goal.
- Transparency unity of knowing and doing: Transparency makes the process flow well.
- Discipline unity of knowing and doing: Self-discipline helps build individual and team capability.
- Virtue unity of knowing and doing: Be proactive, and synergize.
In a summary, unity of knowing and doing is a state of mind that's well prepared for ready-ready and done-done. Consensus is how the team understands the world, the project, the situation, and themselves. Flow is the way to make things happen in a time line.
Finally, Agile involves trusting people. People, by nature, have the ability to know and do well.
My team and my organization have just transferred from old way of working to the Agile method. Below I'll describe some of my observations of the transition, in hopes that this will help teams who feel the pain of old ways of working and look forward to adopting Agile.
In the old way, plans and decisions are made by the project manager, and requirement and analysis are done by architects. What can the team do? It can only do implementation, such as low-level design, coding, and testing. Tasks are assigned without full involvement of team. It's a separation of knowing and doing. Under such a way of working, people can't see the big picture, have less opportunity for personal development, and can't feel achievement and growth. They aren't engaged.
Under Agile, the plan is made by team. Decisions are made by the team. The ScrumMaster is only a facilitator. The product owner can only define what to do. The team has the authority to decide how to do it. That's unity of knowing and doing, when the team's potential is fully released, they can see the big picture, they can volunteer for tasks that interest them (which helps their personal development), and they can feel a sense of achievement from their day-to-day decision making and implementation.
After some time of working in this way, the team becomes proactive and synergized. I've been part of teams that share knowledge as part of team competency development. They set up a word of the day and a story of the week as a way to learn English together. They set up team lunch meetings to forge better personal connections with each other. They create fun and unusual methods at meetings, such as using pictures in a retrospective meeting instead of just talking. All this has happened on the team's initiative, without any manager's command and control. This change from pushing a team to having the team pull themselves forward is part of the Agile culture, and it manifests itself in the planning meetings, daily stand-ups, and definition of sprint goals.
For us, gone are the days of a strictly phased program process, in which every phase must be approved before we can enter next. There are no separated design phases. We do analysis, design, code, and test for each user story. After each sprint, we create a product increment. People are more confident about product quality and customers show an interest in product increments. We can handle change easily. Knowing (requirement) and doing (implementation) are closely aligned.
I must point out that senior leaders are very important in the transformation to Agile. They must set the stage and remove organizational-level obstacles. They must have confidence in Agile — and once that's achieved, it's not difficult for the whole organization to transform.
In the old way, the leaders handled the knowing and followers the doing. There was a gap. Now, everyone is about knowing and doing. This is the key to transformation to an Agile culture.