In case you haven't heard, PMI's Mike Griffiths has a new book out, Beyond Agile: Achieving Success with Situation Knowledge and Skills. Mike is a well known and respected thought leader within the agile community.  To be transparent, Mike is currently an employee of PMI, working on the Disciplined Agile IP team with me, and he is a long-time volunteer with PMI and contributor to PMI publications.  

So why is one of the Disciplined Agile (DA) guys recommending a book titled "Beyond Agile"?  Simple: The material in this book is incredibly complementary and confirmatory to what we recommend in DA.  Here's what I like about Beyond Agile:

1. It promotes a hybrid strategy. Just like DA, the Beyond Agile approach recommends mixing a combination of lean, agile, and traditional strategies.  And it recommends doing so for both project teams as well as long-standing teams (such as product and service teams).  
2. Context counts. A common theme throughout the book is to do what is right for the situation that you face.  So there are no best practices, rather there are practices that work well for you given the context of your situation.  Furthermore, having industry-specific knowledge and experience is a part of that - what works well for the automotive industry may prove to be a mess for the financial industry, and vice versa.
3. It addresses people issues. The book offers a lot of great advice around people-oriented topics.  This includes emotional intelligence (EI) and emotional quotient (EQ), both intrapersonal and interpersonal skills, leadership, servant leadership, and working with stakeholders. Just this material alone is worth the price of the book (and the rest of the book is great too). 
4. It addresses process issues, particularly those critical for project professionals. One of the greatest frustrations that project professionals have with many agile writings is how they avoid, gloss over, or provide naive advice around issues that are critical to your success.  Luckily this book doesn't make that mistake.  It provides proven strategies for when (and when not) to take a plan-driven approach, how to work effectively with project management offices (PMOs), performance analysis and reporting, estimating time and cost, and risk management to name a few key topics. 
5. It covers organizational change. Adopting more agile ways of working is a change for many teams and their organizations.  The book covers several key topics in this space, including Frederic Laloux's organizational model and several organization change models (Kubler-Ross, Satir, ADKAR, Kotter, and SCARF).  While the book won't make you a change expert, it does cover critical models that you may want to explore in greater detail.  You may also find the offerings of PMI's BrightLine to be of value.
6. It's consumable.  This book is well-written and an easy read.  There are a lot of pictures including great cartoons.

There are several compelling reasons to read Beyond Agile: Achieving Success with Situation Knowledge and Skills. In summary, Mike says it best on his page describing the book:

Beyond Agile is for project practitioners, PMOs, and business representatives who want relevant, high-value delivery guidance. The book presents a model that provides a context-specific approach from a full spectrum of project disciplines including: lean/agile, leadership/EI, plan-driven, and industry-specific approaches. Unlike scaling models such as SAFe, LeSS, and Nexus, the Beyond Agile Model avoids agile-myopia (believing everything can be solved best by agile approaches) and buffet-syndrome (taking on too much process) by being simultaneously broader but ruthlessly selective in its recommendations.

Recently I've been asked by several people about what I believe is the future for PMOs.  My answer, of course, is that it depends.  It depends on what your current strategy is today, how forward thinking your leadership is, and what you believe your PMO's role should be in your organization.  

To better understand your current strategy and leader, considering the following questions:  

1. How effective is your existing PMO?  Is it adding real value to your organization? Is seen as doing so by your leadership?  Do you have measures to support these claims?
2. How adaptable is your existing PMO? Does your PMO have a track record of embracing new ways of working (WoW)?  How well does your PMO react to change?  How well did it react to the changes required to face the  COVID-19 crisis?
3. How respected is your PMO? Do the people your PMO is meant to be guiding want to work with your PMO or do they merely tolerate it? The support of these people will be crucial as your PMO evolves to meet new challenges.
4. Does your PMO focus on more than just projects? Projects are one type of endeavor your organization has going on. You very likely have long-lived product teams that are a critical aspect of your value streams, service teams that support people throughout your organization, and operational teams that focus on running your business, to name but a few.
5. Is your PMO outcome focused? Does the PMO focus on ensuring that your organization's endeavors provide real value to their stakeholders, or are you merely concerned with simplistic "on time, on budget" issues?
6. How flexible is your PMO? Is it able to support teams with different WoWs - agile, lean, hybrid, and serial - or does it insist teams follow a consistent, "predictable" process?

The current state of your PMO will be an important determinant of how it will choose to evolve and whether it will be able to evolve to meet the challenges of the VUCA world in which we all operate.  Potential futures for today's PMOs include:

1. Evolving into a lean governance body. Lean governance is an important aspect of PMI's Disciplined Agile (DA) tool kit. The lean governance mindset is different, focusing on motivation rather than conformance, on enablement rather than inspection, on flow of value rather than delivery of artifacts.
2. Evolving into a value management office (VMO). Rather than delivery of successful projects, a VMO focuses on the successful (and often continuous) delivery of customer value. For individuals, this will necessitate a shift to focusing on value stream management rather than project management. Mark Lines and I recently wrote a foreword for the forthcoming book From PMO to VMO: Managing for Value Delivery by Sanjiv Augustine and others. I suspect this book will be a game changer for many PMOs.
3. Evolving into an adaptive PMO. Many PMOs will choose to get better at being PMOs.  They'll become more flexible, adaptable, outcome focused, and value focused. This will require project management professionals to learn critical continuous improvement skills, exactly the skills you gain via Disciplined Agile certifications.
4. Dissolution. Some PMOs may find that they are no longer needed, their primary responsibilities being automated via artificial intelligence (AI) and other technologies and by other organizational groups taking over their remaining responsibilities.  A PMO may not be dissolved completely, at least not right away, but certainly can be reduced substantially.

Your PMO may choose to follow a combination of the strategies that I listed above, and in future blogs I'm going to explore each one in greater detail.  I believe that today's PMOs face an important turning point, one that has been coming for years but has now been brought forward by the pandemic, where they must choose a new path if they are to survive, and better yet thrive.  Which path is right for you?

NOTE: This article was originally published in the spring of 2011 in Dr. Dobb's Journal.  The magazine is unfortunately defunct now, and some of the material is now disappearing from the original site, including the original publication of this material. I was recently asked if I still had the original, so I have decided to repost this here.

What follows is my original, submitted article before copy editing.  So there may be differences compared with what was originally published.  For this publication I have removed some links which are no longer valid (hey, it's been 10 years).

What We Believe: A Non-Update to the Agile Manifesto

The Agile Manifesto had its beginnings in a meeting held in February 2001 at the Snowbird ski resort just outside of Salt Lake City.  To celebrate the ten year anniversary of this event Alistair Cockburn, who organized the original meeting, invited a group of agile luminaries back to Snowbird to discuss the future direction of agile.  The original 17 manifesto writers were invited, although not all were able to attend, and I was among the people who did participate.  In this newsletter I discuss what we concluded, how the event was organized, and some of the challenges faced by the agile community. 

What We Believe

First, let’s jump to what most people will perceive to be the end results. As a group, we agreed in the following four belief statements:

1. Demand technical excellence 

2. Promote individual change and lead organizational change 

3. Organize knowledge and improve education 

4. Maximize value creation across the entire process

Let’s dive down into what these belief statements imply.  The first statement, demand technical excellence, is a reflection both of the general values of the working group and also our frustration with what we’re seeing in practice – or more accurately not seeing in practice.  The Agile Manifesto exudes the philosophy that technical excellence is critical to your success in the software game, yet this requires both skill and discipline to pull off in practice.  Many agile teams do in fact manage this feat, as various DDJ surveys have shown over the years agile teams produce higher levels of quality on average.  However, the adoption rate of quality techniques such as test-driven development (TDD), refactoring across all architectural tiers, and following common development conventions aren’t as high as the agile rhetoric would lead us to believe.  There is room for improvement, and our hope is that this first believe statement will motivate agilists to do so. 

The second belief statement is to promote individual change and lead organizational change.  Once again, we’ve definitely come a long way as a community but we have further to go when it comes to improving our approach to software development. At the individual level I believe that we need to actively life-long learning, teach people to observe what works for them (and what doesn’t) in the situations that they find themselves in, and to then act on those observations. At the organizational level it is important to understand both the mechanics and the supporting human behavioral aspects of change processes and then invest the time and resources to effectively execute on them.  One aspect of this is to focus on the organizational ecosystem as a whole and not just on IT – in fact, many agilists are instead still mired in the details of software development and unable to see the enterprise forest for the development trees.

Organizing knowledge and improving education is the focus of the third belief statement.  Several people in the group voiced their frustration around the lack of a coherent and consistent agile body of knowledge.  In many ways this is a reflection of our times – the Internet makes it easy for people to publish articles, to post ideas in blogs, to tweet, to write wiki pages, and so on which in turn promotes a dispersed cacophony of voices.  This cacophony can be debilitating when you want resources which support teaching agile concepts, particularly at the college and university level but also at the individual learning level.  Heresy aside, perhaps an organization such as the Agile Alliance could start amalgamating some of this knowledge, and even go so far as to create an Agile Book of Knowledge (ABoK).  Minimally, it’s clear that the agile community could do more to reach out to universities and colleges to help them understand and teach agile more effectively.

Last, and certainly not least, is the fourth belief statement that we should strive to maximize value creation across the entire process.  One of the fundamental messages of the Disciplined Agile Delivery (DAD) process framework is that we need to look beyond the software construction focus of the Agile Manifesto to address the full solution delivery effort.  But this is clearly not the full picture either as there is much more to IT than solution delivery, and certainly much more to your organization that IT.  Some of the greatest challenges that we face with agile adoption are the business issues surrounding IT, particularly when it concerns financial issues such as funding delivery projects, IT governance, and understanding and interacting effectively with business stakeholders to name a few. As the lean community implores, we need to optimize the whole, and agile software development is only one small part of your overall organizational ecosystem. 

How it Happened

To help bring a bit of transparency to this event, I’d like to briefly describe how it was organized.  In early January 2011 Alistair Cockburn sent out invitations to a number of people whom he felt had added value within the agile movement over the years.  Not everyone was able to attend for various reasons, and perhaps a few people who weren’t invited should have been, but from what I could tell he brought together a group who was representative of the overall community.  I’d like to once again express my thanks to Alistair for taking the lead on this effort.

Luckily Alistair decided to hire professional facilitators, Robert Moir and Janet Danforth, to organize the event and I truly believe that we couldn’t have succeeded without the two of them.  A few weeks prior they called around to the confirmed attendees to discuss what they wanted to achieve when we got together.  We first saw the results of this the night before when we gathered in the evening for drinks and discovered that index cards containing questions had been distributed around the tables.   The goal of the cards was to stimulate conversation, not that we needed any help with that, and to communicate to everyone the range of issues to consider the following morning.

The working session itself was held on Saturday February 12^th, with an idea generation session in the morning from 8:30 to 12:30 and a focusing session held in the evening from 5 to 7:30.    During the morning session we organized into seven subgroups, and we iteratively addressed seven topics – value; agile backlash/retrospective; technical/agile process; other communities and business/enterprise process; culture; education/training, and the future – which the index cards from the night before had been assigned to.  Each subgroup started with one of the topics and with sticky notes identified issues pertaining to that category.  Then the subgroups rotated to the next category to review the previous work and to add any new ideas that were missed previously.  We proceeded iteratively until each subgroup had contributed to each topic category.  

Over the break several of us chose to go skiing, the weather was perfect and the mountain offered a range of challenging ski runs – if you downhill ski then I highly suggest Snowbird.  In parallel many people decided to continue discussing the issues identified during the morning session.  The facilitators also took the opportunity to organize our work and to prepare for getting the group back together that night.

The goal of the evening session was to come to a consensus around a statement of our beliefs.  To do this we re-categorized the issues that we identified in the morning into things that we can make good headway on, things we don’t know how to address, and things that we believe can’t be addressed.  For example, better communicating the role of architecture in agile development is something we could make good headway on whereas the fact that many organizations rate their employees in part based on the degrees or certifications is something we’ll never be able to address as a community.  The issues which we believed could be addressed were clustered by topic, the topics were prioritized, and after much discussion and wordsmithing the four belief statements were identified.

The Elephants in the Room

Late in the morning we recognized that there were several issues that we were avoiding in our discussions.  This avoidance was due in part to the prevailing culture of the agile community, in part due to commercial interests of several people in the room, and in part because we were originally asked by Alistair to play nicely together.  So we invested some time to identify these “elephants in the room” so that they could be discussed.  I’ve listed these issues below, using the format of “elephantine issue – my thoughts on the subject” so that you can hopefully gain better perspective as to some of the issues holding back the agile community.  These issues are:

• There are other effective ways of information discovery without writing code – Agile modeling, for example.  
• Managers and management are bad – This is a common refrain of many programmers, including agile ones.
• Politics within the community – There are many factions within the agile community, they don’t always agree nor do they even get along.
• Failure to dampen negative behaviors – We often promote good behaviors within the agile community, such as allowing requirements to emerge over time, but do not push back sufficiently against poor behaviors such as documentation-based governance strategies.
• Technical debt – Are we really paying down technical debt within organizations or merely talking about it?
• Anarchism – Some of the alliances/organizations within the agile community promoting to be open efforts are little more than Ghaddafiesque groups in practice.
• Hypocrisy – The reality of agile is often very different than the reality, something I’ve explored over the years via DDJ surveys.
• Context and applicability – Many agile strategies are promoted as if they are the one best way of doing something, yet in practice they prove to work well in some situations yet very poorly in others.  The Situation Context Framework (SCF) is a contextual framework which may be used to address this problem.
• Context gets in the way of dogma – Related to the previous point, it’s uncomfortable to admit that your one best strategy isn’t the only effective way of work, nor always the best.
• Certification – As I pointed out in January, the agile community continues to build up integrity debt by tolerating questionable certification schemes.
• Pretending agile is not a business – ‘Nuff said.
• Abdicating responsibility for product success (to product owners) – Scrum’s product owner concept is useful in some contexts, but in practice it is a very difficult role to fill and reflects a serious lack of understanding as to the difficulty surrounding requirements management activities.
• Agile Alliance – The AA showed great promise years ago and could potentially have lead the way in a true paradigm shift within IT, but in recent years has done little more than organize the annual Agile conference in the United States and provide funding for local agile events.
• Role of architecture and design – Agile strategies for architecture and design modeling have been long overshadowed by programming practices and Scrum certification.  
• Self organizing teams – The 2010 “How Agile Are You?” survey found that only 56% of “agile teams” were self organizing, and indication that many organizations are still struggling with this concept.
• Elitism – The agile community needs to find ways to be more welcoming to project management professionals, data professionals, software architects, and many other specialist communities within IT.
• Business value (what is it?) – We sure do talk a lot about providing business value, but don’t seem to have a good handle on what it actually means.
• Scaling naivety – As I show in my work around the ASM, there’s a bit more to scaling agile than addressing the issues around large teams and geographically distributed teams, and it’s certainly more complicated than holding a “Scrum of Scrums” to coordinate everything.
• Commercial interests – Perhaps we’d see more evolution in agile methods if we weren’t so focused on charging people to get certified in them.
• Sensing failures – Although DDJ’s Project Success surveys over the years have found that agile project teams enjoy a higher success rate than traditional project teams it isn’t that much better and we don’t have a perfect track record.  
• How do we know that we’re delivering value through software? – If we can’t define value surely we must also be struggling to measure it as well.

The four belief statements are not meant to be an addendum to the Agile Manifesto.  Several of us, myself included, felt that the manifesto should be updated to reflect what we’ve learned as a community these past ten years.  An equal number within the group, however, felt that the manifesto shouldn’t be updated.  It was clear that we wouldn’t reach any sort of consensus on this issue, let alone on what the changes should be, so we decided to leave well enough alone for now.  Interestingly, many of the “elephants in the room” could begin to be addressed by improvements to the manifesto.  Go figure.

>>HOT LINKS

I discuss The Agile Manifesto in detail in my article The Agile Manifesto Examined.

The Disciplined Agile Delivery (DAD) is a hybrid capturing strategies from Scrum, XP, Agile Modeling, lean software development, Kanban, and other agile/lean sources.

See Agility at Scale for more on the topic. 

We are often asked how Disciplined Agile (DA) and PMI-ACP fit together and whether DA is meant to replace PMI-ACP.  Fair enough.  So I thought I would write this short blog to help clear the air.  Here are the key points:

1. PMI-ACP isn't going away.  The PMI-ACP program has been very successful, so of course we're keeping it.
2. DA and PMI-ACP fit well together. We will release an updated agile certification roadmap towards the end of August that makes this very clear.  We're currently finalizing our testing of the strategy out in the marketplace and will publicly release it very soon. Stay tuned here for a detailed announcement.
3. The PMI-ACP certification will evolve over time. At some point it would be reasonable to see the ACP certification explicitly include the advanced agile and lean concepts that DA encompasses.  Don't worry, we'll let you know about any changes to the PMI-ACP certification long before they happen, just as we do with other certifications.
4. PMI-ACP and DA are running in parallel right now. The two programs each have their own schedules. When and if we decide to merge them in some way we will make that clear to everyone.  
5. We're working together.  The DA team is working with many teams within PMI to bring you world-class offerings, including the ACP team.

In summary, you don't have anything to worry about and it's only getting better. 

Update: We now have an Agile Certifications landing page that explains the program.

I'm proud to say that I will be giving the opening keynote speech at Agile Middle East (ME) 2020 on March 11th in Dubai. My title of my keynote is #NoFrameworks: How We Can Take Agile Back! which is a reprise of my keynote from the XP 2019 conference last May in Montreal. 

A fundamental philosophy from the early days of Agile is that teams should own their process. Today we would say that they should be allowed, and better yet, enabled, to choose their own way of working (WoW).

This was a powerful vision, but it was quickly abandoned to make way for the Agile certification gold rush. Why do the hard work of learning your craft, of improving your WoW via experimentation and learning, when you can instead become a certified master of an agile method in two days or a program consultant of a scaling framework in four? It sounds great, and certainly is great for anyone collecting the money, but 19 years after the signing of the Agile Manifesto as an industry we’re nowhere near reaching Agile’s promise. Nowhere near it.

Agile had it right in the very beginning, and the lean community had it right all along – teams need to own their process, they must be enabled to choose their WoW. To do this we need to stop looking for easy answers, we must reject the simplistic solutions that the agile industrial complex wants to sell us, and most importantly recognize that we need #NoFrameworks.

As you can see from the conference schedule there is a great line up of speakers. To help support the conference Project Management Institute (PMI) has gotten the organizers to agree to a 20% discount when you use the code "PMI" in all caps when you register. I'm looking forward to the event and if you're in the area I hope you will choose to attend the conference.