arrow_back

The Starting Problem Series - The Agile Resource Allocation Dilemma - Part 1

Congratulations! You have now convinced your management team to adopt agile. Everyone (or at least most) in your leadership team have extended their support toward this initiative. Everyone believes that this transformation will be excellent for your organization as 1) you are adopting agile 2) claim that your organization is challenging the status quo and 3) you will be able to do product delivery faster.

All transforming organizations and their respective leadership experience a tremendous amount of excitement during this phase. There is a desire to get 100% results and now the leadership team has to commit resources to agile teams to jump-start the transformation. At this "starting point" is when transforming organizations experience the challenges with making commitments.

Typically, prior to adopting agile, a software development and delivery organization would be organized around functional skills - Development, Quality Assurance, Project Management etc. This “tower” or “silo” organization makes sense in the waterfall world to “maximize” effectiveness of the delivery of the artifacts associated with that functional skill. In addition, team members work on multiple projects and tasks that are allocated to the resource by a project manager. This structure and process is very common across most pre-agile organizations.

In agile software delivery, all these resources need to be part of cross-functional teams - self-organizing teams that produce 100% of the results based on sprint commitments made by its team members. The management team expects nothing less than this. However, the challenge facing leaders is that they often do not fully adopt the “dedicated team member” principle of agile and continue to allocate part time resources to the intended agile team. The most likely cause of continuing to split allocations of team members is that they still have a critical role or knowledge required to deliver other critical projects.

In the next posting, we will outline the impact of ignoring the dedicated team principle and some ideas for helping to transition to fully dedicated teams.