Hand Drawn Chart Saturday
As organizations transition to Agile, teams often ask about how to transition from classic command and control project methods into self-organizing teams. Self-organizing and self-managing teams do not just appear magically. Both the project teams and the organization have baggage that needs to be rationalized and unlearned to progress from needing to be lead to leading themselves. The concepts that need to be learned include measuring business value, team decision making and to share the real goals of projects.
Classic command and control project management (which I would classify as minimally collaborative) is based on the premise that the project manager has a unique set of skills for project planning, controlling the activities of the team and status reporting/ Certifications, like the PMP, have been used to encourage this belief. In this environment the measures of success for projects are being on-time, on-budget and on-scope.
In Agile projects, as we have discussed in earlier Daily Process Thoughts, the roles of the classic project manager are spread across the three basic Agile roles (Product Owner, Scrum Master and Development Team). A fourth role, the Agile Program Manager, is needed when multiple projects become a coordinated program (see Daily Process Thoughts, July 19 2013). The primary measures of success in Agile projects are delivered business value and customer satisfaction. (Note: Delivered value and customer satisfaction should be the primary measure of success in ALL types of projects, however these are not generally how project teams are held accountable.)
As teams learn to embrace and use Agile principles they need to learn how to make decisions as a team. The decisions that teams need to learn how to make for themselves have consequences, and they will be wrong sometimes. To accomplish this learning process in the least risky manner, the team should use techniques like delaying decisions as late as is practical and delivering completed work using time boxes. These techniques reduce risk by increasing the time the team has to gather knowledge and to elicit feedback. The organization also must learn how to encourage the team to make good decisions. This requires the organization to accept some level of explicit initial ambiguity that is caused by delaying decisions, rather than implicit ambiguity of making decisions early that later turn to be wrong and in turn lowers productivity. The organization must also learn to evaluate teams and individuals less on the outcome of a single decision and more on the outcome of the value the team delivered.
Teams also have to unlearn habits. For example, relying on others to plan for them. In order to do that, all leaders and teams must have an understanding of the true goals of the project (listen to my interview with David Marquet) and how the project fits into the strategic goals of the organization.
Teams make designs daily that affect the direction of the sprint and project. The faster these decisions are made the higher the team’s velocity or productivity. Having a solid understanding of the real goals of the project helps the team make decisions more effectively. Organizations need to learn how share knowledge that today is generally compartmentalized and not shared with developers, testers or analysts.
The process of learning and unlearning occurs on a continuum as teams push toward a type of collective self-actualization. As the team moves toward its full potential the need to control planning and decisions falls away. If the organization doesn’t back away from the tenants of command and control and move towards the Agile principles, the ability of any team to continue to grow will be constrained because the organizations leadership owns the definition of career success. The tippling point generally occurs when an organization realizes that self-managing and self-organizing teams deliver superior value and higher customer satisfaction, and that in the long run is what keeps CIOs employed.