The book Project, Programme and portfolio governance (P3G), by Ross Garland and Adrian Morey is a comprehensive and practical guide to realize optimum outcomes and benefits characterized by:
Right decisions at the right time
Right people in the right roles
Right accountabilities, responsibilities and delegated authority
Right structure
Right information.
The book is divided into 5 chapters. The Introduction chapter discusses the target audience (governance body members, project, programme and portfolio managers, PMOs, …)., the organizational context and the benefits of effective and efficient P3G. The second chapter – What is P3G? – gives definitions of projects, programmes and portfolios and their relationships. It summarizes the fundamental components of a P3G framework – structure (avoid decision-making gaps and overlaps), people (focus on roles, not people) and documentation (investment grade artefacts). These components are explored in the next chapters via principles and their application.
Chapter 3 – principles of P3G, forms the main part of the book. P3G is based on ten principles of effective and efficient project, programme and portfolio governance:
Principle 1: Treat Change differently from Business as Usual
Principle 2: Ensure a single point of accountability for each project or programme
Principle 3: Business outcome accountability determines project or programme accountability
Principle 4: Support the person accountable for a project or programme with a governance board
Principle 5: Separate project and programme decision-making from stakeholder engagement
Principle 6: Align investments with strategic objectives.
Principle 7: Maintain the business case
Principle 8: Design portfolio governance to drive investment outcomes
Principle 9: Ensure consistent and logical decision-making rights
Chapter 4 – Application of principles: Implementation – discusses the need for scalability, a risk-based approach to determine the degree of governance required on a project or programme, what it means to establish, document and communicating new or enhanced P3G arrangements and the impact of agile delivery approaches.
The final chapter gives four case studies to show the application of the principles. Case studies regarding a basic project, complex programme, standing programme boards and portfolio governance models.
In the appendices you get an explanation of the business case box, role statement examples, terms of reference templates for governance bodies, in-room practices and behaviours, an enterprise P3G framework template, P3G and organizational maturity and standard governance forms.
Conclusion. If you are familiar with PRINCE2 (Agile), MSP, MoP, P3O and P3M3 you can find a lot of recognition regarding project, programme and portfolio board composition, roles and responsibilities, usage of tolerances (management by exception) and continuous business justification. I like the principles approach; this makes it less prescriptive. New are the SRO and project sponsor delegate roles. Accountability (principle 2 and 3) is strongly positioned. Also, the emphasis on decision-making rights is definitely an improvement.
What I miss is the governance needed by organizations who made the transition towards an agile organization with permanent cross-functional agile teams. This is much more than a temporary project organization using an agile delivery method. I would call this product governance (P4G?) with at least a quarterly heartbeat to define the initiatives for the coming quarter and not, as described in the guide, an annual cycle. Here you don’t see temporary project or programme boards but quarterly business reviews with business owners, product owners and delivery teams to look backwards, did we deliver what we promised, and look forward, what can we do differently next period and what are the objectives and underlying initiatives for the coming period, in many cases supported by an Obeya room.
In the book Agile portfolio management (EN Amazon, NL managementboek), I wrote together with Rini van Solingen I would position P3G at the left side of the continuum from plan-based portfolio management to discovery-based portfolio management.
If your organization is positioned at the plan-based portfolio management side, this book is definitely a must read.
2022 was again an extremely fruitful book review year. As one of the 6 judges for the managementboek of the year contest I read 90+ books. We agreed to be very careful when writing about these books, so with some exceptions you will not find those reviews on this blog. You can stil find around 30 book reviews including 10 corresponding quick reference cards and several personal insights, and views on specific topics in the field of project, program and portfolio management, as well as many articles and a new book from my own hand.
Agile by Rini van Solingen and Maarten Kossen was originally published in Dutch. This first English version could be seen as a third edition (see below for the differences between this and the second Dutch edition).
The book starts with a warning that agile is more than a mindset, it is a philosophy, followed by 22 chapters, in which the authors show that it is easy to understand, but very difficult to apply at first.
In ‘The why, what when and how of agile’, we immediately encounter the beautiful submarine-dolphin metaphor (waterfall versus agile). Furthermore, several fundamental fallacies that agile solves. Agile is a mindset elaborated in 4 values and defined by 12 principles and made practical in dozens of approaches and implemented through infinite practices. Finally, using the Stacey matrix, we gain insight into when you should or should not adopt agile working.
‘Are we heading in the right direction’ offers seven questions to see how agile one is and also the usefulness of metrics such as velocity, happiness, value, energy, productivity, autonomy and focus.
In ‘Agile by finishing’, we get six practical measures to speed up work: make finishing central, cut up and detach, many and small releases, automate everything, utter independence and measure impact and returns.
In ‘Dangers of agile’, we are presented with eight dangers of agile working including agile working is harder than it looks and the requirements for a product owner are unrealistic. Seven misconceptions about agile are also elaborated such as, for example, documentation is no longer needed in agile and agile teams do not need management.
‘Scrum or agile?’ describes Scrum and brief explanations of Kanban, Scrumban, Scrum/XP.
‘Quality of agile’ gives seven reasons why agile enforces quality: rhythm and regularity, quality is explicit and fixed, continuous learning process, value as a steering instrument, no more big projects, automation of quality and autonomous teams. Furthermore, the authors explain the importance of the Definition of Done.
‘Agile transformations’ offers eight well-proven steps in practice: run an initial assessment, formulate the why and the urgency, work out a blueprint, determine the change strategy, create a transformation roadmap, execute the roadmap iteratively in sprints, meet and revise the roadmap and, as a final step, integrate through governance and culture and the paradox of controlled flexibility.
‘Pitfalls of agile transformations’ describes seven pitfalls including the importance of a new rhythm is not understood, fear of failure reigns and there is only attention for process.
‘Agile Culture’ offers seven measures to create an agile culture: focus on the why, change the context, put self-managing teams first, make culture explicit, be the culture yourself, work according to a fixed rhythm and stimulate servant leadership. How you can make your agile culture measurable is the last topic in this chapter
‘Agile leadership’ is about the ownership model with the two dimensions freedom and maturity and seven steps to create your own ownership model. We also find here a summary of Rini’s business novel The Beekeeper.
‘Management teams and agile’ answers the question what will change for management teams if they themselves switch to agile working too. The focus switches to prioritizing at strategic portfolio level, purpose- and mission-oriented positioning of the teams and implementing systemic improvements. What does that mean for all existing scheduled meetings? Several topics will disappear from the agenda and replaced by other tasks.
In ‘Agile governance’ you can find seven measures for agile governance such as work with stable teams and short iterations and plan the work not the people
‘Agile strategy and portfolio management’ describes that true agility also requires agile at a strategic and portfolio level. Seven recommendations for agile strategy and eight measures for agile portfolio management are given: set up short-cycled portfolio management, reduce the number of parallel initiatives, shift portfolio control to delivered value, express choices in terms of possible scenarios, options, and hypotheses.
‘Product ownerschip’ presents nine pitfalls for product owners such as wanting to do everything themselves, assuming mandate and saying ‘yes’ to everything. Furthermore, eight attitudes that successful product owners distinguish themselves from a their less successful colleagues.
‘Agile coaches’ gives answers which coach fits best in your organization depending on the need, the phase of the transformation, issues, and the corporate culture. Get clear what needs are in play, draw up a coach profile and determine which type of coach fits best. The author gives seven types of coaches: the artist, the evangelist, the Viking, the mediator, the professor, the networker, and the innovator.
‘Quality through autonomy’ explains seven measures to increase quality in agile such as automate all quality checks and remove third party dependences.
‘Agile at scale’ highlights seven focus points for scaling agile and explains SAFe including SAFe PI planning and its seven-step preparation. It includes brief paragraphs on Srum@Scale, Spotify and Enterprise Scrum too.
‘Large scale agile challenge’ gives seven root causes of failing agile and ten interventions to add control to large scale agile.
‘Agile sourcing and contracts’ offers eight questions about agile sourcing and six principles for agile structures in contracts as well as how these principles have been implemented at a software vendor CALVI. It ends with an explanation how to do an agile tender.
‘Agile and fixed price’ discusses whether agile can also be fixed-price and four associated measures for fixed-price agile are given.
The final chapter ‘agile estimating and planning poker’ explains how planning poker works and gives ten tips for planning poker.
Conclusion Beautifully formatted, calm soft colors and beautiful photos. Agile is a mindset and a philosophy and that splashes off the pages! The book is peppered with listings of pitfalls, roadmaps, thinking errors, reasons preconditions and dangers that greatly increase the practical applicability of this book. The descriptions of cases at bol.com, ANWB, Eneco consumers and software vendor CALVI help. If you are thinking of or just started an agile transition, this is a perfect book to be read by all involved. Of course, it is also excellent for learning about the agile mindset and philosophy.
Changes in comparison with the Dutch second edition:
The book now starts with a warning that agile is more than a mindset, it is a philosophy
Brief explanations of additional frameworks besides Scrum: Kanban, Scrumban, Scrum/XP
New chapter ‘Management teams and agile’ What will change for management teams if they themselves switch to agile working too? The focus switches to prioritizing at strategic portfolio level, purpose- and mission-oriented positioning of the teams and implementing systemic improvements. What does that mean for all existing scheduled meetings? Several topics will disappear from the agenda and replaced by other tasks.
Chapter about ‘Agile strategy’ is adjusted to include portfolio management too. Eight measures for agile portfolio management are discussed.
New chapter ‘Value steering for product owners’ What is value and eight measures to make steering on value concrete.
The chapter ‘Agile at scale’ describing SAFe now includes brief paragraphs on Srum@Scale, Spotify and Enterprise Scrum too.
The chapter ‘Agile opdrachtgeverschap’ is replaced by ‘Large scale agile challenges’ (seven root causes of failing agile at scale and ten interventions to add control to large scale agile)
The chapter ‘Agile contracts’ is expanded. It’s now called ‘Agile sourcing and contracts’. Two additional paragraphs with ‘Eight questions about agile sourcing’ and ‘How do you do an agile tender (derived from the removed ‘Agile opdrachtgeverschap’ chapter) are added’.
Now that I am working on a book on agile portfolio management, I was curious about this book. Looking at the title I was thinking am I too late? After reading the book I am even more energized to deliver the agile portfolio management book. This book is all about prescriptive or control-based portfolio management.
The outcome-driven organization – Your project portfolio running on espresso 2nd Edition, written by Linda E. Szmyt and Fernando Santago gives you a project portfolio management set up comparable with Management of Portfolios (MoP) from Axelos/PeopleCert and Managing Benefits from APMG. The authors want to see transparency, a sense of fairness, as well as visibility and predictability across the portfolio. That’s what they call a project portfolio running on expresso. They move away from a focus on scope and work, to one driven by outcomes and business results.
Investment types
Throughout the book 6 types of investment are used: mandatory/legislated, keep the lights on, optimize current operation, grow the business, transformational, venture. Compare the buckets in MoP (in MoP you can differentiate from these types. E.g., covering your main strategic objectives). What I miss is a discussion regarding allocation of funds across these buckets. Prioritization within the buckets or investment types is based on adjusted NPV and IRR taking delivery and benefit risks into account.
For each investment type you get an overview of activities needed for the realization of the benefits, the rigour required and the usage of a business case as the cornerstone for managing a portfolio to maximize value (I don’t agree that there is no need for a business case for the mandatory/legislated investment types. Here, the business case can be used to show do nothing, bronze, silver of gold solution scenario’s and use that in your decision-making).
Benefits management
Benefits management is all about calculation of financial indicators like NPV, IRR and EVA/EVM and benefits forecasting. The benefits map is explained in detail and shows outcomes, capabilities and initiatives including propagation of inflows to initiatives and outflows. An explanation of the importance of the role business change manager connected to the benefits is lacking. Those who are responsible for realizing the benefits. With these people you can discuss what outcomes/capabilities are needed. Benefits performance index (BPI) and or realization performance index (RPI) as additions to the schedule and cost performance indices from EVA/EVM are discussed too.
Agile
On some places you see very brief additions regarding agile. But remarks like “this is not very different than a project following a predictive approach and delivering in phases that add more functionality to a capability” is too easy. Or “projects that follow an agile approach are not that different from other projects when it comes to the realization of benefits”. I would say that if you have an incremental delivery of benefits, you can benefit of regular feedback, deliver a better product, and reduce benefit risks.
Portfolio reporting
“Red” initiatives including expected ROI and level of risk are important. The authors show what information is needed to maximize value at the portfolio level. E.g. the current and expected IRR at portfolio level, the target split percentage between operational and transformational projects. The investments metrics showing for each RAG-status and project stage the total investment or IRR. This could give a completely different picture if you show the number of projects. Another view is the investment versus delivery and benefit risk.
Conclusion. A good overview of prescriptive or control-based portfolio management. The set up of portfolio dashboards with indicators at portfolio level are much better than looking at only lists of projects and their RAG-status. But…
You can create great reports or dashboards based on financial figures but it’s jiggling with balls. It gives the impression that you use a data driven project portfolio approach, but I doubt it. There are so many assumptions behind those figures (e.g., the outflows, the contributions, the delivery and benefit risk adjustments, et cetera) that you may wonder if you are kidding yourself. This asks for scenario thinking, continuous validation, checking hypotheses with MVP’s and RATs, and execution flexibility among other things but that will be covered in the agile portfolio management book I am writing together with Rini van Solingen. By the way the authors see the MVP as the minimum marketable product (MMP) and not as an instrument to test, with minimum effort, a hypothesis.
The professional agile leader – The leader’s journey toward growing mature agile teams and organizations by Ron Eringa, Kurt Bittner and Laurens Bonnema provides a detailed understanding of the leader’s role in an agile transformation.
When talking about reasons why so many agile transformations fail, I often show a picture of two rhinos colliding, and saying that this is the reason why. Next, I add two text boxes over the rhinos with company culture and agile culture. I can now refer to this book if you want an in-depth explanation of this clash.
The book is divided in eight chapters. the first chapter zooms in on the situation where you see yourself as an organization being overtaken by competitors. You may be very efficient but too unwieldy to respond quickly to the many changes that come your way. One solution is to take over another company that is already much more agile. This is also the case in the book where Reliable Energy takes over Energy Bridge and we follow the CEO who wants to make her organization more agile.
The second chapter shows what it means to form empowering cross-functional teams who discovered their purpose and the role of the leader. Key is that the teams must form themselves and that this takes time.
In the third chapter the emphasis is on the impact. Forget output but focus on the impact by framing goals in terms of customer outcomes instead of things that are produces. From plan-driven goals to goal-driven planning (tactical – intermediate – strategic goals).
Chapter four shows how teams and their leaders are changing by becoming more feedback driven. This is all about decision latency, levels of delegation, decentralized decision-making, and intrinsic motivation.
In chapter five we see the issues leaders are facing when they are halfway their agile transformation. This refers back to the clash between the rhinos at the start of this review. The original way of working with checks and balances versus the agile mind mindset and what that means to the people involved. Self-managing teams require leaders with a catalytic leadership style (collective focus: sharing, enabling, diversity, acceptance and supportive).
Chapter six shows that in an agile organization less and less hierarchical leaders are needed but all the more agile leaders. Where leadership should be seen as an activity and not a role. How to grow new leaders, how to grow mature teams and to escape the silos by breaking them down.
In chapter seven the authors explain that Kotter’s dual operating system cannot be used for ever. At a certain point you must decide to fully go for the agile way otherwise you will fall back to the old ways of working. I am not sure if this is what Kotter has in mind with his dual operating system.
The final chapter puts the agile culture in the spotlights. The social behavior and norms that people in the organization exhibit, including their beliefs and habits. Without this agile culture your agile transformation will fail and be aware this transformation will never end.
Conclusion
a compact and easy to read book that explains the role of a leader in an agile transformation in a clear, straightforward, and practical way. the case used of a merger of two companies as a common thread makes very clear the issues and friction a leader faces in an agile transformation.
I missed the agile leader’s role in sharing knowledge and lessons learnt by setting up communities of practice (CoPs), chapters, guilds et cetera. The issues and what to do about them when multiple teams are necessary to work on a single product are presented very simplistically but this is probably beyond the scope of this book.
In my opinion an absolute must read if you are in the middle of or want to start an agile transformation.
The book PMO Services and Capabilities – Including an overview of AIPMO’s competence framework – Competences per PMO service – Techniques and tools per PMO service is written by Robert Joslin. This book is unique as it addresses in a systematic and structured way for each PMO service including the associated attributes how to implement service to provide the right service to the right people at the right moment.
Each organizational unit is unique, each organizational unit needs its own set of PMO services.
The book is divided into two parts:
The first small part contains a high level overview of AIPMO’s services lifecycle framework (service strategy, service design, service pilot and implementation, service operations, service transform or retire) as part of AIPMO’s methodology on how to build and implement a PMO services and capabilities catalog
The second main part lists the PMO services that are in service groups and listed under the 22 service domains.
There are over 220 PMO services described in this book. The book is based on a three-level categorization system that allowed services to be grouped (service groups) with a service domain. A service domain is related to an area of experience. There are 22 service domains explained.
Each service domain is broken down into one to three service groups (in total approximately 60). A service group is related to one of the three main activity types that the PMO is expected to do:
Design – a PMO can provide the standards, tools, templates, processes, procedures, help, guidance, framework that defines how work will operate within that particular service domain
Operate – a PMO can operate (or perform) some of the work on behalf of other people within the project (program or portfolio) team. If the PMO does not perform this service then, if this is performed at all, then this will be done by another member of the project (program or portfolio) team
Monitor – a PMO can review the work done by others and provide and independent quality assessment and check. They can provide reporting across the service domain and highlight items that require escalation.
Not all of the PMO activities fall neatly into the 3 groupings. For some of the services activities are categorized in a more relevant way. This has been done for ease of comprehension as it fits more naturally into how the service domain operates.
The 22 service domains explained in the book are: integration management, stakeholder management, communications management, governance, frameworks and methodologies management, PPM tools management, consultancy, portfolio management, benefits management, financial management, schedule management, risk management, quality management, supplier management, capability and capacity management, configuration management, change management, issue management, administrative management, innovation management, knowledge management and PMO self-development.
To give an example for the portfolio management service domain, its domain services and services.
Within each service group there are one or more services. A service is the lowest level of offering that a PMO can provide. The service domains are grouped into four clusters (conceptualization, planning, execution and safeguarding the future).
Each service has 2 audiences:
The PMO How the service should be performed and some hints and tips that the PMO should consider when performing the service.
The customer Why do you want to get this service, what would you expect to be delivered from this service, and why would you benefit.
For each service you get a description, what it provides for the customer, why is it being offered to the customer, SIPOC (Supplier, Input, Process, Output and Customer), demand triggers, measurement indicators, tips and tricks, needed capabilities (organizational enabler capabilities, personal capabilities, service domain capabilities, techniques, tools) and references to related services. Each service ends with suggestions for further reading.
Conclusion: I have never seen such a complete overview of PMO services for a single PMO. 1,7 kg heavy, 22 service domains with in total 60 service groups and more than 220 services. On the other hand, it isn’t complete. For sure there will be PMO’s offering services that are not explained in this book. New developments take place. E.g. the rise of Value Management Offices with their own specific services. But this is something the author mentions too and solutions to cover this will be offered in the near future. The book is structured as a reference work and will bring a lot of value for those involved in PMO’s. If you are involved in a PMO setting this is definitely a must have.
The only struggle I have is to find the place where a service is explained. Table 2.1 shows the service group mapping, but the services themselves aren’t mentioned. I would suggest replacing the domain number with the chapter number used in part 2 where all the services are explained. See also my example regarding portfolio management.
I am looking forward to some other titles AIPMO is preparing. E.g. Project, Program, Portfolio, and PMO Competences Frameworks: Designing for Successful Outcomes.
To order PMO Services and capabilities: bol.com, amazon
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.
Conclusion
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 builds
Software testing (is it bug free)
Customers
End-users
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:
Water-Scrum-Fall
Multi-sprint stories
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:
Task-board only
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.
Conclusion.
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.
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.
Principle
Soft skills
Becoming influential
InspirationMaintaining a positive perspective Keeping promises AwarenessEmpathy
Solution understanding Value managementBuilding consensusThe art of the compromiseClarity of purpose
Communication
Managing defensivenessEliminatingDestructive criticismDeveloping good ritualsUse of analogiesAttentive listening
Acceptance
Decision acceptanceSubject matter expertiseCompetencySharing the factsKnowing how to deliver bad news quickly
Respect
Good mannersLeading with your best selfConnectionsDemonstrationManaging expectations
Becoming a good ‘confrontationist’
NegotiationManaging trade-offsSolving solvable disagreementsManaging unsolvable disagreementsDealing with a toxic person
Civility
Advocating honorCreating a shared meaningBeing all-in for the teamEthical appreciationMaintaining objectivity
Being driven
SpeedProgressionReducing decision latencyParticipating in retrospectivesBeing on the same page as your team
Different ways
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”
Henny Portman's Blog 