News

The current pandemic is challenging all of us in many different ways. One big challenge is that almost everybody works remotely. Meetings are cancelled, plans have changed and business, as usual, is interrupted. Also, we as QRP International have to alter the planning of our courses. However, the pandemic was also the last push we needed to finally execute the plan we have had for a long time; Virtual Classrooms. As of now, we can offer all of our courses virtually. We have the same teachers, the same challenging learning methods and the same energy. The only difference, you and the other participants are all in different locations.  

Our Virtual Classroom solution

We do our utmost to make our clients happy. It is with this core value in the back of our heads that we developed the Virtual Classrooms. We thought about giving you the best possible learning experience. In this light, we decided not to just copy the on-site classroom courses, but we shuffled it up. Our Virtual Classroom courses are made out of a mix of live training and homework. This is because we do not think you will be happy to sit behind your webcam for eight hours straight. The morning or afternoon sessions are taught live and that is where the trainer explains the methodology. This is your opportunity to ask questions to the trainer and engage with the other participants. The other part of the day, you will actively apply all that you learned while doing the homework. To do this homework we use tools that will make it easier for you to study and that have AI-driven exam simulations. After finishing the course you will be more than ready to complete the exam!  

High-quality solution

The Q in QRP stands for Quality, so quality is what we deliver. We use a state of the art e-learning software and provide you with a course that is in line with our quality standards. As you expect, the course is provided in all local languages. The Virtual Classroom courses are taught by our trainers, experienced and still active in their respective field. The courses include examples of real-life situations and are adapted to the group of participants in order to offer them the best possible experience.  

Why now?

The changes in your business, as usual, might leave you with some time left on your hands. Once everything will go back to normal you will probably be challenged with an overload of new projects, programmes and software development. Now is the time to build up the expertise to face these coming changes so why not follow a course, get a certificate and change your business downtime into business uptime? QRP develops professionals to facilitate change. So we have been able to provide you with a solution during this challenging time for all of us. We offer our Virtual Classrooms next to our e-learning solutions and also hope to start providing you again with classroom courses on-site soon. If you want to know more, download our Virtual Classroom brochure here. Or contact us directly.

PRINCE2 Foundation - Virtual Training

AgilePM Foundation - Virtual Training

ITIL4 Foundation - Virtual Training

Virtual/Classroom Course Calendar

The Scrum Developer is the professional responsible for creating the project deliverables, together with the rest of the Scrum team. As described in the Scrum Guide, there are three core roles in Scrum, responsible for meeting the project objectives:

• the Product Owner,
• the Scrum Master
• the Development Team.

The Development Team is made up by professionals who work to deliver a potentially releasable increment of “Done” products at the end of each Sprint. These professionals are Scrum developers. The Development Team is responsible for:

• understanding the business requirements specified by the Product Owner
• estimating the user stories in the sprint backlog
• developing the product/service (deliverables).

Each Scrum Developer is responsible for delivering a functional element (also known as a chunk) of the product at the end of each sprint.  

Scrum Developer responsibilities 

When working for a Scrum project, Scrum Developers have the following responsibilities:

• Achieve the goals defined for each sprint
• Attend daily scrum meetings reporting the planned tasks for each day
• Assure to Product Owner and Scrum Master that the allocated work is being performed as planned
• Ensure a clear understanding of epics and personas
• Provide inputs on the creation of User Stories to the Product Owner
• Understand the User Stories
• Estimate User Stories approved by the Product Owner
• Commit User Stories to be done in a sprint and develop the list of tasks based on the User Story
• Report to the Scrum Master impediments to the progress of the project, if any
• Agree on the length of the sprint with the other Scrum Team members
• Develop the Sprint Backlog and the Sprint Burndown Chart
• Create the deliverables
• Update Burndown Chart, Scrum Board, and Impediment Log
• Submit Change Requests, if any
• Participate in Prioritized Product Backlog Review Meetings
• Identify improvement opportunities, if any, from the current Sprint and agree on any possible improvements for the next Sprint
• Participate in the Retrospect Project Meeting.

   

The necessary skills for a Scrum Developer

A Scrum Developer should have:

• technical knowledge and skills (software analysis, coding, software programming or testing)
• deep knowledge of the Scrum framework and an understanding of how to implement it effectively for any software project
• excellent team skills, necessary for the collaboration with the other team members.

Other important soft skills, highlighted by the Scrum Guide are:

• Highly Motivated
• Proactive
• Self-organized
• Independent
• Responsible
• Intuitive
• Goal-Oriented

Sources: Schwaber and Sutherland, The Scrum Guide; © 2017 SCRUMstudy™. A Guide to the Scrum Body of Knowledge (SBOK™ Guide).

A portfolio is defined as a set of projects and programmes that are managed by an organization. A portfolio can consist of multiple programmes and/or multiple projects. The projects within a portfolio can also be different from each other. However, the programmes within a portfolio are formed by related projects. The portfolio represents the implementation of an organization’s strategy. Portfolio Management is the coordinated management of the projects and programmes that help achieve specific business objectives. Portfolio management defines priorities based on business objectives. Projects and programmes that are to be implemented are based on these priorities. The selected projects and programmes will together enable the most effective balance of creating business value, the risk level and resources to be used. Where project management serves to correctly manage projects, portfolio management serves to choose the right projects. In the MoP (Management of Portfolios) guide, Axelos defines portfolio management as; “a coordinated collection of strategic processes and decisions that together enable the most effective balance of organizational change and business as usual.” Portfolio management characteristics:

• Portfolio management is focused on the return of investment (ROI) and the effective implementation of change through both programmes and projects.
• Portfolio management is used to ensure an excellent allocation of resources (human resources, assets, materials, funds and services), to achieve the key strategic objectives.
• Portfolio management supports organizations to choose the suited future projects and programs by providing structured information to managers.
• Portfolio management is used to ensure that the priority of projects and programmes is periodically reviewed in order to invest resources according to the strategic objectives of the organization.

 

Differences between Program and Portfolio management

In the blog post ‘What is Programme Management,’ we explained the meaning of a Programme and Programme management. According to Axelos a Programme consists of one or multiple projects and serves to meet one or more strategic objectives while focusing on enabling change. Programme Management is the management of all related projects that together form the Programme. The main difference between Programme and Portfolio management is that Programme management is about similar projects. Portfolio management, on the other hand, manages projects and programmes within a wide range and even different fields.  

Portfolio management: why it matters

Portfolio management can allow organizations to:

• Better allocation and use of resources between projects or programmes
• Better communication between projects and programmes
• Better coordination between projects and programmes

According to Axelos, "in an ever faster and more demanding world like today, portfolio management can help organizations successfully implement change and achieve their strategic goals." * Today more than ever organizations that want to keep up with changes and innovations need an approach that focuses not just on projects and programmes but on the portfolio. The challenge is to find the balance between managing business as usual and change while ensuring that the business and the whole organization are willing, ready, and capable of supporting and assimilating change. *Axelos: What is Portfolio Management

During the interview with Mélanie Franklin, Co-Chair of the Change Management Institute UK, she highlighted how important it is to manage change in an Agile environment. The changes in Agile are complex and continuous. In an Agile environment, innovation is continuous which will take other processes out of practice. Due to this, changes are complex and become more frequent as time passes. Past changes soon become part of the ‘business as usual’. In this post, we will provide you with the expert’s advice and techniques to help you plan your change in Agile.  

How to plan Agile?

Agile talks about evolving solutions, which basically means that within Agile you constantly have to re-plan. Instead of planning just the next step, in Agile planning is done looking at the final goal. It is important to understand the destination so one can orient the route to get there. In this way, it becomes easier to define the things that will really help to achieve the final goal. The work to be done is decomposed in a decomposition scheme, where the final goal is divided into small components. Decomposing the work to be done, means to look at the project from a bottom-up approach. Seeing these small components, it becomes easier to prioritise, identify the timespan, resources and communicate to the business. In Agile planning is a team responsibility, all resources are involved so that they can actively contribute to the planning. The driving question to Agile planning is ‘are we really doing the most relevant thing to achieve our final goal’? Planning in Agile is something extremely difficult and constantly changing. The planning starts high-level, by defining the desired destination. Step by step, by questioning the usefulness of undertaken actions, Agile takes you to plan more and more detailed. With Agile the level of detail grows progressively.  

Behavioural change: what is it and why is it important?

One of the biggest challenges in Agile planning is taking into account behavioral change. Resources are not robots and any type of change will impact their way of working. For example, employees can lose familiarity with their work or need time to understand new techniques and/or systems. The transition activities take time and there needs to be room to make mistakes and to practice new ways of working. This means that while planning, not only emotional effects must be taken into consideration, but also the overall change acceptance. Together with project activities, it must be made sure that the resources are ready for new activities, new ways of working and that they understand the final goal. However, it often happens that technical activities develop much faster than behavioural change. Melanie Franklin identifies the three elements of behavioural change; test new ways of working, understand how to do things and create new habits. Attention should be both on the project activities as well as on the behavioural change. These two should be synced in order to avoid resources not being able to use new features or practices. Therefore at the end of each iteration phase, there must be an agreement on how the current and upcoming change will be managed. This is a collaborative activity because it involves both those responsible for the outcome as well as the users.  

The importance of punctual delivery

Respecting the set timeframe for product deliveries means knowing when change can be expected and when improvements should start being visible. Sharing the activities and meeting deadlines also means answering the expectancies of the resources on the new way of working. It is important to respect delivery promises because change is always a source of stress; delay could increase the emotional impact of the change. Respecting the set timeframe is therefore fundamental. But how to decompose the total timeframe? M. Franklin suggests different levels of planning, see the image below.   The first element is the timeline exists of different iterations and at the end of each the outcome is identified. In order to achieve these milestones, M. Franklin has identified the following steps to follow;

1. Getting started
2. Making progress
3. Realising benefits

  1 Getting started This step is more or less a brainstorming session about all the activities that need to be done. In a real Agile environment, this would be called the ‘user story’. It is essential to cover both the ‘delivery’ and the ‘transition’ parts of the change management activities. This activity is collaborative and therefore an opportunity for everyone involved to understand the approach to work and timing. 2 Making progress It includes all the changes in the working procedures, both technical and changes in ways of working. At the end of this step, the parts of work are reviewed and the elements of change are assessed on their quality and effectiveness. 3 Realising benefits The final step is used to analyse the output so far. Benefits are taken into use and all that is no longer needed is eliminated. This step is also important to include all resources and to make room to thank them for the work that has been done. This creates a motivating environment for all team members. These steps offer a repeatable structure for each iteration that can be used to plan the elements of your Agile changes. Curious to know more? Read the article: “Change and opportunities in Agile Change Management: Interview with Melanie Franklin” SOURCE: How to plan and Agile change initiative, APMG International

We all know that DevOps is a transformation of both people and culture. Breaking down the so-called 'wall of confusion' between Dev and Ops means collaboration and DevOps encourages a culture of collaboration and learning. DevOps wants to build cross-functional teams and, of course, it requires practical specialists. However, DevOps is not a specific job title or team.  

Is DevOps Team really necessary?

Talking about the 'DevOps team', the industry is divided on whether a DevOps team should exist or not. The article “The Industry Just Can’t Decide about DevOps Teams” * showcases different opinions. The most popular opinion is that DevOps teams are an antipattern: they can create additional silos and, more in general, all people in an organization should subscribe to the DevOps culture. Theresa Naete, in “Break down DevOps team roles so you can actually get to DevOps” ** says:

“The point is that we are not achieving DevOps if we are still siloing teams. (…) In this world, Dev and Ops are now on the same team. Let me repeat that: it’s the same team. What some of us don’t understand is that culture is paramount and primary to tools. This culture includes breaking down the DevOps team roles, silos and working barriers so any chosen tools can then be optimized to achieve our desired results.”

But there are also supporters of the idea that DevOps teams are an effective way of transitioning to a new way of working and, despite the fact that the majority of the industry thinks teams are not the right approach to evolving DevOps capabilities across an organization, the DevOps teams are on the rise. The goal of DevOps within an organization is to improve the delivery of value for customers and the business; different organizations could need different team structures in order to create an effective Dev and Ops collaboration. This means that the ideal organizational structure for implementing DevOps depends on many variables.  

DevOps roles

As we said before, there is no one-size-fits-all structure for a DevOps team (or we could say there is no such thing as a DevOps team). Roles and responsibilities will vary according to your organisation: the most important thing is to identify key roles and responsibilities and have the right-skilled member to cover them. According to TechBeacon*** the most common DevOps roles, that are pivotal for any organisation that wants to adopt a successful DevOps approach, are:

• DevOps Evangelist: the person who promotes the benefits of DevOps across the organization. He/she is passionate about DevOps and his/her role is to ensure the back-up from development and operational teams. The DevOps Evangelist is your DevOps Leader.
• Release Manager: sometimes known as the Release Engineer or Product Stability Manager; responsible for overall progress, he/she coordinates and manages the product from development all the way to production.
• Automation Architect: also called Automation Engineer/Expert or Integration Specialist; he/she analyzes, designs and implements various strategies for the product’s continuous deployment. This role is critical because it ensures a reliable environment that is fully automated and free from obstacles.
• Software Developer/Tester: of course this role is at the heart of a DevOps organization (the Dev of DevOps!). But in a DevOps environment, the developers are responsible not only for turning new requirements into code but also for unit testing, deployment and ongoing monitoring.
• Experience assurance (XA) professional: if in the 'classical' software development Quality Assurance (QA) has a vital role for the successful delivery of the final product, in DevOps it evolves in Experience assurance because this role also needs to ensure that all new features and functions are released with the end-user experience in mind.
• Security Engineer: he/she works side by side with developers, making the under development product secure.
• Utility technology player: traditional IT operations or systems administration professional who focuses on keeping the servers running; he/she operates effectively across development platforms, networks, databases, servers and tools.

 

DevOps Culture

DevOps is about sharing and learning so as important as having a skilled team member, is having an ambitious and open-minded team member that is constantly looking to change and learn. These are the three key characteristics for a DevOps professional:

• a good team player, who fits well in your organization’s culture;
• a curious person, who wants to experiment over and over and keeps on trying and failing until he/she learns what will work: DevOps encourages responsible failure;
• an adaptive professional, who can embrace change with a positive mindset.

    Copyright 2017-2019 PeopleCert International Ltd. Other sources: * Helen Beal, The Industry Just Can’t Decide about DevOps Teams ** Theresa Naete, Break down DevOps team roles so you can actually get to DevOps *** 7 key DevOps roles you need to succeed What Team Structure is Right for DevOps to Flourish?

QRP International is pleased to announce its partnership with TempTraining, the continuing education fund for temporary workers.

If you work on a temporary basis and would like to take training in Project or IT Management, you can take advantage of subsidised training through Temptraining.

Who can benefit from it and which courses can be subsidised?

Temporary workers who are subject to the Collective Labour Agreement (CCL) for the loan of personnel are eligible. You can receive up to CHF 5,000 for further training and up to CHF 2,250 for compensation for loss of earnings.

Temporary workers thus have the opportunity to update their skills or specialise in their professional field.

Temptraining supports continuing education in various fields, including IT and economics. Our Hermes, ITIL and PRINCE2 courses fall within these two areas. You can choose between virtual or on-site courses in Geneva and Zurich in English, French or German.

If you would like to follow one of these trainings, you can submit an application before the training takes place on the TempTraining portal.

The calendar of our QRP courses on Temptraining can be consulted from the TempTraining site, filtering by training institute and selecting QRP CH Sagl.

What are the requirements to get access?

If you have worked on a temporary basis for at least 88 hours in the previous 12 months you can benefit from Temptraining. Certain additional conditions must be met for your continuing education application to be approved.

Why choose QRP for your Temptraining funded training

• Over 20 years of experience
• More than 30,000 certified professionals
• Only accredited courses
• Our trainers have an average rating of 9/10
• Leaders in Best Practice
• Specialists in IT and PPM

Would you like to receive support in choosing your funded training? Write to us: switzerland@qrpinternational.com.