ReliabilitySite Reliability Engineering (SRE) means working on the most important functionality of a system: reliability, a “feature” that precedes any other. To illustrate its importance, imagine that you need to use a service whose operation is based, in whole or in part, on computer systems, electronics, telco and other related industries. Take any online service, reliability is critical. If the assistant who wakes you up in the morning and streams your favourite radio station might not be essential, the smartphone that allows you to interact with relatives and friends, manage documents and appointments, definitely is critical for the quality of your daily life. If your smartphone is “not available” and the apps like your bank account, Google, social networks, and Wikipedia do not work, some problems with your routine could loom. With various nuances of criticality, these are – under the hood – very sophisticated platforms that interact and work with each other, self-balance and often consist of millions or billions of lines of code and hardware devices. The functionalities all devices and apps offer to correspond to possibilities in the real world. The idea, therefore, is that they should be kept efficient and responsive for those who use them, with a quality of service that lives up to the needs. This is called reliability.
The immensity of the systemTo illustrate, if downloading a file from your Drive may appear to be a simple gesture, behind it lies an endless chain of events: from the mobile radio network, the data flow travels encapsulated, encrypted, in an optical fibre, through transoceanic cables that carry it within milliseconds to a remote datacenter, and back. In turn, there are data links that allow these infrastructures to communicate with each other, provide network services, hardware, but also energy and gas on the network – even further upstream. From POS to pay in-store, to ticketing services, to the railway, motorway, aeronautical and civil signalling networks, to remote surgery, to medical diagnoses in the cloud. But also the logistics of each package delivered by courier, the work of the “riders”, the heat trails of food and drug transport. All of these are pivotal platforms for entire sectors and for the quality of personal life: industry, communication, education, marketing, media, health, public administration, democratic processes – almost the entire service sector – and beyond.
Possible drawbacksThere are many things that can go wrong.
- First, systems become inherently unstable over time. Due to their incredible complexity, they tend to break down and it is necessary to work continuously so that this does not happen. The work activities on the systems and their updating must not be carried out only when «accidents», or events of an exceptional nature, occur, they must be part of business as usual. As business as usual, the activities can prevent inertia, obsolescence and technical debt.
- The latter are all daemons that threaten not only the quality of the services but also the possibility of continuing to introduce changes in them. The SREs is to keep the systems stable and that of the programmers is to write and maintain the functionalities. of products, with continuous software releases. Each release, therefore, could introduce new errors, and complexity.
Value of SREReliability is the upstream feature of any system. However, it is also a difficult feature to communicate because, when it is present, it can easily be taken for granted. It is also difficult to always give the right importance to this theme. To correct this small cognitive bias, the roles and organizational structures of the SREs are often autonomous with respect to the Software Engineers, who instead build the products. The value attributed to the SRE, therefore, is to keep these products stable on systems; error-free, maintainable, usable for the user – no matter what is happening. The value that an SRE offers to its organisation and to the users of its products is, ultimately, that of guaranteeing the stability of production systems, the maintainability of the software and a high-quality level of service. All this regardless of external conditions, be it traffic peaks or continuous releases of new features.
Fabio Mora is a freelance programmer and Agile coach enthusiastic about Extreme Programming and Linux. Passionate about open source, economics and everything related to mathematics and data science, he first founded a web agency and then worked in eBay as a software engineer. He loves music, sound engineering and scientific dissemination.
- New leadership,
- A new team structure,
- The implementation of new technology,
- Fast growth,
- The adaption of a different business model.
- A global pandemic,
- Changes in the business environment,
- A new competitive environment,
- Political changes.
Change Management by APMGAs the name suggests, APMG’s Change Management deals with managing change and its impact. It provides an overview of the theories within Change Management and can be seen as a collection of knowledge and best practices. The methodology provides an extensive insight at all the different stages of change and provides a structured approach for supporting individuals and teams to move from a current to a future state. The key takeaway from this methodology is that change is not a single event, it is a process. To follow structural change there is a need for clarity to connect business strategy to action and its main factor for success is proper communication with all stakeholders. Mastery, purpose and autonomy can help raise change engagement. This certification can aid Change Managers in the following situations;
- Traditional waterfall organisations,
- Transformational changes,
- Organisations with a strong top-down approach,
- Long-lasting and evident-based results.
Agile Change Agent by APMGThe Agile Change Agent is a hands-on course that supports the ideas of collaboration, empowerment and self-direction that are core to Agile approaches. These ideas are also at the heart of effective change management. Unless people participate in designing, practising and adopting the change for themselves, the change does not happen and benefits cannot be realized. The methodology defines different ‘change agents’, these can be managers or employees, or external consultants hired to facilitate change initiatives. A change agent is someone who has a (temporary) job within the organisation and next to his/her daily work facilitates change. The methodology and its course are full of exercises and practical tools, tips and advice. The course focuses less on the theories of change and is more methodological. This certification can aid Change Managers, and others, in the following situations;
- Agile organisations,
- Adaptive changes,
- Organisations with a strong bottom-up approach,
- Fast, person-driven results.
How do these courses & certifications compare?The APMG Change Management program provides a structured approach for supporting individuals and teams to move from a current to a future state. The course equips participants with the theory, tools and techniques to contribute effectively to planning, implementing and sustaining change. The APMG Agile Change Agent certification includes a simple, repeatable lifecycle model which acts as the structure of any change plan. The course provides questionnaires and checklists to help create the culture for effective change. QRP Switzerland offers both the APMG Change Management course and the APMG Agile Change Agent course. Do you have more questions about the differences between the different Change Management approaches? You can contact us and we will be happy to support you with more information, customized to your needs.
What is your role at Smals?I am responsible for the SharePoint Competence Centre at Smals, the joint ICT organisation of Belgium’s public social security institutions. I am a project manager in charge of the SharePoint projects that are entrusted to us by our members.
How did you hear about AgilePM and what was your initial need?AgilePM training is part of our training catalogue. I was looking for an agile method and I knew that the Scrum approach – which is also used at Smals – is primarily designed for software development teams. We had previously tried to implement this approach on SharePoint projects but it had not been convincing. I was looking for a more global approach that also integrates project management, which would allow us to better involve the business representatives in our projects to ensure we are working on the things that mattered.
Shortly after AgilePM training you successfully applied it to key projects. Can you explain the background of the projects?The first project on which we applied the AgilePM approach concerned a Belgian social security institution that wanted to renew two applications, which previously existed in Lotus Notes, into SharePoint applications. These were two large pilot projects (a request management application and an internal communication portal) which would also allow them to develop their SharePoint and project management skills. We implemented the AgilePM approach and it went very well; we were very satisfied for many reasons. Following my training, I trained one of my colleagues to act as an architect/developer/technical coach to the customer. The aim was to ensure that the approach to the projects was well understood on the customer side and to encourage maximum engagement. We briefed our business (business ambassador) and technical (developers) contacts at the same kick-off for both projects. I explained the method, the roles and responsibilities of each, and how it would work. At the end of the kick-off we gave the business the task of creating a first version of the backlog by describing their requirements and prioritizing them according to the MoSCoW prioritization technique (Must have, Should have, Could have, Won’t have this time). The challenge was to designate 60% of the total project effort as must-haves, which can be difficult (often we get 70 or even 80% of requirements as must-haves in the first round).
What were your constraints and challenges?The first challenge was that of coaching, as part of the team was not my usual team. The second challenge was to make sure that the whole project team followed the rules, the vision and the issues. One of the developers who were very good technically was, for example, not convinced by the AgilePM approach; he was a bit sceptical at first. But he finally played the game and was able to see the logic of the approach and that relations with the business went very well. The clients also appreciated working in an agile way thanks to AgilePM, which allows the business to be much more involved in the project and in day-to-day decisions. It is not unusual for the business to think something is simple, but being involved makes them better understand the task and associated challenges. Conversely, the developers have a better understanding of the underlying needs. The AgilePM approach allows for a transparent dialogue and the right choices to be made, without the development teams getting hung up on things that are not so important to the client/business. The clients expected the project to progress (and results materialize) quickly without setting a deadline (which can be a trap as it can take much longer than necessary). However, we managed to deliver quickly and within three months we were ready to go live. There were some network performance issues that prevented us from going live as planned, but we were ready. We simply preferred to wait and solve the network problem rather than deliver a tool that would have been perceived as underperforming, even if the cause was external to the tool.
How did you implement AgilePM?After the coaching and kick-off, we set up sprint review/sprint planning meetings every fortnight for each of the projects, which meant that one project would be dealt with one week and the other the next, and so on. One of the two business ambassadors would automatically attend the other’s meetings to ensure consistency in decisions, as we were working on the same technical platform. Every day there was also a 15-minute stand-up meeting involving the project team (business and technical contacts). We organized a monthly one-hour project board and that was enough to follow the progress of the project. It is important not to go into too much functional or technical detail during the project boards, but to stay focused on the project monitoring. Once this monitoring structure was in place, the project almost ran itself! At the end of the project, we carried out a remote lessons-learned exercise and the feedback from the client was that, in the beginning, they did not necessarily understand what had been explained during the kick-off, nor why we were asking for certain things. However, as time went on everything became clearer, they understood why and the reason for the intensity of the efforts. For a future project, we will pay more attention to this dimension. The client was also unaware at the beginning of the effort that it would require on their side. Being a business ambassador is almost a full-time job and it’s important that they are given the time to carry out this important role. There are various meetings to attend and you also have to be ready to address questions and concerns from the development team on a daily basis, participate in tests, etc. How did the AgilePM approach help you? Was there a particular element that was most useful to you? The most useful in my opinion is the MoSCoW prioritisation technique. There is a big difference between ranking the requirements in an order (1-2-3-4-5) and accepting that a requirement that you consider important is only a “should-have” that may never be implemented because other requirements come first. Continuous prioritisation is probably THE most useful aspect. Of course, this is not the only point, the whole framework is useful.
Do you have any advice for fellow project professionals in the sector?You have to get trained. I recommend taking a training course with an expert and not just watching, reading the book and picking up elements according to what speaks to you. I took a training course in a small group and it allowed me to understand the method, to have templates and to ask my questions. Personally, without the training, I would never have read the whole manual and I would have missed key benefits of the method.
A few words to conclude?Recently I also attended a DevOps course and I can see that the two fit together well as the philosophy and culture are similar. → Curious to read another AgilePM success story? Read on how FLIR implemented the AgilePM methodology in their daily work.
Karine PicartKarine is Project Leader & Team Leader at Smals. She is a specialist in collaborative tools and is responsible for the Smals SharePoint competence centre.
What are the types of change agent?When an organisation wants to make a change happens there are 2 perspectives it should be interested in:
- everybody who has a role in running the business,
- everybody who is in a project or change management role.
Everybody who has a role in running the businessAll the people who are providing the services and the products that ultimately the customer buy from the organisation. In the first group, we have all the staff impacted by the change, whose priorities are using the existing ways of working to satisfy current customer demand and getting the job done. On top of that, when a change occurs, they need to change how they work. Plus, they need to mobilize their colleagues and themselves to participate in the change and, finally, integrate the change into current ways of working. That is exactly the definition of a change agent: somebody having a job in an organisation and next to that job he/she facilitates change. This means a Change Agent can have a role in HR, Finance, Marketing, Sales, Operations, Administration etc.
Everybody who is in a project or change management roleTheir role is about changing the business. In the second group, we have project and change teams, whose priorities are introducing new ideas, innovation and new ways of working, identifying activities and tasks and creating plans to implement change. Plus, they can guide those who are selected as “change agents” to perform their roles. The change agent network is becoming incredibly popular within organisations. People may not be called change agents but the point is that, on top of their daily job, they have the role to help make change happen and integrate changes into the current ways of working.
What does a change agent do?
- Flexibility (and of course being open to change!).
- Effective Listening Skills.
- Influence and negotiation.
- Analytical skills.
- Relationship management.
- Strategic thinking.
- Relationship Orientation.
- Able to prioritize.
- Patience and persistence.
- Deep understanding of the business and business culture.
Why is a Change Agent Important?We know by heart that change is present in any organisation of any size. But in this world of very fast-moving change, we can talk about “agile change”. Since it is not a good idea to try and plan every single change detail upfront, we need to adopt change in an Agile way. That was the idea that Melanie Franklin, thought leader in change management, transformed into an approach for managing transformational change initiatives mainly using the ideas from the agile methodologies. Organisations can benefit from an agile approach to change in order to plan and manage all the activities that are needed to design and deliver changes. And to make changes successful, from both perspectives. If you are doing the day job, change is probably irritating because it gets in the way of you using your existing habits, your existing sort of skills and techniques to get things done really quickly. It slows you down because you have to think through a new way of working whereas everybody on the other side thinks change is great. An Agile Change Agent works to bring these groups of people together, drawing attention both on the project/change activities as well as on the behavioural change of the team. And an Agile Change approach can offer your organisation a structure to plan the elements of your Agile changes. The Agile Change Agent course & certification is designed to build practical ability in Agile and Change to support effective transformation and change initiatives. Visit our website to learn more! SOURCE: APMG; Free Taster Session of Agile Change Agent
- visualize your work,
- limit the work in progress,
- maximize the efficiency (or flow) of the team.
How do Kanban boards work?The main component of the Kanban framework is the Kanban board. The Kanban board is a tool to visualize the workflow of the project. The board shows the workflow and all related tasks, this helps to better understand your processes and provides an overview of the workload. The visualization of the workflow offers the transparency that will help quickly identify problematic work stages. The Kanban board will help teamwork more efficiently. The Kanban board is available for the complete team and everybody can access it to find his/her responsibilities. Everyone can see what each team member is doing and therefore the Kanban board also functions as a motivator to pursue better performance. The Kanban board can be used either as an online tool or in the office itself. The board uses
- WIP limits.
Kanban cardsThe Kanban cards are the virtual representation of tasks. Each card is filled with information about the task, like its description, the deadline, the status. Kanban cards are assigned to a team member or members, who will be responsible for executing the task.
Kanban columnsThe Kanban columns all represent a different stage of the workflow. The Kanban cards move from column to column until they reach their full completion.
Kanban swimlanesThe Kanban swimlanes are horizontal lanes that can be used to separate different teams, services or activities.
Work in Progress limitsThe Work in Progress limits restricts the maximum amount of tasks in the different columns of the board. That means that there can only be a total of tasks in a certain stage of the workflow. The WIP limits help you prioritize tasks and allow you to focus on current tasks. The Kanban board is not static and can be adapted by any team. That means that you are free to add as many columns and tasks as you want. You can decide where to put the WIP limits and whether you would like to use swimlanes. The Kanban board is to be tailored to your specific workflow and needs.
How to use a Kanban board?The Kanban board is a very intuitive tool that anyone can use and understand at first glance. But what are the best ways to use the board?
- Tailor the board for your project
- Look for workflow bottlenecks
- Help your team focus
- Improve time management
- Define a Kanban policy
1.Tailor the board for your projectMany first Kanban boards start with three simple columns:
- ‘to do’,
- ‘in progress’
2. Look for workflow bottlenecksIf there is one column where all tasks seem to pile up, it means that something does not go right in that process. This can be due to a temporary situation, like a sick team member that can not finish his/her tasks or a serious bottleneck. The Kanban board shows where to pay extra attention and helps you to come up with improvements. A more detailed Kanban board will give better insights.
3. Help your team focusIf you make use of the WIP limits on the Kanban board, you help your team focus on the high priority tasks. Often tasks pile up in the ‘in progress stage. If you put the WIP limits, team members will first have to finish their ‘in progress’ tasks before they can start with new ones. This way, the Kanban board helps your team finish assignments that are already in progress and stops the team members from multitasking.
4. Improve time managementThe Kanban board provides a complete overview of the current status of a project and the team. It gives a real-time status on the progress of the project. With that, you can consider cancelling the progress reports and regular progress meetings and save a lot of time. Make sure your Kanban board is not static, but keep on looking for improvements to your board in order to improve your workflow even more. This way you continue to become more efficient.
5. Define a Kanban policyIt does not have to be much, but make sure that every team member knows what the process policy is. Define when to move a card from one column to another column, define what information is needed in your card etc. Each team member needs to understand for example when to move a card or when to add information to a certain task.
- Team Building
- Decision making
- Manage conflicts
- Effective communication
- Know how to negotiate
1. Team BuildingTo be able to carry out and manage projects efficiently and effectively, it is essential that the team is aligned and above all that it collaborates. The project manager must act as the glue between the various members, making them collaborate and assigning tasks that reflect as much as possible the skills and inclinations of each of them. If the project manager is able to create a team spirit that involves all team members, he/she will be able to rely more and more on collaborators. The team will be motivated to work synergistically with each other, which will help avoid problems and misunderstandings and facilitate all processes.
2. Decision makingObviously, in the development of a project, it is necessary to be able to make the right decisions, trying to stay on schedule. The successful project manager must be able to collect the ideas of all team members and then make decisions that may conflict with the proposals received if this guarantees the success of the project. It can certainly be useful to rely on the six-step decision model:
- Define the problem clearly and concisely.
- Brainstorm with the team to come up with possible solutions.
- Define evaluation criteria for solutions and analyze the pros and cons of each of them.
- Understand which other actors are involved in the implementation of the solution and involve them in the process.
- After carrying out the implementation, analyze, evaluate and listen to the lessons learned.
- Evaluate to what extent the project goal has been achieved by implementing the solution.