Despite research limitations, the psychological basis for estimation biases is much clearer now than several decades ago, and these insights can have a positive impact on the practice of project management.

What are the ramifications of moving from a project orientation to a process or product orientation? First, an organization needs to establish an efficient means of production. It must create a funding model and a value stream equipped and staffed with people able to deliver its software requirements. Then the organization must manage the flow of work into that development value stream. The concept of flow is critical to value stream performance. Lean manufacturing principles have established that an overloaded value stream slows down the rate of delivery, increases costs, and decreases quality.

The articles in this issue discuss various aspects of corporate crisis management and how business technology can help companies deal with crises of all kinds, but especially those that change everything. Some of the articles are strategic; some are tactical. But they’re all engaging and useful, with purposeful points of view.

While the software industry is currently grappling with ideas of complexity and resilience, there has been very little in the way of concrete actions or activities that software engineers can use to actually design systems. Residuality theory answers this need and draws on complexity science and the history of software engineering to propose a new set of design techniques that make it possible to integrate these two fields. It does this at the expense of two of the most important concepts in software design: processes and components.

Several fundamental Agile principles drive behaviors that can improve an organization’s ability to make use of its data. One of the Agile behaviors that is key in identifying and analyzing data, and eventually for designing a solution, is the use of cross-functional teams.

Tools and methods can work in some contexts but not others. If you have your own principles and mindset, then you can adapt or create your own methods and tools to fit your context. Once we realized this, we made a mental leap from a focus on methods and tools to a focus on principles and mindset.

The myth surrounding Agile projects goes something like this: a small team of developers who can handle any coding task (database, business logic, user interface, middleware, etc.) works hand-in-hand with the end user who talks with the development team about the details of the work requirements. The small-team-filled-with-generalists model may work for some small projects, but it doesn’t scale. The problem has been with confusing two parts of the traditional development problem: collaboration and specialized skills.