Challenges and Opportunities of the Agility: interview with Jon Ward

1. What’s your current job title?

I am an Enterprise Agile Coach. What does that mean, you may say? I am responsible for the planning and organisation of moving a group of people from traditional ways of working to new agile ways of working. I act as a catalyst, providing training and coaching to teams and senior managers as they switch project delivery methods. I design and implement a new project management eco-system so that project teams are enabled to deliver high-quality solutions faster.

2. What do you actually do?

I find that I spend about thirty per cent of my time correcting middle or senior management “myths” about agile. For example, you cannot be agile unless you: deliver to a customer every sprint, have co-located teams, have the customer embedded in the team and so on. The proponents of these views are usually trying to find means of establishing an exemption from the new ways of working – they sometimes provide interesting coffee breaks!
Then I spend a chunk of time measuring and forecasting. Senior Management always wants to know the impacts of their transition to agile. I am required to continually answer the questions like; are the projects going faster, are we being more efficient, if I make a further investment in automated testing tools what will be the likely payback?
Lastly, I get to work with the teams: Teaching and coaching agile practices and trying to avoid becoming “fake agile”. Agile is a dish of many spices and some people think that if a team is using scrum it is agile. This is quite far from the truth as getting to the right solution is as much about agile requirements modelling and agile quality practices as it is about Scrum. So “fake agile” is about avoiding doing agile – the ceremonies and so on, but becoming agile – ability to deliver faster, rapidly pivot and work with collaborative teams displaying empirical project control.

3. How did you come to Agile project management career?

I think that Agile project management came to me rather than the other way round. I started my career working on Concorde and the Harrier jump jet. I worked in production control we used a board to plan the stages of production of components, assembly, test and so on. Later I learned the term Kanban used to describe this effective planning and control process.
I headed off into a traditional Project Management career and then moved to establish a project management consultancy. We had just over one hundred consultants with bases in New York, Frankfurt and London we focused mainly on financial services. Over time I noticed that traditional project management skills had become a commodity and demand for project management consultancy reduced.
Then in 2007, I was asked to introduce Scrum into a software house in South London. I saw amazing results from this team in terms of control and efficiency. From then on I started to use some Agile Techniques in the context of traditional projects. For example, working for a global American bank in Chicago I introduced BDD into the waterfall requirements process. We halved the time for the requirements stage and what’s more reduced the number of requirements misses in UAT from approximately seventy per cent of defects to less than ten per cent. From then I took an on-line scrum master course, attended a Discipline Agile Masterclass and qualified as a SAFe Program Consultant. For the last two years, I have acted as Director of Agile transformation leading a team of coaches to improve business performance.

4. What’s the biggest issue/change you see in the Agile community at the moment?

I think there is a significant challenge in the agile community about implementing organisation-wide agile. Some people think this means “agile-at-scale” this is far from the truth. The agile-at-scale frameworks (SAFe, LeSS, S@S, Nexus and so on) provide means of combining a Scrum team of between 5 and 9 individuals so they can deliver larger pieces of work. The frameworks provide guidance on organisation, planning and control processes for large teams using Scrum or Kanban as their control mechanisms. There is a misconception that an agile-at-scale framework will define mechanisms at an organisational level to enable it to be agile. They don’t! As with the PMI or PRINCE2 guidance, an organisation needs to tailor the agile processes and practices provided by a framework to suit their organisational context. However, care needs to be taken to avoid taking off the waterfall straitjacket and replacing it with an agile one! Agile builds upon the energy, creativity, and knowledge of the team to define and deliver appropriate solutions any organisation-wide agile approach should maximise the impact of this human potential.

5. What tips could you give to our community regarding your past experiences?

I have a mantra:

“Agile without metrics is anarchy
Agile without quality is pointless”

My tip is this: focus on the numbers used in the agile ceremonies. Make sure the numbers in planning, forecasting and control add up. Allow the numbers to illustrate the empirical control is effective. Publish numbers to senior management (not inter-team comparisons please!) so they may see the improvements being made.
Secondly, focus as much on getting the right requirements and delivering those exactly as the focus you apply to the agile ceremonies. Quality solutions don’t happen by accident they happen by design. Use shift-left techniques to manage quality.

6. What are three things you’ve told yourself that you would like to learn in the next future to develop you as a professional?

Albert Einstein famously said, “Once you stop learning, you start dying” Since I don’t wish to start the latter! I seek to learn as much as I can. Unlike a journey, in my view, there is no end to learning. Agile is a dish of many spices I want to know more so that I may help organisations become more efficient and effective. In this, my approach is – learn. Test, develop.
I want to know more about the use of artificial intelligence to support agile business and teams. It is very clear that some aspects of agile cannot be enhanced “individuals and interactions over processes and tools”. However, there are areas where AI can be or should be applied to increase productivity. Testing is clearly one, backlog management and preparation another.
The second area I want to learn more about is Agile Quality assurance. Many teams think that because they use Scrum, they are agile. I want to learn more about how to change behaviour with regards to quality. We often talk about the agile domain expertise with which can help the team. We also talk about issues with quality and testing, getting it “right first time” and so on. I am intrigued by the technical and behavioural skill set needed to become an Agile Quality Coach.
Lastly, while when I left college as I mentioned earlier, I used a Kanban board for production control purposes working in the aircraft industry. So I am familiar with the technique. However, I want to know more about planning and organising using Kanban. In particular how to integrate a team producing small work items for many Scrum Teams. Where scale and specialist expertise means that these skills cannot be embedded in the Scrum team in the short term. I want to use PDCA to see if we can do more than simply treat the Kanban team as an external supplier. I also want to know more about how to use Kanban to drive organisational agility – I am talking about the portfolio Kanban concept.

7. Tell us more about your book “The Agile Coaches Cookbook”. What is it about (even if you already told me a bit) and how did you come up to write this book (if it is not already responding question 4)

Thanks for asking about the book. In reading and learning more about agile I realised that there is a lot of material written about agile at the team level. However, once you start to look at agile at the organisational level the materials become scarcer.
The Agile Coaches cookbook is exactly that; it provides recipes for agile coaches. There are four sections:

• The master chief – tools and techniques for agile coaching, how to create a coaching diary, establishing what type of agile coach you are, using a team health check model to determine team interventions and so on.
• Recipes for teams – includes how to get teams started, transitioning from waterfall to agile, getting to a backlog, agile risk management and illustrating project control.
• Recipes for the organisation – includes why is adopting agile so hard, identifying the systemic challenges, coaching sponsors and changing the PMO.
• The transformation dinner party – bringing it all together, stages in agile transformation, preparing a goal-based transformation plan, using the PMO as an agile catalyst, alternatives to agile scaling, agile portfolio management, using metrics to prove success.

The goal of this book is to help scrum masters and agile coaches to be more effective. An agile transformation is rarely the domain of a single agile coach. This book allows teams of Agile coaches to decide on their “big rules” and to orchestrate their actions in harmony rather than acting as discordant individuals.