Five expectations for agile tools…

wrong-toolAgile delivery does not mandate the use of software tools, but when scaling agile within large organizations with  greater numbers of stakeholders, geographic distribution of pods, compliance requirements and similar enterprise challenges, tooling can improve efficiency and effectiveness.

There are a few basic expectations which should be met to ensure that your tooling isn’t consistently identified as a blocker during stand-ups and retrospectives.


Agile enables greater levels of transparency and objectivity than traditional delivery but if the underlying tools can’t be trusted to reliably and responsively capture and provide information then pods are likely to experience greater levels of interruptions and requests for status updates.


There is no right answer when it comes to the choice of purchasing an end-to-end tool suite from a single vendor or pursuing a best-of-breed point solution approach. But without seamless integration at the logical connecting points, the risk of data quality or redundant effort increases.

Context-based flexibility

While we encourage team self-organization, in larger environments there is the need to have some standards about where and how critical delivery information elements are captured. Without this, there is likely to be no consistency between product or project-based pods which will make it that much harder to enable a self-serve, lean governance and oversight model.


A good tool facilitates agility by adapting to the working style of the team member instead of requiring them to significantly modify their practices. The greater the delta between tool and team member practices, the greater the need for comprehensive training and for constant reinforcement of expected practices.

Scalable complexity

Minimally sufficient applies to documentation as well as tooling. Teams new to agile should be given a very basic set of features but have the ability to incrementally expand their usage as their maturity increases. However limiting which capabilities are visible to these teams should not prevent more capable pods from advanced usage.

I’m agnostic when it comes to software solutions as the best tool in the hands of a fool will just make them a more dangerous fool but tool capabilities should be commensurate with team needs.

Categories: Agile, Project Management | Tags: , | Leave a comment

Post navigation

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Create a free website or blog at

%d bloggers like this: