The book Remote Team Interactions Workbook – Using Team Topologies Patterns for Remote Working written by Matthew Skelton and Manuel Pais explores several aspects of team-first remote work including highlighting poor team interactions, the usage of the team-API pattern to define and communicate the focus of teams, to remove team-level dependencies, to design inter-team communications and make use of the three team interaction modes from Team Topologies to help.
The book is divided in five chapters. The first chapter gives an overview of the mindset and skills you and your organisation will need to succeed in a remote-first world. The following chapters each describe techniques to track and manage inter-team relationships, to maintain high trust within teams and groups and to make the team interactions more purposeful. The final chapter focusses on some next steps to increase maturity of your remote team interactions.
The first chapter explores some of the techniques that can help organizations adopt an effective remote-first approach. But without good psychological safety and an effective set of “ground rules” and practices for teams for working together, the techniques will not help. Some of the discussed techniques are:
Cognitive load assessment
Use the team API approach to define and communicate responsibilities and team focus
Track dependencies using simple tools and remove blocking dependencies
Over-communicate using just enough written documentation.
The second chapter explores techniques to track and manage inter-team dependencies that work in a remote context. Starting point is the team API including the roadmap for upcoming work as well as communication preferences (channels, time slots, response times). Besides an example you can download a Team API template. Tracking dependencies can be used to assess how dependencies should change (reduce, eliminate blocking ones, …). Final topic in this chapter is about building networks by using coffee, talks, CoPs, guilds and internal conferences.
The next chapter provides some techniques for maintaining high trust within teams and groups in a remote-first world based on group size. How much trust can exist within groupings od a certain size? The anthropologist Robin Dunbar found that the size of physical and online social networks where people can have meaningful relationships is in the order of 150 people. Dunbar sees the following trust boundaries: 5, 15, 5,0, 150 and 500 people. For online spaces (chat tools, documentation tools) these trust boundaries are applicable too. Make sure that each online space grouping should have people with a shared focus on a related flow of change. When using chat tools agree on team-focussed conventions (e.g., channel names).
Chapter four explains some techniques to help make the team interactions more purposeful (whether remote or in person), including detecting ineffective team interaction modes (collaboration, X-as-a-service, facilitating). To be effective, it is essential for the purpose and channel of any communication to be clear and obvious (team-specific channels, community channels, topic channels).
The final chapter gives some suggestions for further activities and patterns to make remote-first, team-centric work as effective as possible:
Setup an internal platform survey
Define and validate a set of user personas for developers and other engineers
Define naming and usage conventions for chat tools
Use the team API with multiple teams to define and clarify team boundaries
Devise and share an execution plan.
This book contains lots of examples and hands on material to use Team Topologies patterns for remote working. It describes techniques to track and manage inter-team relationships, to maintain high trust within teams and groups and to make the team interactions more purposeful. It’s a workbook. On several places you find the header ‘Now your turn’ where you get instructions and templates to look at your own situation. It helps you to bring the Team Topologies book into practice within a remote working environment.
To order Remote Team Interactions Workbook: bol.com
There are not that many books on agile portfolio management, so I am curious what the book Agile Portfolio Management – A guide to the methodology and its successful implementation “knowledge that sets you apart” written by Klaus Nielsen, offers.
The book is divided into nine chapters, starting with project portfolio management, and ending with case studies on agile portfolio management. In between chapters explaining agility at scale, agile portfolio management, differences between project portfolio management and agile portfolio management, hybrid portfolio management and implementing and tailoring agile portfolio management.
Every chapter starts with the same overview figure. It shows 6 circles representing 6 topics where one or two circles are highlighted. I have no clue what the author wants to express. The first two topics/circles are the first two chapters. The third chapter is the fifth circle. The fourth chapter is the fifth topic/circle. Chapter 6 refers to the third topic/circle, chapter 8 Tailoring agile portfolio management refers to topic/circle 4 Tailoring portfolio management and topic/circle 5 Agile Portfolio management.
The first chapter Project Portfolio Management explains in detail the financial approach within traditional project portfolio management. Based on PMI’s Standard for Portfolio Management several financial models like PV, NPV, FV, ROI, IRR, PP, DCF, BCF, PI are explained as well as the continuous stages as initiation, planning, execution, optimization and monitoring and control. Set-up of the chapter is somewhat difficult to follow. All the information can be found in 28 sub paragraphs of the last paragraph 1.7. Explanation of a specific financial model or portfolio governance or stakeholder engagement are all separate sub-paragraphs. I miss structure.
The next chapter The reality of Agility@Scale is more a chapter on lean thinking and principles. Important for agile portfolio management but looking at the title I was expecting something different. In this chapter a brief explanation of the Stacey Matrix and the Cynefin Framework, lean thinking and lean portfolio management (using the theories of the Toyota way, Womach, Larman and Vodde, Reinertsen, Poppendiecks, …), continuous planning, and innovation.
Chapter 3 Agile Portfolio Management starts with an explanation of the Agile Manifesto and underlaying principles. The twelve principles are expanded including (portfolio) practices.
In many paragraphs a table has been used showing Portfolio Life-Cycle Stages (initiation, planning, executing, optimizing, monitoring and controlling), Portfolio Kanban (funnel, review/analyzing, portfolio backlog, implementation, done), Projectized and Recurring. There is no reference in the text or explanation. This table comes back, in exact the same form, multiple times. I would say that only table 3.9 The Portfolio Kanban High-level Overview makes sense. In total 20 times the same table except the title of the table in the field Projectized or Recurring. Even the title is sometimes wrong (same as the previous table). I have no clue and what this says about the quality of the book?
Some paragraphs, e.g., stakeholder analysis is discussed in too much detail (this is not different from PPM stakeholder analysis). Regarding risk management I can make the same remark, there is only a small sub-paragraph regarding a risk burndown chart and risk-based spikes. What I am missing are the real agile portfolio risks. Portfolio risk management is more than the sum of initiative or project related risks. Other topics which are typically Agile portfolio management e.g., portfolio value, portfolio metrics and reporting are lacking details, and the benefits of agile portfolio management is not explained. I have my doubts if a tool-driven portfolio reporting approach is an indication for a medium to high agile maturity. Unclear why the paragraph Exploring EDGE is positioned here, because in the next chapter agile portfolio management frameworks are explained.
Chapter 4 covers several (agile) portfolio management frameworks like SAFe, LeSS, AgilePfM, Nexus, DA (notice that DAD only covers the delivery life cycles), Scrum, XSCALE, Enterprise Scrum, RAGE and the Spotify model. The author mentioned that the latest version of SAFe is 5.0. It’s 5.1 but that is not what bothers me. The description of SAFe talks about the value-stream level (after version 4, it is called large solution). There are now three levels: portfolio, large solution and essential and not team, programme, value stream and portfolio. I would expect that the portfolio level was discussed in more detail, e.g., the portfolio Kanban, portfolio canvas and participatory budgeting. Table 4.3 Levels of SAFe shows the Conformity Rating for LeSS. 5 pages further, we can find table 4.4 Conformity Ratings for LeSS which shows the SAFe key terms!
To refer to LeSS Huge for the agile portfolio aspects is not correct in my opinion. LeSS Huge is there if we need more than 8-10 teams to develop and maintain one product. Finally, the Spotify Model is explained. A pity the author didn’t discuss the Spotify Rhythm model with company beliefs, company, functional and market bets boards which is more related to agile portfolio management.
Chapter 5 compares Project Portfolio Management and Agile Portfolio Management. In chapter 1 it is stated that MoP is long overdue and the PMI’s Standard for Portfolio Management lifecycle is used to structure chapter 1. In chapter 5, it is stated that MoP is one of the best Project Portfolio Management standards and MoP is used to build comparison tables with Agile Portfolio Management (high level, key activities, roles, and documentation). Why no consistency throughout the book? I missed a paragraph explaining the Obeya room concept as an agile portfolio management artifact to replace the portfolio dashboard.
I don’t believe that you can use the Stacey matrix, Cynefin model or the PRINCE2 Agile Agilometer to choose between project portfolio management or agile portfolio management. This only works if all your projects are the same (e.g., simple) and I guess you will have simple as well as complicated or complex projects in your portfolio.
The next chapter talks about hybrid portfolio management. Too short if you ask me. For me hybrid portfolio management is something you need when you have to select, prioritize and allocate initiatives to permanent agile teams responsible for the development and maintenance of specific products and services and/or to one-off temporary projects, to deliver your portfolio’s objectives. Resource management is two-fold. Individual resource capacity management for the temporary projects and up and down scaling of permanent agile teams. Et cetera. The author combines project portfolio management with agile portfolio management resulting in 6 different flavors: standard PPM stage-gate in combination with agile ways of working between the gates, with agile teams (each team is handled as a project), with projects using temporary and agile teams, with an agile framework or agile portfolio management with plan-based projects or with a combination of projects and agile teams.
Chapter 7 focusses on the implementation of agile portfolio management by describing the top 10 challenges and suggested actions for implementing agile portfolio management:
Defining large-scale agile framework concepts and terms
Comparing and contrasting large-scale agile frameworks
Readiness and appetite for large-scale agile frameworks
Balancing organizational structure and large-scale agile frameworks
Top-down versus bottom-up implementation of large-scale agile frameworks
Over-emphasis on 100% framework adherence over value
Lack of evidence-based use of large-scale agile frameworks
Maintaining developer autonomy in large-scale agile frameworks
Misalignment between customer processes and large-scale agile frameworks
Ensure people and process issues do not steal the show.
How to and the importance of tailoring agile portfolio management is the next chapter. The intro, before paragraph 8.1, is eight pages long, without empty or white lines! A bit of tailoring could make it more readable. Is the author now talking about tailoring the agile portfolio (selection or adjustment of initiatives) or tailoring the agile portfolio framework itself? What makes an agile portfolio different from a portfolio? Next a three-step tailoring process is discussed (initially tailoring based on the organization, tailoring based upon the content of the actual portfolio, and continuous tailoring of the portfolio).
The last chapter shows nine (brief) case studies on some degree of agile portfolio management.
Too much traditional PPM theory, instead of agile portfolio management theory. And the case studies offer not enough practical aspects. Sometimes I review books and it’s clear that these books are self-published. This book with unbalanced chapters and paragraphs, inconsistency, the issues with the figures, blurred figures, misspelled names, typos, and wrong numbers, gives me the same impression but it isn’t. I would have expected more from the author’s publisher to improve the quality. Sorry to say, but I can’t recommend this book.
The book Better Agile – How every software firm can spend less time firefighting and have more fun building great software by David Daly highlights his experiences to make agile work. It offers Scrum and Kanban mistakes to avoid and three agile secrets to continuously improve your agility.
The book can be divided in two parts. The first part elaborates on the author’s three agile secrets: how to optimize for flow, how to get the right people doing the right things and the impact of the right feedback loops on the product as well as the team effectiveness. The second part gives 10-minute overviews and mistakes to avoid of Scrum and Kanban and how to choose between Scrum and Kanban. Maybe it was better to reverse the order and start with second part because that would be more in line how organizations will start with their agile journey.
Secret #1: Optimize for flow
In case people are overloaded, are multitasking to extreme levels, are too busy, have changes blocked, are spending more time on fixing then implementing new features, you must optimize for flow. To increase flow efficiency (is touch time divided by lead time) can be done by:
Reduce batch sizes: reduces overall lead time (or elapsed time is touch time + wait time), especially when large batches occur before a continuous process
Reduce overall lead time
Use the ToC to identify and alleviate bottlenecks by increasing focus, support and/or capacity
Understand common sources of blockers on your team and find ways to reduce the delay they cause
Shorten feedback cycles to reduce the effort spent on rework.
To support this secret and the other secrets several coaching questions are mentioned as well as further reading.
Secret #2: Get the right people doing the right things
When people are not focused on the most important work or frustrated with always working on the same kind of task or technology or when there are not enough people with the right skills or there is a lack of knowledge sharing between team members you benefit from getting the right people doing the right things.
It will help when you:
Capture all requests for work in a single backlog (yes, but I would say a single ‘short’ backlog. Saying ‘no’ in a substantiated way is a key competence too).
Do just enough prioritisation of your backlog so the team knows what is most important to work on next
Make sure how work is added to the backlog and how it is prioritised is transparent and visible to all stakeholders
Use guided self-selection to allocate work
Allocate work to avoid key-person dependencies: the most experienced people on the team should spend much of their time coaching and supporting others.
Secret #3: Shorten feedback loops
Are mistakes made more than once, do changes not always deliver the intended benefits, does it take too long to diagnose and fix problems, it will help to shorten feedback loops.
Feedback about the product:
Software testing (is it bug free)
Feedback about how effectively the team is working:
Analysis of key metrics (elapsed lead time, frequency of deployments, change failure rate, time to restore after failure)
Regular opportunities to reflect on their performance and proposed improvements
Information radiators (walls, whiteboards, screens, bells, et cetera).
After a 10-minute overview of Scrum, the following 5 mistakes are explained:
Ineffective Product owner
Not reaching a potentially shippable state in every sprint
Ignoring required technical practices
Kanban mistakes to avoid
After a 10-minute overview of Kanban including a short explanation of Scrumban (using Kanban to support your Scrum way of working), the following 5 mistakes are explained:
Not limiting WIP
Not starting with what you do now
No feedback loops
Mapping who does the work rather than the value-adding steps
Scrum, Kanban or?
The chapter How to choose between Scrum and Kanban is according to the author very short and rather obvious. Too short in my opinion if you want to use this to choose between frameworks like SAFe, LeSS or others.
The book ends with a 5-minute agility self-assessment to understand where to start to become more agile and a recap of the coaching questions to support the three agile secrets.
Better Agile is a practical, easy to understand guide to continuously improve your agility. It gives insights in some common mistakes in Scrum and Kanban. It shows how to optimize for flow, how to get the right people doing the right things and the impact of the right feedback loops on the product as well as the team effectiveness. The 55 coaching questions and the 5-minute agility self-assessment are helpful. What I miss is a fourth secret regarding the agile mindset and culture. The organization’s culture is often at odds with the agile culture and that’s a key reason why agility isn’t improving. Finally, I have my doubts if, after reading this book, you have the skills to make an informed choice about any method, including frameworks for scaling agile. See e.g., my articles The evolution of agile frameworks and The bird’s eye view on the agile forest.
Happy to see that the Project Management world Journal published my featured article Portman, H. (2022). Project management maturity and excellence models: Stirring in the fruit bowl; PM World Journal, Vol. XI, Issue II, February. In this article I look at different maturity and excellence models in project management. At this moment around 50 different models are included.
David L. Pells, Editor / Publisher PMWJ: “Five outstanding papers are included in the Featured Paperssection. … And a late entry by Henny Portman in The Netherlands, “Project management maturity and excellence models: Stirring in the garden”, makes a significant contribution to the PM body of literature that should be read by every PMO leader worldwide.”
Why maturity models or excellence models?
The success rate of projects is still very low. If I look at the latest figures from the Standish Group (CHAOS 2020 – Beyond infinity) 60% or more, depending on your approach (agile or waterfall) is not successful. This is already for several decades the case!
To improve the way you are running projects, there are several paths to follow. You could look at the way your organization is doing projects. Or with other words how mature is your organization in doing projects? Some well-known maturity models are CMMI, OPM3, and P3M3. Another approach is to look at individual projects and ask how well this project was performed? Think about all those yearly contests that are running. E.g., the IPMA Global Project Excellence Awards, the PMO Global Awards, and the PMI Project Awards.
When you want to say something about maturity you have to look at the standards an organization has set and how they apply those standards to their projects. If one project is using the standards and another project uses a different or no standard this is a signal the organization isn’t mature in project management. You could even go further and compare the results found with industry average figures by using the same maturity model to understand your strengths and weaknesses compared with competitors. I also used maturity models to compare different business units within the same organization to find spots for improvement in one business unit and used ways of working of a better performing business unit in the same area. In this case you don’t need absolute figures, but relative ones will work too.
As an organization you could be less mature but still have an award-winning project. The award programmes are not maturity assessments!
To download the complete article Portman, H. (2022). Project management maturity and excellence models: Stirring in the fruit bowl; PM World Journal, Vol. XI, Issue II, February.
The book The good mate – How understanding team relationships can make you happier and more productive, by James Johnson and Evan Sorensen, offers the tools and shows the needed skills for successful team relationships. The book combined two decades of research (Standish Group) on emotional intelligence behavior of project teams with 40 years of research on successful marriage and family dynamics.
You are master of your destiny
The research tells that you are the only person who can improve you. The book is about how to make you happier in a place where you spend much of your time – at work, with your team. It is very unlikely that you will be able to change their behavior. In fact, it is very likely the harder you try to do that, the less successful and more frustrated and unhappy you will become. Your behavior will dictate how your teammates treat you.
A step towards project success
You must become one with your team. In other words, you must be synchronized with your teammates while you improve your own emotional maturity skills.
To do this, you, and your teammates:
must have a good, clear, and agreed-upon understanding of the project
Need to know the skills required and how they relate to the organization’s goals for the project.
Principles and skills
The authors have distilled 10 principles to build a better team by becoming a better teammate. Each principle is discussed in a separate chapter where five associated “soft skills” are discussed in detail (in total 50 soft skills). Every chapter ends with a quiz, a how to and an individual daily exercise and checklist. In each chapter a married couple Sue and John give their daily exercise outcome.
InspirationMaintaining a positive perspective Keeping promises AwarenessEmpathy
Solution understanding Value managementBuilding consensusThe art of the compromiseClarity of purpose
Managing defensivenessEliminatingDestructive criticismDeveloping good ritualsUse of analogiesAttentive listening
Decision acceptanceSubject matter expertiseCompetencySharing the factsKnowing how to deliver bad news quickly
Good mannersLeading with your best selfConnectionsDemonstrationManaging expectations
Becoming a good ‘confrontationist’
NegotiationManaging trade-offsSolving solvable disagreementsManaging unsolvable disagreementsDealing with a toxic person
Advocating honorCreating a shared meaningBeing all-in for the teamEthical appreciationMaintaining objectivity
SpeedProgressionReducing decision latencyParticipating in retrospectivesBeing on the same page as your team
In the book you can find different ways to become a good mate. To mention a few: by reading individual chapters and doing the associated individual exercises or complete the good mate appraisal and benchmark or you could execute as a group the guide to good team workshops. In the appendices you can find the guide to good team group workshops, general exercises, and mate map exercises as well as the script The public execution of miss Scarlet.
In the latest report CHAOS 2020: Beyond Infinity the Standish Group has determined three factors (good sponsor, good team, and good place) that most seriously affect the outcome of a software project. This book helps to create a good team starting with yourself. It describes 10 principles including five associated “soft skills” each, to build a better team by becoming a better teammate. Each principle is discussed in a separate chapter where five associated “soft skills”
AI and more specific AI and project management gets more and more attention. The key to this development, however, is project data. Getting started in project data is a report that helps you to get a first understanding of project data analytics.
The guide from the APM contains contributions from Alex Robertson, Andy Murray, Gareth Parkes, and Martin Paver.
Project data analytics is the use of past and current project data to enable effective decisions on project initiation, delivery, and efficient automation of project tasks. This can be done in three ways:
by using algorithms to respond to data inputs to perform routine tasks faster with fewer errors than if processed manually
by collecting, cleaning, analysing, structuring, and presenting data in the most effective format to make better decisions
by using it to predict future performance to make timely decisions and actions.
The report shows how you can make a tactical start and take a strategic approach with project data analytics.
The book AI and the project manager – How the rise of artificial intelligence will change your world, by Peter Taylor, is probably one of the first where we see the link between Artificial Intelligence (AI) and project management. It gives insights into what is out there with regard to AI in project management. Gartner states that by 2030, 80% of the work of today’s project managers will be eliminated as AI takes on functions such as data collection, tracking, reporting, analytics, and predictive analysis.
The book starts with some definitions:
AI is the designing and building of intelligent agents that receives percepts from the environment and takes actions that affect that environment.
Artificial narrow intelligence (ANI) or ‘Weak’ AI is AI that exists today (e.g., play chess, analysing data to produce reports, Siri, Google Assistant, et cetera).
Artificial general intelligence (AGI) or ‘Strong’ AI refers to machines that exhibit human or adaptable intelligence. As such there are no real-world examples of ‘Strong’ AI.
Besides these you get definitions of Machine Learning, applied intelligence, deep learning, responsible AI, predictive analysis, computer vision, natural language processing, intelligent automation and dark data.
The author distinguish four main categories of AI related to project management:
Project management process automation (auto-scheduling, automatically tracking progress and status of tasks, exception based management)
Project intelligence through machine learning (supervised, unsupervised, reinforcement and rules-based learning)
The future state of the autonomous project manager (no real life examples)
Having the data is key in AI. Unfortunately projects are complex to model, but typically they have poor historical data and factors that are hard to understand (i.e. behavioural aspects of various actors). Any historical data is heavily biased, subjective, and unreliable as more often than not it did not reflect real delivery detail or accurate completion rates.
Some AI use cases
In the book many use cases for using AI. To mention a few:
The ultimate goal, of a supplier of AI driven PM software, with machine learning should be to automate data insights on project delivery, help project teams spot problems early, and identify where best to focus project management efforts to continually reduce the uncertainty and increase the probability of delivering project outcomes.
Another supplier wanted to use technology and data in order to understand what made projects succeed or fail and prioritise leveraging the knowledge of the people behind them (people data) and not simply the traditional project data (when the task is complete) most people used. Or can machine learning support the ability to ‘match’ people on he projects they would be most passionate about working on.
Project are about people
Project managers, in the ‘new AI normal’ world is still about people and will:
use all of that AI insights and predictable capability
really have time to get to grips with complexities of people and teams
build and lead incredible project teams into a single purpose-driven powerhouse.
The book ends with some thoughts on the future project manager (can anyone do project management, will certification be valueless, will we abandon methodology, are professional bodies irrelevant and will our skills be devalued) and AI in project management survey response details.
This book shows that AI is not the silver bullet to solve all our project related problems. The book gives many AI examples from ideas to realised AI solutions. For those who aren’t familiar yet with AI and project management you get some first insights, definitions, and AI use cases. It will help to start a discussion where you can benefit from AI. for sure, project managers can definitely benefit from AI and use their scarce time to focus on people! But I am not sure yet, if in 2030 80% of the work of today’s project managers will be eliminated.
IPMA OCB offers insights for all interested in understanding how to improve the way projects, programmes and portfolios are managed in an organization.
The IPMA OCB provides a standard for organizations to analyse their context, to identify relevant trends and to develop their strategies, processes, structures, cultures and project, programme and portfolio competences.
The IPMA OCB describes five groups of of organisational competence:
Project, programme and portfolio governance
Project, programme and portfolio management
Project, programme and portfolio alignment
Project, programme and portfolio resources
Project, programme and portfolio people’s competences
Each competence is divided into three or four competence elements and are explained in detail.
Appendix A provides a more detailed description of the competence elements including the intended users and their responsibilities and some key questions that organizations should consider.
Appendix B provides an outline of a competence development programme.
The IPMA OCB is one of the three standards used as reference models during the IPMA Delta maturity assessment: the IPMA Individual Competence Baseline (IPMA ICB) to assess selected individuals, the IPMA Project Excellence Baseline (IPMA PEB) to assess selected projects and/or programmes, and the IPMA Organisational Competence Baseline (IPMA OCB).
IPMA Delta uses the concept of competence classes to help assess the current project management state of an organization. IPMA Delta follows a similar approach as other assessment systems like CMMI (initial, defined, standardized, managed, optimizing).
As a result, the assessment report shows the class of competence for each IPMA OCB competence cluster. The actual class and the difference (“Delta”) to the desired competence class, combined with detailed findings, can be used to derive development needs and a long-term strategy for organizational development of project, programmes and portfolios.
Conclusion. Like all other IPMA standards a very relevant standard for those who want to strengthen their project, programme and portfolio competences and need a baseline. When I look at those organizations with permanent agile teams, I think this standard needs an update to show the impact of these agile ways of working on the organization’s project, programme and portfolio competences.
To order a printed copy of the IPMA OCB (or to get a free Ebook): IPMA World
My ‘bird’s eye view on the agile forest’ gives a fairly complete picture of the different agile frameworks. I only adapt it when I come across really deviant frameworks. This time it’s MAHD.
Modified Agile for Hardware Development (MAHD) Framework was developed by Gary Hinkle and Dorian Simpson. It is similar to agile for software methods, but with critical differences. The MAHD Framework uses the principles of Agile to develop physical products in less time, with reduced risk and with higher customer satisfaction. Many companies have attempted applying Agile for SW methods directly to physical products with mixed results. Teams often struggle since current Agile steps, techniques and even language were not optimized for hardware development. A modified Agile approach can leverage the power of Agile, while addressing the unique needs of hardware development.