I recently facilitated a process for soliciting requirements for an Agile work management system for a medium-size enterprise. You know, the kind of system that needs to scale beyond a scrum team and even scrum of scrums to many of boards across the enterprise, support reporting and analytics on multiple levels, integrate with various existing systems, and accommodate a variety of workflows. Many people proposed a large number of requirements and it was interesting to see how a large number of oddities like, “I want to see my burndown chart on Android; no, Blackberry” converged to a smaller set of really important stories.

Last week I was at a demo event organized by one of the vendors and it was during the demo that I realized a lot of these requirements are rooted in one principle. If vendor whose product you’re looking it is not aligned with this principle, you don’t need a very long RFP.

Your vendor’s deployment frequency must be at least as high as your organization’s target deployment frequency.

To understand this thesis, watch Kent Beck’s 2011 lecture Software G-Forces: The Effects of Acceleration. In his talk, Beck presents a scale of deployment frequencies – yearly, quarterly, monthly, weekly, daily, hourly. How high your frequency is largely determines a set of practices, both technical and organizational, that your company has to have. It has to follow some practices and get rid of others to sustain its frequency. For example, if you deploy yearly, you can have a siloed QA department to do testing at the end; if you want to deploy more often, you need a more collaborative organization. If you want to deploy weekly, you have to remove “code freeze” from your vocabulary. If you want to deploy at least once a day, you may need a continuous delivery pipeline. Changing the frequency creates forces that bend your process and your organization to a new shape. (Watch the whole video here or on YouTube – I believe it’s a must-see for any software professional today.)

In the past, yearly deployments were the norm and very few deployed more often. Today, the quarterly frequency seems to be the norm for the industry, but there are quite a few firms with Web-based products that practice continuous delivery and deploy daily. There are firms that deploy every 12-18 months, but they are facing extinction. The trend is towards increasing the frequency.

The great thing about Kent Beck’s model that it allows practitioners to be completely non-judgemental when it comes to differences between systems of work and practices in their organizations. There is no need to argue which way of organizing code branches is better. There is no right or wrong way; there are just the ones that are a good match for a particular frequency range and the ones that aren’t!

What does that mean if we need to choose a tool?

Your tool vendor’s area of subject matter expertise is Agile itself – collaborative systems of work, principles and practices of Agile teams and organizations. We have just learned how those depend on the deployment frequency. If you’re ahead of your tool vendor in terms of frequency, it’s very likely that the vendor lacks expertise in operating at that frequency. Why would you then buy their product?

You can sit through the demo and take notes of where their product lacks features you want (from a long desired feature list) or where their software product codifies behaviours that can straight-jacket your collaborative teams. When you have taken enough notes, you can see the common theme in them: these guys have too much time between deployments compared to you.