Corporate Multitasking | Glossary

Definition: 

The corporate form of multitasking is pursuing too many concurrent projects. When an organisation takes on too many projects people become shared across multiple projects, which leads to individual multitasking. Individuals feel compelled to multitask because the organisations in which we work attempt to multitask as well. 

The detrimental effect of multitasking  then causes those projects to take more time, which leads to more multitasking near the end of the project when we need to start a new project. Mary and Tom Poppendieck urge organisations to limit work to capacity. An organisation that has more projects running concurrently that can be adequately staffed is attempting to work beyond its capacity. Don’t start a new project until it can be fully staffed, Include ramp-up and wind-down time in enterprise plan, gaining agreement on simple rules can help lead to the right organisational behaviour such as “No one can be assigned to more than two projects. Go slow, but go. You have to believe that doing fewer concurrent projects will lead to more projects being completed. 

Further Reading:
Book: SUCCEEDING WITH AGILE Software Development Using Scrum by Mike Cohn

Emergent Requirements | Glossary

Definition: 

Emergent requirements are the features which cannot be identified in advance. User stories that are not defined, but rather emerge during the lifecycle of the software development. These exists on every nontrivial project, they cause problems. An up-front design phase will always be imperfect as it will be impossible for the designer to consider the requirements until they do emerge.

In sequential development process, emergent requirements are handled by adding contingency buffers to the plan and emergent requirement is viewed as a failure of the plan. Agile teams accepts the requirements that will emerge, no matter how carefully team members plan. The first step in dealing with emergent requirements is to acknowledge that we cannot thing of everything well in advance, some requirements will emerge as we develop the system. It should be accepted that we don’t need a perfect requirements document up-front that specifies all details of the system to be developed, rather it is better to specify features with different levels of precision based on when the feature with be developed.  It is not good idea to loc down requirements in a contract, we can’t. We can pretend requirements are locked down and won’t change but some always do. The best contract reflect this or at least acknowledge that change will happen. 

Further Reading:
Book: SUCCEEDING WITH AGILE Software Development Using Scrum by Mike Cohn