Helpful lessons from Scrum and XP

Scrum has taught us a lot. It is a very good framework or approach. Here are some good lessons from Scrum.

• Cross-functional teams are good. A team that has all of the capability required to create a product. Feature teams are better structures than component teams because you don’t have to try to tie components together.
• Improve collaboration. Cross-functional teams improve collaboration with teams. Consistent cadence helps teams to collaborate and coordinate with each other.
• Eliminate waste. Reducing delays in communication reduces the waste of waiting and decreases cycle time. Frequent feedback reduces miscommunication and defects and the delay of realizing value quickly.
• Cadence coordinates different roles. Product Owners know when they need to have backlogs ready for the team. Teams are able to stay in sync. This reduces waste caused by dependencies.
• Iterations create discipline. Two-week time-boxed iterations automatically focuses people on the work at hand.
• Short-term planning can be accurate. It is much easier to predict what is needed in the near term than far away.

XP has also taught us a lot about good Agile practices. For example:

• Test-first and automated testing results in long-term high quality, maintainable code.
• Continuous integration is important.
• Small stories are important.
• Collaboration is critical.
• Shared understanding of Agility is critical.

Scrum and XP work as well as they do because they are founded Lean principles, even if that is not always recognized. For example, the cross-functional teams within Scrum help to manifest several Lean principles and eliminate waste.

• Cross-functional teams help to minimize partially-done work because the people who are needed are available when they are needed. There is no need to wait on them.
• They reduce the amount of paperwork required for communication and handoffs. In fact, there are many fewer hand-offs.
• By incrementally building and releasing, the team is less likely to be building extra features that are not required. The Product Owner and the team communicate quickly about what is being done and can stop anything that is not needed, that is not going to produce Business value.
• There is less task-switching. The team focuses on finishing work before going on to the next thing.
• They make Acceptance Test-Driven Development and Test-Driven Development easier because developers and testers and analysts are all part of the team.
• Defects are more likely to be caught because the team is building in small increments. There is a shorter cycle between when a defect is created and when it is fixed.

As shown in the figure, cross-functional teams make cross-team, cross-tribe collaboration more effective. When people are organized simply according to function (as shown on the left), they primary interests and relationships are with their peers within their function (UI, mid-tier, database, etc.); communication with other functions (“tribes”) requires crossing significant boundaries. Putting people into cross-functional teams creates different loyalties and social relationships. For example, a UI person will naturally be motivated to work with their teammates; at the same time, since they are still part of the UI community, sharing ideas with other UI professionals will still go on.

Lessons learned: The challenges with Scrum

While good in theory, some of the challenges with Scrum and XP come when they encounter the real world. For example,

• It is not always possible to form teams.
• The roles are unfamiliar.
• There is too much changed demanded right away.
• Management is not included.
• IT environments and product environments with heavy maintenance costs could not accommodate the flexibility demanded.

A primary hurdle for XP is that it has a very high bar for adoption. Few teams will move forward with XP even though its practices are good. It demands a high degree of alignment with its approach in order to work. In practice, this has proven hard to do especially at scale.

One of the weaknesses of Scrum is that it does not provide teams with principles that could guide them when they are faced with the real world. Teams and leaders are left on their own to try to figure out how and what to adjust in order to meet their situation. Without guidance, Scrum becomes a prescription or leaves people to flail about. As Deming says, “Theory without experience is useless. Experience without theory is expensive.”

Kanban can help

Kanban has helped in cases where flow is important. It offers some significant practices (which are also founded on lean):

• It has an intense focus on improving the flow of work lowers delay. While Scrum is somewhat of a “black box” in its workflow (belonging to the team), kanban makes work processes and workflow extremely visible. Improvement in flow comes from intentional looking at processes and delays.
• Management is a key member of the process.
• Kanban offers ways to manage projects without having to form cross-functional teams.
• The transition to kanban is much less intense. It starts where you are and gradually improves based on observe and adapt process improvements.

Like Scrum and XP, kanban is also not sufficient. There are assumptions and gaps when it is taken by itself. And that means we will miss other opportunities for improvement. For example, the pull method of kanban is not the only or best approach. Lean says, “Flow when you can; pull when you must.” Focusing on flow also requires improving the ecosystem.

Here are some comparisons between Scrum and kanban.

Scrum	Kanban
Organize in cross-functional teams.	Use your current team organization. Team structure is orthogonal to kanban.
Create new roles: Product Owner, Team Agility Coach, tea m	Use existing roles
Just jump to Scrum and consider any impediments you face as issues to remove.	Start where you are. Avoid making eco-system changes until after a kanban system has been put into place.
Use time-boxed sprints for planning and guidance to finish things quickly.	Do not have sprints nor plan work ahead besides creating a product backlog.
Estimate work and use velocity based on estimates and work done to assist planning.	Do not estimate; it is wasteful activity/
Create visibility of work going into and out of sprint as well as status of work being done; but, don’t explain workflow rules.	Make all work visible to management including work status and workflow agreements.
Have learning retrospections at the end of every sprint.	Have explicit workflow policies that enable the use of kaizen to improve flow on a daily basis.
Teams coached by a Team Agility Coach with no authority over them.	Teams use existing team leadership approaches in place prior to kanban.

Missing elements

Each of these methods, when followed too closely, tend to preclude other good practices. Thus, Scrum tends to preclude flow, explicit policies, and excluding management (it doesn’t have to, but it often does). Kanban tends to preclude teams (it doesn’t have to, but it often does).

In addition, these methods are missing important insights in transition management, learning theory, and double-loop learning. Transition management is a multi-dimensional journey. It occurs both in social architecture and operating architecture and across leadership, management, and team. People learn in stages; you provide the roadmaps to give them the options they can handle as they move forward.

Double-loop learning is the modification or rejection of a goal / approach in the light of experience. It recognizes that the way a problem is defined and solved can be a source of the problem. Double-loop learning has us question our approaches. No one approach fits all situations. Is the approach we are using the right approach or can we change or improve? All the while still getting our work done.