Upper managers are right to insist on some form of formal work management to meet customer expectations. Why any company would not do so escapes me. Yet I have rarely visited a smaller one that did insist, and most larger ones don’t really follow their procedures because those are so inflexible. (Hence the growth of Agile.)
The lack of a formal approach reduces profit, by slowing the delivery of whatever the company sells or reducing the quality of the customer experience, and wasting money paid to workers who aren’t as efficient as possible. Although these impacts are not as obvious in nonprofit or government agencies, they too want to serve as many people as they can by making maximum use of their limited resources.
Every manager I have talked with on this topic has instantly agreed that a disciplined approach has value and, in most cases, has been lacking in their organization. I have found little research to explain why managers don’t insist on such an approach, so I won’t speculate. Start your journey by insisting to your colleagues and employees that they choose not between “doing things as we always have” and agile for projects, but between these and only these four options:
- Full waterfall—By “full” I mean designing and planning every detail of the development of the project before starting development, and instituting a standard change management process. The goal is to manage budget, scope, and schedule by making the plan as accurate as possible and then modifying it carefully to address the inevitable changes. In this case, I strongly recommend reorganizing the company into a “strong matrix” organization in which project team members report directly to the project manager(s), not the functional managers. Regardless, hire experienced Project Management Professionals® (PMPs) and support their decisions.
- Self-directed agility—Create self-directed work teams, and give them the time and freedom to develop procedures that best fit their circumstances and customers. This is my preferred method in almost all settings, but can be a longer and more disruptive process in a larger organization trying to coordinate the work of multiple teams. This site provides a disciplined way of going about that, which may seem self-contradictory, but “Self-Directed agile” explains why and how.
- Full Scale agile™—If self-organization is rejected by management, I obviously recommend FuSca™, for reasons discussed elsewhere.
- Another system of Agile-at-scale—Buy books, hire consultants, or take classes if need be, and choose another framework to implement. Adopt and learn the system, then modify it. If this approach is chosen, hire an Agile coach to come in full-time for at least three months (for one team) to two years initially (for large enterprise change) and implement that system. Again, support that person’s instructions, and consider changing your organization chart to a strong matrix.
We’ll talk about managing non-project work using Kanban later. Most of the principles of “Decide to Change” apply to those teams as well, but it focuses on choosing an approach to agility based on Scrum for project teams. Many teams in most companies, and some teams in every company, are project teams.
Don’t wait until the company is “ready.” To repeat, people don’t like change, and non-managers rarely see the value of project management until after it is (properly) implemented. Many would rather complain about problems than admit they have a role in those problems and do something about them. Given a choice of “stay the course,” they will. A major goal of any organizational change process is to help people get “ready.”
The rest of this section will walk you through the initial decisions needed to make the change. If your team(s) are ready to dive into agility with no one objecting—a rare situation—they can make the decisions called for and go straight into the process. In most cases, however, you will be well advised to take the disciplined approach of our transformation process where that is discussed in this section.