Agile workers collaborating on a mast of a sailboat

How do I consider the staffing feasibility of a project when traditional procedural models are replaced by Scrum, Kanban, or DSDM Atern in the practical implementation of a project? How does resource management work in an agile environment? Let’s talk about agile resource management!

1. Capacities, Demand, and Resources in an Agile Context

These questions are posed by many portfolio managers, department heads, and dedicated resource managers. Regardless of who is the driving force behind agile initiatives, the initial focus is on working more collaboratively, independently, and effectively. The continuing need to compare capacities and demand in order to create a feasible, realistic project portfolio is not exactly obvious in this context.

Resource Management – Do We Still Need It?

Modified Agile Resource Management

Taking both perspectives into account, it becomes clear that we still want to manage resources in order to maintain an overview of our performance, identify the right people for specific tasks, and to maintain the ability to plan for external support as needed. Only the basic conditions and parameters are modified in an agile context.

  • So how can the resource management be changed? How can it be more agile?
  • What can resource management contribute to fortify the agile revolution?

2. Let’s Take a Look at Principles of Agile Development

It is generally advisable to consult the 12 principles from the Agile Manifesto in order to check any issue that arises with respect to an agile approach. Anyone can do this in the course of his or her daily work, and it is worth discussing the issues mentioned above. Three of the twelve principles have a clear connection to resource management and lead to constructive modifications of the resource planning process:


A photo displaying a manager and her team collaborating for agile resource management

“Subject matter experts and developers must collaborate daily during the project.”

Resource Planning Limited to Individual Departments

It is often the case in IT-driven companies that concrete planning of personnel deployment is only done for the IT department. Developers, testers, analysts, project managers, and system administrators are then counted among the desired resources that are often over-planned by several hundred percent. In the best case, there is an IT portfolio planning system with resource management that not only strategically classifies the projects and prioritizes them according to utility, but also ensures capacitative feasibility. In terms of agile principles, this means that projects are scheduled sequentially as soon as the “resource box” is exhausted or cannot be expanded anymore.

Out on a Limb

But what happens if these optimally scheduled software development teams are on their own at the start of the project? The necessary stakeholders and subject matter experts from Accounting, Controlling, or Online Marketing need to introduce new processes during this time, and must manage their operative seasonal work at the same time or prepare the annual report, and are also somewhat involved in all IT projects in the portfolio.

New Challenge: Collaboration

Not that this is a new situation or one that is specifically tied to agility. In any case, agile development is only conceivable in a collaborative and extensively interdisciplinary environment. It is precisely this principle and the strict adherence to it that makes, for example, agile software development so much better than traditionally organized projects where compromises might be made. Insufficient and continuous collaboration and cooperation with the (internal) clients
results in one of the greatest risks of software or product development – developing “past” the need.

Agile Resource Management for All

Based on this conviction, it seems absolutely necessary for resource management to take active responsibility for the planning of all people involved and to establish processes for this.

In doing so, resource management does not have to operate at the same level of detail and constancy in every division. Only the objective must be clear: to create the framework that allows subject matter experts and developers to collaborate daily during the project.

Some initial, simple actions to support the formation of collaborative teams:

  1. Per project: overview of which departments are involved in the project
  2. Per division/department: overview of which projects a department is scheduled for
  3. Organizational: identification of the persons responsible for the decentralized capacity planning of a division/department
  4. Agreements with the line management concerning leave, and the form of involvement of employees from specialist divisions, e.g., concerning dedicated project employees, project weekdays, times of day, temporary project jobs, etc.

A weakened form of resource management such as this already creates a good framework for stakeholder management and specific agreements by project or product managers.


Soccer team members celebrating a win

“The best architectures, requirements, and drafts are produced by self-organized teams.”


The term “imported team” has been in common use for quite some time, and the Tuckman team-building phase model with its four stages, “forming, storming, norming, and performing,” from the 1960s had already caused competent project managers to go to great lengths to establish stable, well composed teams working responsibly as a group, and to get them to “perform,” even before agile frameworks existed.

Scrum defines such a team consistently as a requirement for all tools and rules regarding collaboration, and simplifies its basic structure using fixed team roles. It is up to the organization and the individual to specify which members will make up this team and which solutions and products they will create.

Team Profile as a New Challenge

Ensuring a good “profile” for self-organized interdisciplinary teams represents one of the great challenges for agile organizations. First, expertise and skill sets must be well distributed. Also, the soft factor “chemistry” becomes much more important than in parallel part-time assignments with less team interaction.

Here, the lines become blurred between resource management and organizational team formation, and there is a need for a(n) (agile) collaborative cooperation between department heads of the line organization and the perpendicularly organized, project-focused resource managers.

Dynamic Team Formation as a Resource Management Task

The synergies resulting from a department head’s management experience and knowledge of human nature, the self-assessment of colleagues, and the mathematically stringent approach of a resource manager appear promising. What if the resource manager added parameters regarding constant
team collaboration and personal preferences to his or her optimization rules for utilization and the assignment of individual experts?

Could this result in a different form of resource planning, from which teams are optimized dynamically and, in the best case, systematically based on needs and on efficient, agile collaboration? Is this not better than rigidly defining agile teams for which there might not be any suitable tasks in this form in the next major strategic project?

Resource management can fall back on methods and tools that compose and, ideally, permanently establish agile teams dynamically and reasonably.

Parameter for agile Resource Management

The management of resources can become a positive reinforcement for agile approaches if the following parameters are incorporated:

  1. “Frequency of collaboration” as a decision criterion for team composition
  2. “Location” as a highly weighted parameter
  3. Introduction of a personal “chemistry” factor by the employees themselves
  4. Degree of constancy for “topics/products”
  5. Capacity-oriented planning on the team level

These factors, of course, do not replace other factors such as qualification, preferences for internal or external composition, cost, availability, or, in general, materials planning.

These demands on resource planning represent a challenge. If they are resolved well, they help create the framework for the agile principle of self-organized teams. This also increases the likelihood that solutions and products will not only be created one time, but rather will be continually optimized and expanded.

In this way, dynamic team formation strengthens another agile principle:

“Agile processes promote sustainable development. The client, developer, and user should be able to maintain a steady pace for an unlimited period of time.”


Boxes of vegetables at a farmer's market

“Deliver functioning results regularly and within short timeframes”

From Timeboxing to Resource-Boxing

This agile principle results in the methodology of working in timeboxes, which means delivering a usable result that creates added value, within a specified timeframe. Without calling it resource management, agile frameworks such as Scrum add skill and capacity components to this principle. This is usually done by supplementing a timebox (“sprint” in Scrum) with the rule of a fixed interdisciplinary team that is available, preferably full-time, for the duration of the sprint
and that has sufficient competency to implement the tasks independently. Before each sprint, the actual capacity and team composition is reviewed and taken into consideration for the sprint planning.

In short, this means that for the period of a timebox, a team composed of several people with defined expertise is specified for a desired result. This commitment is thus capacitatively based on a “resource-boxing” over the period of a timebox.

Resource Box:
Working days in the sprint * Number of scheduled testers = Allocation of a “resource box” with test skills

Viewed in this way, the participating testers, developers, or analysts are only allocated for a sprint over a short period of 1-4 weeks and are scheduled as a fixed “resource box.” Albeit at 100%.

Resource Management Becomes Easier and More Flexible

This simplifies planning considerably in comparison with traditional resource management, because it is much easier to plan colleagues full-time for exactly one project or team than to plan them on a percentage basis for several projects running in parallel. There is always only a single project or product manager as a contact person, and the efficiency of all colleagues previously “divided” on a percentage basis increases as a result of reduced context change and more sequential work.

In addition to this positive effect, the short-term allocation for sprints creates a new flexibility. In certain circumstances, a key resource may not be available for a project for 2, 3, or 4 weeks. However, in contrast to the very long-term allocations in traditional resource management, a person or even an entire team in the agile environment can be flexibly redeployed after the end of the sprint – at full strength.

More Team Expertise – Less Individual Skills

Ideally, the team remains together and, except for individual skills, the imported team is scheduled for new tasks with its dynamic and selfoptimized work processes. This works consistently when sufficient projects or tasks are regularly initiated for this exact team configuration.

Resource management together with portfolio planning can help optimize the agile principle of the self-organized team by the formation of teams over time, which are scheduled as a block for longer periods of time and are only supplemented with external consultants, vacation replacements, or specialists when there is a specific need.

Timeboxing Simplifies Planning and Creates Flexibility

  1. Fixed cycles, 100% allocation, and sequential processing simplify planning
  2. Short-term allocations for sprint durations create flexibility for resource allocation
  3. Optimization is possible by means of appropriate project and team profiles

3. Summary

A photo displaying a lighthouse representing an example of reorientation

Reorientation in Resource Management

In summary, it can be said that agile frameworks and methods will in no way replace capacity planning. On the contrary, by partially reinventing itself, resource management can become a supportive, optimizing column in the creation of added value through agile methods.

The precise manner in which this occurs is heavily dependent upon the starting point, the size and structure of the organization, and the diversity of the content of the project orders.

Agile methods require new ways of thinking for organizations and especially for all resource managers who may have the objective of creating a dynamic framework for collaborative, results-oriented, focused, interdisciplinary, and flexibly deployable teams.


The examination of agile principles and the conscious focus on resource management are intended to encourage people to think about this exciting and, as of yet, insufficiently discussed topic and to create and describe solution spaces in one’s own environment or even across disciplines.

Like What You’re Reading?

Subscribe to our mailing list to receive similar articles right to your inbox.

By entering my email address and clicking on “SUBSCRIBE”, I agree to receive regular information from Meisterplan on project portfolio management, resource management and Meisterplan. I can unsubscribe from the Meisterplan newsletter at any time.

Want to read more?