News

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?

HERMES is the project management method for all types of projects. It is the standard used by the Swiss Federal Administration for IT projects as well as many cantons and municipalities and is also used in the private sector. HERMES 5 Advanced Level is the certification aimed at project managers.  

HERMES Advanced Examination Target

• Project Manager
• Project Staff
• Controller
• PMO staff
• Quality Management

 

HERMES Advanced Exam Format

• Language: German and French
• Duration: 120 minutes Part 1: 60 minutes Part 2. 60 minutes
• Materials permitted: Part 1: Closed book exam. Books or notes are not allowed. Part 2: The HERMES reference manual and a scenario overview may be used.
• Questions: Part 1: 30 Part 2: 15
• Pass mark: Part 1: 18 Part 2: 9 At least 60% of the maximum achievable points are required to pass the written examination.
• Level of Thinking Bloom’s levels: 1, 2, 3, 4, 5 & 6
• Exam Format: Online or Paper

 

HERMES 5 Advanced Exam Sample Questions

In the written examinations, questions are asked about the learning objectives underlying the relevant subject areas of the examination. The procedure for the HERMES 5 Advanced examination is the Multiple-Choice-Questions. There are several possible answers per question. One or more answers can be correct (Complex Multiple Choice). The evaluation is based on a point system.

• Each correct answer gives a plus point,
• every wrong answer a minus point.
• Missing answers (not placed cross) are evaluated with zero points.
• The lowest score within a question is zero points.

 

Example 'Multiple choice questions':

What is the source of best practice? (a) Q (b) R (c) P (d) S  

HERMES 5 Advanced sample question

The following elements belong to the "IT system" module: (a) Result "migration concept". (b) Result "Detailed study". (c) Task "Prepare systems integration". (d) Task "Shut down the old system".  

HERMES 5 Advanced Objectives

The participants know how to manage and control a project according to HERMES and have trained selected project management tasks by working with a case study according to the standard scenario "IT standard application" and "IT individual application". Here is the list of the most important learning objectives:

• The participants have learned the Foundation content.
• The participants have gained a deeper insight into the modules "IT system, IT operation, IT migration, agile development" in the context of the standard scenario "IT standard application and IT individual application". (Scrum/agile, not relevant for the exam).
• The participants learned the modules "Project Basics" and "Project Management" in detail by working with a case study according to the standard scenario "IT Standard Application" and trained the implementation of selected tasks from the module.
• The participants have learned the module "Project Management" in detail by working with a described starting situation and are prepared for the cooperation with the client and the project committee.
• The participants are prepared for the certification exam HERMES Advanced (not relevant for the examination).

 

HERMES 5 Advanced Certificate

The participant receives a certificate for the passed exam. If the participant does not pass the exam, he or she receives a certificate of results for taking the exam. The HERMES 5 Advanced certificate is valid for three years.  

AXELOS has just launched the last two modules of ITIL 4 Managing Professional Stream: ITIL 4 Specialist: High Velocity IT (HVIT) and ITIL 4 Specialist: Drive Stakeholder Value (DSV). With the publication of these last two modules, the ITIL 4 Managing Professional Stream is now completely open to the public! ITIL Managing Professional targets IT practitioners working within technology and digital teams across businesses. The Managing Professional (MP) stream provides practical and technical knowledge about how to run successful IT projects, teams and workflows.  

ITIL 4 Specialist: High Velocity IT (HVIT)

The module ITIL 4 Specialist: High Velocity IT is aimed at practitioners who are now confronted with a world of more digitally-enabled organizations and who want to become more valuable and remain relevant in this new era. The way digital technology contributes to enterprises today requires a different way of thinking, working and a new concept of high-velocity IT. HVIT means professionals should be able to make faster decisions about IT changes. It’s not about speed alone: it’s also about what you need when you need it, which is more dynamic and tailored to the user/customer. Working with complex adaptive systems, practitioners can’t rely on pre-determined processes; rather, it’s about taking small, experimental steps to see what works. This needs both a mindset change and a decision to move away from traditional root cause analysis. The High-velocity IT approach in ITIL 4 is a radical rethink of how to operate in ITSM: it means reconstructing service management – by taking it to bits and putting it back together to improve the ways of working. Looking for a way for making your organization digitally-enabled? ITIL 4 Specialist High Velocity IT training    

ITIL 4 Specialist: Drive Stakeholder Value (DSV)

The ITIL 4 Specialist Drive Stakeholder Value module is about the engagement and interaction between service providers and stakeholders and the conversion of demand to value via IT-enabled services. ITIL 4 also encourages the service provider to help the consumer to improve: the “consumer” is encouraged to adopt service management best practices as part of the product development relationship to elevate mutual capabilities and thereby increasing the co-created value. As ITIL now includes consumers and producers together in multi-dependent workflows and systems, this module is focused on helping practitioners increase stakeholder satisfaction via the best service offerings; something that is essential to business success in today’s highly competitive landscape. ITIL 4 Drive Stakeholder Value takes a higher-level view of what needs to happen across all four dimensions of service management to create and manage effective and streamlined services. Interested in maximizing the consumer experience? Find out more now about QRP's ITIL 4 specialist Drive Stakeholder Value (DSV)     With digital products and services, value is only realized when the users act on decisions that have been improved by the information they have derived from the digital products. The latest iteration of ITIL responds to the fast pace of technological change that organizations are now experiencing. It allows practitioners to progress their existing expertise in ITIL and capitalise on the opportunities that are arising from technological advances. Furthermore, ITIL 4 supports practitioners in carrying out best practice with these services and gives them the tools to take part in this global digital transformation.   Would you like to know more about the other two modules of ITIL 4 Managing Professional Stream? Here you find the pages on these topics!

• ITIL 4 Strategist Direct, Plan & Improve
• ITIL 4 Specialist Create, Deliver & Support