Let’s talk about VISION.

Vision relates to inspiration, but tangible. At a basic level, vision is knowing what must be built and why. At a more advanced level, vision channels Chrisotpher Alexander’s concept of Strong Centers. A product with a strong center exudes value through a purpose that is self-evident in its execution. Every feature exists in balanced harmony to amplify the product’s reason for existing. Any product lacking a strong center, which includes most IT, isn’t sure why it exists because developers cluttered it with conflicting features and design choices.

Vision is necessary because it controls development priorities. Every new day presents choices about what to work on next, what to delay, and what to delete. The sum of these choices must follow a theme that is stable from start to finish. This doesn’t mean you should design every detail up front. However, it does require that you spend more time contemplating the whole product before ramping development, in what can be considered a Pre-production stage. In this stage you should be deeply engaged in ethnography, design, and technical risk containment. Again, not Big Design Up Front (BDUF), but enough design up front to give the product its special reason for existing, its unique personality, proper acceptance criteria, and a stable theme that will help it achieve its ROI with a minimalist execution.

Let’s talk about PRIORITY.

Prioritization is leadership. It is about deciding what to work on next, what’s in, and what’s out. It’s also about knowing which elements of execution are more important than others. Prioritization isn’t something you can do up-front. Prioritization happens every day. When a worker or team finishes a task, what next? What conditions determine if they are done? Sure, you could have a project plan, but executing against a plan only ensures that you will waste massive amounts of time developing a fictional story while doing many wrong things at the expense of more important things. On the other hand, you could let developers select their own tasks from a fresh backlog, but that’s just a plan by another name. It requires that you generate and maintain a backlog that is bigger than the available capacity, with dependencies factored in. It is far more efficient to allocate work in real-time based on a match of resources and top priorities, as they are known at that moment.

Let’s talk about TEMPO.

Tempo (or pace) is extremely important. This is about how much your production team gets done every week. Managing tempo opens the world of production management.

• First, run continuous production. This doesn’t mean three-shifts 24×7. It means no stopping for planning, no sprints, and no epics. There should be no ritual downtime between tasking.
• Second, reduce garbage time (a term from Theory of Constraints). Project management is garbage time. Metrics reporting is garbage time. If it doesn’t contribute to production or quality, it’s garbage time.
• Third, create accountability for productivity. We recommend running a weekly tempo where everyone demos their work on a fixed day of the week (e.g., Demo Thursday). If you have slackers, you need to flush them out. If you have internal or external flow constraints, you need to flush them out. Innovation loves a deadline.
• Fourth, stabilize the production flow. Flow is a complicated topic, but the simple goal is to maintain the continuous part of continuous production. Once flow is stabilized, there should be no unplanned downtime at any station caused by a shortage of inputs. All materials on which the work depends are available at the time they are needed. It is tempting to invest in optimizing flow, but optimization is not important. The goal is to stabilize flow, so your software factory produces at a steady and predictable pace. If you achieve this, you win. Optimization is pure fantasy for most organizations.

But what about Agile?

There are two types of Agile:

• Agile Inc. (capital ‘A’), which is a cottage industry that pushes frameworks, consultants, professional certifications, and (if we are being honest) an egalitarian ideology.
• Agile in its fundamental form (with a lowercase ‘a’), which is about executing with craftsmanship, efficiency, and responsiveness.

The lowercase agile is good and healthy. Agile Inc. is unhealthy.

Over many years, Agile Inc. (capital ‘A’) has promoted harmful misconceptions. One misconception is that organizations should eliminate planning, preparation, and anything resembling a waterfall process. A second misconception is that leadership, as a concept, is bad and you must rely on self-organization for task allocation. A third misconception is that productivity must not be spoken about, and productivity measurement is both unethical and unwise. This is some harmful B.S.

Not everything about the so-called waterfall is bad. In fact, it is almost impossible to consistently produce good products without some sequentially dependent steps. The real enemy isn’t the waterfall, it’s the rigidity (and stupidity) of project management. If you can only delete one thing, it should the culture of project management and the stranglehold it exerts. It is okay to have project schedulers, but high-discipline project management has been the root cause of most software failures throughout the decades. To put it simply, the discipline of project management is incompatible with the needs and realities of software development (see article). As for prioritizing leadership, this is essential to sustaining a high-functioning purposeful culture. The challenge is installing good leadership, which we leave for another conversation. Regarding productivity, yes, as with any production environment (a.k.a., factory) you should measure productivity and hold the organization accountable for targets.