READING NOTE · UPDATED 2026
Readiness is a conversation about constraints
An assessment can uncover important dependencies, but a score should not replace evidence about delivery. Ask which conditions enable a safe, useful experiment and which conditions are missing. The original readiness discussion is relevant to that inquiry. Avoid presenting a checklist result as a certification that an organisation will succeed with Agile.
A practical next step
- Identify the proposed change and its dependencies.
- Inspect a real delivery example with the affected people.
- Choose one missing condition to address before scaling.
This 2026 reading note is written by the Durnall editorial team. Richard Durnall’s original text follows below.
Read the diagram as text
Name a real problem, choose one practice, state a hypothesis, run a bounded trial, inspect evidence and decide whether to adapt, stop or extend. A method name alone is not a result.
Original publication: .
Printed day and month matched to the original monthly archive, which establishes the year. Check the date source ↗
The original words below retain their period and attribution. The reading note above is the current editorial addition.
Source capture · 2014-02-15 ↗I strongly recommend starting any initiative to introduce new practices to an organisation with a readiness assessment. I wrote a previous post on common patterns that I come across when organisations decide to introduce Agile and Lean techniques. Many of the barriers to success can be identified and prevented with a little foresight resulting from a short, early assessment.
So, what should a good assessment include? I structure my assessments around people, process and technology. Each of these areas can pose their own barriers to change and often present their own challenges to successful adoption.
People
In this category I assess things like the current people capability, the perceived capacity for change, the staff demographics (PM, BA, QA) by roles and the organisational recruitment plans. It’s important to get early line of sight in these areas as it’s important to develop plans to improve skills and change the ratio of roles early.
I recently coached a team that had just started on the early stages of their project. I hadn’t been involved in the inception of the project and I was only there for a few weeks to help them get going. Unfortunately they had planned using their old staffing ratios so that the team had 2 PM’s, 6 BA’s, 1 QA and 1 Developer. The team had been built for performing heavy up-front analysis and not much else. This and other problems would have been caught immediately had an early assessment taken place.
Process
Here is our opportunity to measure the current process capability prior to introducing any change. It has always amazed me how many organisations start out on an improvement exercise without any idea of the current capability or where they would like to be. My weapon of choice here is Value-Stream Mapping (VSM). VSM helps us to get a good understanding of the current process efficiency and helps to identify good places to start our improvement activities.
At this stage I also like to take a look at the project portfolio: the blend of projects, size, cost and other similar information. This helps us to identify good pilot projects and identify any challenges that we are likely to face integrating our new processes at a portfolio management level.
This is also our opportunity to discuss with the business customers their immediate pain points and the metrics and perceptions that they use to measure IT performance. I recently worked with a team that had used a 6-Sigma driven customer survey as a trigger to their latest round of work. To say that the feedback they received was insightful would be an understatement!
Technology
Using some technology is like trying to run in quicksand. It just is. If the organisation has a strategy to buy the biggest, heaviest products that they can find (and as many of them that they can find) then try as we might we’ll never become that efficient. Why? Because our constraint will very quickly move from being our process to being our technology. If we select a portal product that takes 25 minutes to build then our team are going to be spending a lot of time watching the application build, or worse, they won’t build it very often. It’s important that we select technologies that support the way that we want to work.
Assessments in this space are best focussed around reviewing the architecture strategy and standards to identify potential pain points. If there is a technology strategy in place then this is also a good place to look. If it contains heavyweight portal, ESB products or similar then big alarm bells should be ringing.
Once our readiness assessment is complete (and it shouldn’t take long) we’re in a position to start developing a vision for the organisation. I use the term vision to ensure that we focus at a suitably abstract level and allow ourselves to adaptively plan. Organisations are weird, dynamic things and if we create predictive plans we are destined to fail the same way as on a software delivery project. I look at the short-term (<12 months), the medium-term (1 – 3 years) and the long-term (3 years+).
If we’re smart we should be able to gather this information very quickly and end up in a very strong position to develop our adoption plan. If you’d like more information on the process that I follow then take a look at my presentation on Introducing Agile. I’d love to get your thoughts.