True agility requires ruthless prioritization


Primary roles on agile delivery teams are expected to be fully dedicated to the one project or product that they are supporting.

Depending on the scope and context of a project, certain specialized roles such as database administrators might support delivery activities during specific iterations, the core analysts, developers, designers and testers need to focus on that one project or product to avoid incurring the velocity and quality-impacting fruits of multitasking.

Easier said than done.

Project portfolio management excellence is realized not just by prioritizing funding to just those projects which we can afford within a given time period but by ensuring that the concurrent number of projects matches available resource capacity.

Through the economic vicissitudes of the past decade, organizations have got better at ensuring their portfolio spend fits enterprise budgets for project work, but most companies still haven’t solved the problem of how many projects should they have active at any given time.

Managers wish to ensure that their team members are being fully utilized to avoid attracting the attention of zealous cost cutters. Waterfall or traditional delivery encourages unproductive multitasking by forcing managers to have to allocate their staff to multiple concurrent projects so that their utilization will not be challenged.

Total utilization does not result in total productivity.

The greater the number of distinct initiatives someone works on, the greater the percentage of context-switching waste and quality impacts which will arise.

So when the organization embraces agile delivery, if there is no corresponding balancing of the number of concurrent projects to available capacity, the impacts of multitasking will become apparent very quickly.

This can be challenging for organizations that are commencing the transformation of their delivery approaches. For some period of time, potentially very long, there will be teams delivering in a traditional manner and others delivering in an agile manner. Calculating effective concurrent project throughput in a hybrid state can be mind-numbing but this effort is necessary if the organization wishes to reap the full benefits of the transformation.

We have to learn to cut our coats according to our cloth (and not just how much we can afford to spend)!



Categories: Agile, Facilitating Organization Change, Project Management | Tags: , , , | 1 Comment

The five failures of agile tools

HammerInTheHead.htmFor organizations transforming their technology delivery from traditional to agile approaches, there’s a need to evolve team practices, tools, leadership behavior and stakeholder change appetites in parallel to avoid realizing the risks of being agile while standing in a waterfall. Owing to the popularity of the agile movement coupled with mainstream obsession with DevOps, legions of tool vendors stand ready to sell you snake oil solutions to satisfy all of your agile delivery needs.

But before you sign that vendor contract, consider the following five failures of agile tools.

The inability to incorporate different perspectives

A tool suite’s ability to capture of relevant metrics, produce colorful reports or deliver sexy dashboards is worthless if process to enter or maintain the underlying information is not equally user friendly. While procurement decisions are normally taken by those consuming the output of the tools, not including evaluations by project team members will provide those decision makers with all the form but no substance.

An inability to integrate

Agile tooling presents two distinct options. Buy a comprehensive tool suite from a single vendor that covers the whole construction and delivery lifecycle or purchase distinct best-of-breed products and integrate them. If your company is fortunate enough to have limited technology standards, the former approach might work well, but for most larger companies heterogeneity is the norm so the decision is often made to go with point solutions. No harm in this approach, but if integration considerations are not part of the product evaluation process you could end up with functional siloes (e.g. development or testing) dictating the bells and whistles required for the point products which they would primarily use and no one will be focused on end-to-end operability.

No standards, guidance or governance

Few tools will be installed out of the box with the appropriate usage models for your organization baked in. While you could take a hands-off approach to guidance letting each team figure things out for themselves, the free-for-all which ensues will catch up with you when you look at supporting portfolio-level processes or when there is a need to align the work of separate agile teams. While we want to provide flexibility where beneficial at the project team level, there is a need to define a minimally sufficient set of standards and provide all users with tool training as part of their onboarding to ensure they don’t shoot themselves in the feet.

A lack of discipline

Agile success exposes the need for greater levels of discipline than with traditional delivery approaches. Planning and work management tools can help teams objectively forecast when their next release will be ready but only if the team is disciplined about entering and updating the status and size of all work items. Team collaboration environments are a great way to overcome geographic distribution challenges but only if the information uploaded is accurate and complete.

Tools don’t fit the practices

While most tools can be configured, few possess the ability to be fully customized nor is that a desirable practice unless a company wishes to assume the ongoing maintenance of such customizations. Given this, some compromises have to be made on how consistent the nomenclature or workflow is between the tools and the procedures they are expected to support. However if insufficient effort is spent up front in defining the must-haves from a lexicon or process perspective, these gaps will become a source of data quality and team member frustration issues.

Tools can be a powerful enabler, but a fool with a tool is just a more dangerous fool.


Categories: Agile, Facilitating Organization Change, Project Management | Tags: , , | 2 Comments

Are you done?

DoneOne of the challenges of traditional project delivery approaches is that team members often treat the completion of their own tasks as proof of project progress. This perception gets reinforced by project managers or their people managers who will give these team members a pat on the back for getting their assigned tasks completed on time.

One of the original twelve principles of the Agile Manifesto is Working software is the primary measure of progress. Teams following an agile delivery approach look beyond their individual tasks to a feature or capability as a whole. It’s not enough that a component has been developed. Did it pass all of its acceptance criteria without regressing previously completed work and are all of its supporting elements equally ready for release?

To help an agile team gain perspective, it is common practice for a Definition of Done (DoD) to be developed by the team. This becomes the standard against which work items are assessed and ensures consistency of understanding between the team and key stakeholders.

But a team’s DoD could still provide the illusion of true progress.

Long lead times for setting up environments, or limited, shared environments are just two examples of blockers which could hamper deployment. In such cases, a deliverable might be ready to ship but customers are unable to realize business value as it can’t be deployed.

In other situations, it might not even be possible for teams to complete deliverables. Requirements for independent testing, lack of access to all testing environments, or an inability to incorporate all supporting elements (e.g. documentation, change management) into the deliverable could prevent the completion of shippable capabilities.

Such constraints are normal in organizations commencing the agile transformation journey, but leadership teams need to ensure that they continue to whittle away at the blockers which impede full delivery. Otherwise we’ve evolved our understanding of progress from an individual perspective to the team level but we still haven’t realized the true definition of done.

Categories: Agile, Facilitating Organization Change, Project Management | Tags: , , | 1 Comment

Create a free website or blog at


Get every new post delivered to your Inbox.

Join 333 other followers

%d bloggers like this: