News

Interim Director of Agile Transformation responsible for agile-adoption in a 650 people strong international division and 350 strong UK division of a major financial service provider.  Jon Ward operates in an international context of Agile and organisational change in the financial services, banking, insurance, consumer products sectors, television and retail trade. Author of the book "The Agile Coaches Cookbook", we interviewed him on the most interesting topic of the moment: Agility and project management.  

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 that you would like to learn in the next future?

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 and how did you come up to write this book?

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.

  Jon Ward Practising Agnostic Agile, Transformation Director, Coach, Program Director and Change Leader. With more than 20 years of experience, Jon operates in an international context of Agile and organisational change in the financial services, banking, insurance, consumer products sectors, television and retail trade. He is also certified Disciplined Agile and Certified Scrum Master.

What is the right Agile methodology to choose? How can I understand what is the Agile framework that fits the best with my projects and the organizational needs?  

What is Scrum?

Scrum is one of the Agile frameworks, created to give an efficient management answer to the Software Development projects but its guidance and its flexibility are easily applicable to all those projects that require a fast answer to change.

Scrum method was originally formalized for software development projects, but it works well for any complex, innovative scope of work. It is an iterative software development model used for product development (different from Project Management).

It is the most enabled Agile framework – the result of a survey conducted by VersionOne reveals that about 58% of the Agile organizations adopt Scrum. It was created and developed by Ken Schwaber and Jeff Sutherland in the ‘90s. It is an iterative and incremental approach firstly thought to manage software delivery. Scrum is a team-based approach where the development process is divided into several sprints in order to enhance collaboration with the final user. It encourages teams to learn through experiences, self-organize while working on a problem, and reflect on their wins and losses to continuously improve. In fact, its principles and lessons can be applied to all kinds of teamwork. This is one of the reasons Scrum is so popular. Often thought of as an agile project management framework, Scrum describes a set of meetings, tools, and roles that work in concert to help teams structure and manage their work. Finally, the term “Scrum” was taken from a Rugby practice, where it is a synonym of “melee”: it leads to imagining how the development team works; all the involved actors pushing towards the same direction, as to say towards successful product delivery.  

AgilePM, the only methodology for agile project management

AgilePM (Agile Project Management) is the only Agile methodology for Agile project management. It is the result of the collaboration between APMG International and the Agile Business Consortium (previously known as the DSDM Consortium), it highlights the perfect balance between the standard structured approach of project management and the flexibility and agility typical of all Agile methods. It is a methodology that can be used when all the characteristics of the final product aren’t perfectly defined and, as a consequence, several and repeated requests for change concretize or, the final user wants to receive some of the project benefits before the closing of the project itself. AgilePM was developed to harmonize all the aspects of traditional project management methodologies with Agile to adapt the framework to the high-paced continually changing working environments.  

Scrum or Agile?

We hear very often the question “AgilePM or Scrum?”; apparently there is a trend towards learning and applying a single methodology/framework for all the projects and into all the environments. Actually, it would be tremendously useful to know both methodologies in order to choose the one to adopt case-by-case. The working environment and the kind of project should indicate what method to use and not vice-versa, adapting the project/product to the chosen methodology is always the wrong approach!  

Scrum is a product development framework whereas, AgilePM is a project management methodology.

  Contrary to common belief, the two methods in real life are perfect pairs. In Scrum we won’t find the concept of “project”, that’s why complex organizations using Scrum should apply an Agile approach also at the organizational level. For example, an organization that already has applied Scrum could also be interested in adopting AgilePM: Scrum is focalized on the product delivery, so it can be used to develop products while managing the overall project by applying a Project Management framework such as AgilePM. Scrum, as also declared by its authors, is a framework simple to understand but difficult to apply. Organizations can utilize Scrum to let the customers feel close to the project and to quickly meet their needs during the whole length of process development, but they shouldn’t forget the importance of Project Management. Scrum is a useful tool when handling complex projects because it allows to dynamically adapt to situations and to realize products that fit the exigencies of the final user effectively and creatively. AgilePM could be the right solution for organizations requiring to adopt a project management framework in a fast-paced environment where change can be efficiently and effectively addressed by Agile. It is particularly addressed to all those organizations that due to complex governance reasons need to define the project guidelines since the first phases. If you or your organization are looking for an Agile method to manage projects or non- software products in a lighter way than “traditional waterfall project management”, AgilePM could be the right methodology for you.  

Are you looking for an overview of the 3 most famous Agile methodologies? Download our free article!

       

QRP International is proud to announce it has achieved the ISO 9001:2015 certification, an internationally recognised standard that ensures our services meet the needs of our customers through an effective quality management system.  

Achieving excellence, Customer Satisfaction and Continuous Improvement

We are dedicated to providing high Quality. Our Accredited Quality Management System enables us to maximize Quality provided in all of our activities – from the analysis of clients business needs to the tailoring of the services offered. The Quality Management System ensures that our services are supplied according to the foreseen specifications, in order to assure the constancy of the Quality, the full satisfaction of the Customers and the reference to our Core Values :

1. We do our utmost to make our clients happy
2. We enjoy working together as a team
3. We keep our word
4. We are committed to our professional development

  QRP international decision to work towards ISO 9001:2015 accreditation demonstrates our commitment to continually improving our services. To become ISO 9001:2015 compliant, the QRP team underwent an extensive company-wide audit that included quality management system development, a management system documentation review, pre-audit, initial assessment. Non-conformances have not been identified along with the assessment. ISO is one of the most rigorous and well-regarded standards in the world. QRP International was audited by Bureau Veritas and was presented with their certificate on August 2019.   QRP International Managing Director, Jacobus Groot says:

“As you know the first letter of our brand, the Q stands for Quality which means for us that we are focused on delivering services with outstanding quality. It means also that we are constantly working on improving the quality of our services as we believe that can always improve the things we do. I am therefore very honoured and proud about our achievement of the ISO 9001 accreditation. It is a recognition of much work done in the last years. I was especially proud to learn that we had to make minimal changes to our systems in order to achieve the ISO accreditation as we have been working on improving our systems all the time. It is a great milestone for the development of our company and I am grateful to all staff contributing to this achievement!”

The modern, fast-paced business environment requires IT and digital teams to release innovative and reliable smaller products, faster and more often. Traditional IT frameworks can’t cope with the business needs provoked by this “4th Industrial Revolution” resulting obsolete and inefficient for the majority of the cases.

ITIL has been updated to the new ITIL 4 version to respond to the new business exigencies and to improve usability and integration providing a common vocabulary within departments and teams. But the ITIL v4 framework provide any guidance on how to integrate it also with other Agile methodologies?

Yes, ITIL 4 is equally applicable to all service organizations and has to work across multiple other best practices, in fact, it is a complementary framework to other ways of working, like Lean, Agile and DevOps.

Let’s discover in more details why is erroneous to define ITIL 4 as a “traditional” rigid waterfall IT Service Management framework!

 

Three Reasons why ITIL 4 pairs with  the Agile culture: the ITIL guiding principles

1. The holistic approach and the Creation of Value

ITIL 4 provides a holistic approach to the co-creation of value with customers and other stakeholders in the form of products and services. The holistic approach and the creation of value are the first two of the 7 ITIL guiding principles (focus on value, keep it simple and practical, think and work holistically, start where you are, progress iteratively with feedback, collaborate and promote visibility, optimize and automate).

The ITIL guidance underpins that no creation of value is possible without a smooth and easy communication among users, stakeholders and providers that are all involved in the optimization of the final output which, only with communication and cooperation, will generate the desired outcome. The necessity of putting the focus on value avoiding to create unnecessary capabilities is a core principle from LEAN Management where products are meant to be delivered Just In Time (continual flow of small packages produced in the exact agreed number and delivered at the exactly agreed scheduling) in order to avoid waste (calculated in production expenses, deliverables and human working hours) and to enhance quality.  

2. Start where you are

ITIL prescribe to "Start where you are": in order to deliver a new final product successfully, you can’t manage everything all at once if your organization hasn’t the necessary capabilities (knowledge, economic resources, mental attitude etc). There are processes to be respected and implemented step by step in order to deliver a final service which will reach successfully the desired outcome.

This principle is clearly explained by Kevin Kasunic Manager of Business Transformation at the Walt Disney Company in a famous white paper where he explains how he led the company IT team towards the adoption of the ITIL Framework, you can download the white paper here. The philosophy that stands behind this principle is not a unicum, in fact, DevOps culture suggests to start where one is and with one has got. DevOps is in part based on ITIL and Lean principles that’s why DevOps and ITIL represent two methodologies that could be integrated very efficiently and effectively.  

3. Keeping it Simple and Practical and relays on feedback!

Following the Agile Manifesto, an agile organization is based on individuals (internal and external to the organization) and interaction instead of processes and tools: the focus is on the continual delivery of working software in order to be ready to likely requests for change.

Again, the ITIL guidance results to be fully compatible with the Agile mindset in fact by ”keeping it simple and practical” is possible to continually deliver working packages which will reach the desired outcome because the final product/service is obtained by “progressing iteratively with feedback”.

With keeping it simple and practical, the ITIL guidance suggests not to produce a solution for every exception, focalizing only on the exceptions that have the highest chance to realize instead. You will deliver simple and quick solutions that will immediately show value. This is outcome-based thinking and requires to have a holistic view of the organization processes, procedures, projects and aim. Moreover, avoiding to work on the overall output at a time and choosing to work on manageable smaller chunks helps to address all the exemptions/requests for change raised by the users through their feedback. Progress iteratively with feedback allow to quickly deliver working software which can be easily and iteratively improved until to reach the final output; the final output has been tested and tailored during any iteration by the final user with the scope of receiving a product/service capabilities to help him to achieve the final outcome.  

After this short analysis of the main ITIL 4 Guiding Principle, is it quite clear that ITIL is a complementary framework to other ways of working, like Lean, Agile and DevOps?

Although at a first glance ITIL & DevOps could appear at the antipodes, actually these two IT methodologies have more in common that one could expect; integrate ITIL with DevOps is a quite smooth process that could guarantee a very effective and modern way of delivering software and services.

The Scrum Master is a professional who coaches the team towards the adoption of the Scrum Framework. The core responsibility of a Scrum Master is to lead the Scrum Team to the correct understanding and enactment of the Scrum theory, practices and rules.

The Scrum Master interacts with all the members of the Scrum Team (the Product Owner and the Development Team) and with the entire organization in order to maximize the value created by the Scrum Team.

The Scrum Master is a professional in the Agile Software Development field and s/he responsible for the Scrum Team by monitoring Scrum processes and meetings.

S/he is the professional responsible for ensuring that the Agile philosophy is understood and enabled inside the whole organization (that’s the reason why is preferable that the Scrum Master belongs to the organization instead of being freelance)

Due to their devotion to the Agile principles, the Scrum Masters are often considered as servant-leaders for the Scrum Team.

 

The role of a Scrum Master

The main responsibility of the Scrum Master is being a process facilitator for the Product Owner and for all the Scrum Team. Being a team member s/he has no management authority inside the team in fact, the Scrum Master has to lead the team by acting as a facilitator for the Scrum Events (as the development of working software) and helping the team to release the Product Increment. The Scrum Master is considered as a coach for the Scrum Team.

 

The Responsibilities of the Scrum Master inside the Scrum team

The main responsibilities of a Scrum Master are:

• to ensure that the Scrum processes are correctly enabled
• to facilitate the Scrum events of Sprint Planning, the daily scrum, the Sprint Review and the Sprint Retrospective
• to remove all the obstacles
• to maintain a friend environment that enables team efficiency
• conflict management inside the Scrum Team
• to ensure a smooth relationship within the team and the Product Owner and between the Scrum Team and the other departments. 
• to protect the team from external threats
• to provide assistance on the agile practices, give priority to individuals and interactions over processes and tools.
• Guarantee the adoption of the Scrum framework

• To help the Product Owner with the following activities:
  • Shaping and ordering the Product Backlog
  • Communicating the vision, goals and intended use of the product to the Development Team
  • Describing Product Backlog items to the Development Team clearly and unambiguously
  • Organizing Scrum events when and as a request by the Product Owner

• To help the Development Teams with:
  • their internal  self-organization
  • the removal of any possible obstacle to their work
  • the development of high-value products

• At the organization level the Scrum Master has to:
  • Lead and assist the overall organization in adopting and implementing Scrum
  • Help colleagues to understand and use Scrum
  • Implement any necessary change to increase the productivity of the team 
  • Collaborate with other ScrumMaster in order to increase the effectiveness of Scrum adoption inside the organization.

 

The necessary skills for being a Scrum Master

Scrum.org enlighten the 5 main areas in which a professional has to succeed if she/he wants to be a Scrum Master. A potential Scrum master has:

• To understand and to enable the Scrum Framework.
• To develop the individual and the Scrum Team.
• To manage a product in an Agile way.
• To professionally develop and deliver products.
• Nurture the Agile organization by boosting its improvement.

In a fast-paced, ever-changing digital world, all organizations have to deal with a high volume of change. But are they well-prepared for this? Is it possible to learn how to be better at managing change in an agile world?

We are delighted to share our interview with Melanie Franklin, Co-Chair of the Change Management Institute UK, Director of Agile Change Management LTD and a respected author of textbooks and articles on change, project, and program management. Melanie has dedicated the last 20 years to build the capability for change in organizations. She is a highly respected thought leader in change management with an impressive track record in the successful realization of business change programs across public and private sector organizations. In 2014 she wrote the book “Agile Change Management”, setting out an approach for managing transformational change initiatives mainly using the ideas from the agile methodologies.

 

Can you tell me more about your career? How did you come to the change management path?

I started as a Business Analyst, so my job was to look at how processes could run better. This was in global banking. I loved my job and I was promoted to project manager. I ran bigger and bigger projects until I became a Program Manager. As a program manager, I ran large scale transformational change programs, with more than 52 countries involved, so I did a lot of global change, but this was before we called it 'change management'. When we wrote the managing successful program book (Melanie authored Think MSP - a practical guide to how to run programs), we talked about how important it was to implement the changes we were creating. But we didn’t say how to manage the change: we said change management was very important but we didn’t say how to do it. When APMG brought out the Change Management qualification in 2008 I really loved it so, I started using it with my consulting clients and I’ve used it, I’ve helped with ideas for the current version and I’ve been heavily involved writing on both agile and change because that’s what I do with my clients. They want to work in an agile way and they want to run very large scale change initiatives so, using traditional methods like PRINCE2® does not work, it’s too controlled and it implies you know everything at the beginning (which you don’t in change, you never do). Actually, it seemed obvious to me that bringing agile and change together was a good idea; I’m really pleased that I wrote the book Agile Change Management five years ago and I’m really pleased we’re taking into a qualification because it’s exactly what organizations keep asking me for: “How can we manage our change? We’ve got our IT department working in an Agile way and we need to roll the change out in small pieces. We need to do iterations, we need to build up versions.”

Finally, what we came out with it’s a very practical point of view. I had a very successful career as a program director but then I moved to training and consulting in program management and change management which I loved. And now my career is more focused on developing best practice, how we can do better.

 

So, you started the change management path and then the agility came later?

Yes, I think agility came to a couple of years after we started talking about change because, of course, as you start to do more change initiatives then you realize that change is always going to be “do a little bit, see what the reaction is, do a little bit more”. It naturally is an agile approach and I think that’s where I started to become very interested in agile methods. I went on every course you can imagine, I have every agile qualification. Because that’s how I learn, I always learn a practice first and then I can work on how to implement it. In the last few years, my enthusiasm has to lead me to chair the Change Management Institute in the UK as well. So, I’m very interested in building up recognition for the profession of Change Manager, to make sure that what we do as change management is recognized and appreciated.

 

How did you come up with the idea of Agile Change Management?

As I mentioned before, my clients wanted to work in an agile way and they wanted to run very large scale change initiatives. Using traditional methods couldn’t work because in an agile environment you don’t know everything at the start, so it seemed obvious to me that bring agile and change together was a good idea. What I wanted to do was to create something that did not assume that somebody being trained was going to be the expert who let the change, because I think that the effective Change Managers Handbook and the Change Management course do that brilliantly. I also did not want to assume that the person needing to be trained was the person involved in the actual project that creates the tangible change (the AgilePM course does that); what I wanted was for somebody to have an understanding of how they might make change happens in the finance function, the marketing department, the operations unit, the call centre, whatever, that they are not experts on either agile or change but what they are is very good at managing their part of the business. But you have to give them a structure and an approach for managing change. This is what this new course does.

 

What’s the biggest challenge that you see in the agile and change management communities at the moment?

I think the biggest challenge is that with an agile approach you increase the number of changes that go live in an agile organization. Because change happens in every increment, it might be every sprint, and you’re ready to go live with something new. The problem we have is that the brain does not process this requirement to unlearn the old ways of working and learn new ways of working as quickly as we can produce the actual tangible change.

So, implementation and adoption are slower than creation and we end up with people feeling under tremendous pressure because they are struggling to deal with one change when another one comes in, and another one… and I think change and a high volume of change means we need to get better at managing change, we need to keep educating people that it is a skill they can learn. Because if we don’t I’m not sure that organization won’t get to breaking point.

Speaking on the behalf of professional change management, I think we still have to win the argument that change management is the secret to realizing benefits. If you have a project that creates something, it won’t realize benefits if it’s just getting things done - it becomes only a new way of working after a period of time when you see cost reduction, revenue increase, greater customer satisfaction, greater staff engagement. Unless we get the message that to actually run the change in a structured way, we need to use techniques to encourage people to participate and to encourage people and support people in working in new ways, we won’t get benefits. This process is not automatic yet.