Disciplined Agile Applied

And now for something completely different.  Earlier this week my wife and I celebrated our 16th wedding anniversary. On social media I joked that it was our 10th anniversary in hexadecimal, not realizing that my non-computer nerd friends wouldn't get it.  And that's exactly what happened. So what are computer professionals talking about when they refer to different numbering systems?

Bits and Bytes

Digital computers store information as bits, ones and zeros, which in turn are organized into bytes, which are commonly 8 bits.  The words in this blog posting, the numbers in your spreadsheets, the images on the web, all converted back and forth to 1s and 0s.  When it comes to numbers, computer scientists like to think in terms of four numbering systems:

1. Decimal. This is our normal, arabic numbering system where the digits are 0 through 9.  This is also known as base 10 (there are 10 digits).
2. Binary. This is how computers store information, using the digits 0 and 1.  This is known as base 2 (there are two digits).  
3. Octal. The octal numbering system uses three bits, a bit is a 0 or 1, to store numbers. This is known as base 8.  A few groups of people throughout history used octal as their numbering system, and it was commonly used in several computer technologies in the 1960s and 1970s due to 6-bit, 12-bit, 24-bit, and 26-bit architectures.  This is not in use any more, except perhaps as a teaching mechanism in computer science courses.
4. Hexadecimal. The hexadecimal numbering system uses 4 bits to represent numbers, giving us 16 digits to work with (typically 0-9 plus A-F).  This is also known as base 16.

The following chart converts the decimal numbers 0 through 16 to binary, octal, and hexadecimal. Now you can start to understand my joke.  I've been married for 16 years.  In hexadecimal, that's the number 10, which is 16 + 0, more on this math below.  In octal it would be 20 years and in binary 10000 years (I'm smart enough to not joke about that). 

Figure 1. Comparing numbering systems.

How the Math Works

To explain how this works, I need to introduce you to a mathematical symbol: ^ which means "to the power of".  So 10^3 = 10x10x10 = 1000.  2^3 = 2x2x2 = 8.  Any number to the power 0 is 1.  

Let's work through an example.  In this case we'll covert the decimal number 13 to each of the four numbering systems:

• Decimal:  13 = 1*10^1 + 3*10^0 = 10 + 3.  
• Binary: 1101 = 1*2^3 + 1*2^2 + 1*2^0 = 8 + 4 + 1.
• Octal: 15 = 1*8^1 + 5*8^0 = 8+5.
• Hex: D, because D is the hex digit for 13.

Now let's try something harder, the decimal number 75:

• Decimal:  75 = 7*10^1 + 5*10^0 = 70 + 5.  
• Binary: 1001011 = 2^6 + 2^3 + 2^1 + 2^0 = 64 + 8 + 2 + 1
• Octal: 113 = 8^2 + 8^1 + 3*8^0 = 64+8+3.
• Hex: 4A = 4*16^1 + A(11)*16^0 = 64+11.

The concept of different numerical bases is a general math concept, it isn't restricted to computers. For example, if you play your cards right you can use different number systems in jokes.  Yeah, that's the ticket.

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?

I was recently a panelist on a webinar about enterprise agility.  One of the issues that we explored was why organizations were struggling to improve, and we heard from a range of people about the problems that they faced.  Sadly, many excuses were offered up, and they basically boiled down to:

1. I'm on an agile team, we'd love to improve, but the PMO (or the governance team, or our executives, or...) will beat us up.
2. I'm in a regulated environment, we'd love to improve, but the auditors will beat us up.
3. I'm an executive, we'd love to improve, but the board of directors will beat us up.

Here are some insights that will hopefully help you to work your way past these sorts of excuses:

1. These people that will "beat you up" face similar challenges.  They may have a different point of view than you, and that point of view is valid and should be respected.  They also face a similar dilemma in that they're likely afraid that someone else will beat them up if they change their way of working (WoW). Recognizing that we have this in common can often provide a basis from which to have a more meaningful discussion.
2. Work with them.  Discover what their concerns and constraints are.  What risks are they worried about?  How can you work more effectively while still addressing those risks?  What minimum viable change (MVC) can we experiment with safely to determine whether it is possible to improve?
3. Treat them as allies, not enemies.  I've had great experiences working with PMOs to identify how my team can work better and thereby provide increased value to the organization.  I've substantially reduced risk by working with auditors early in the game to discover what they're actually concerned about, to identify how my team can address those concerns in a streamlined (and often automated) manner.  I've had great discussions with board members, particularly those who are executives at other firms, when I asked them if they're dealing with similar challenges in their organizations (and they always have similar challenges).  Bottom line is that you'll be amazed at how the people whom you thought wanted to beat you up are really there to help you to succeed.
4. Regulations are obligations, not prescriptions.  I'm working on a detailed blog about this topic right now, but too many people believe that regulations state "work this way" or "produce these artifacts."  That may be your organizational interpretation of the regulations, but if you choose to go to the source you'll often find that the regulations aren't as prescriptive as you've been led to believe.  When your bureaucrats are allowed to interpret regulations you will end up with a bureaucratic WoW, whereas if practical people interpret the regulations you'll end up with a pragmatic WoW.  And both approaches will still conformant.
5. Other organizations have chosen to overcome similar excuses.  I have to say it - while you're standing there complaining about how tough you have it, someone else is stepping up and doing what it takes to improve.  I invite you to join them.

My hope is that this blog has given you some food for thought.

Related Resources

• Disciplined Agile Scrum Master (DASM) - Learn how to improve
• Disciplined Agile Senior Scrum Master (DASSM) - Learn how to lead improvement within a team
• Disciplined Agile Coach (DAC) - Learn how to facilitate improvement across disparate teams
• Disciplined Agile Value Stream Consultant (DAVSC) - Learn how to guide improvement throughout a value stream and across an organization

Herb Kelleher's missive “hire for attitude, train for skills" is becoming more and more relevant as time passes. Kelleher, one of the founders of Southwest Airlines in the United States, believed in hiring good people and then supporting their learning journeys over time.  This is in stark contrast to the "gig economy" where you hire people with the skills to perform a specific job for a specified period to time so as to fill an immediate need.  Both are valid strategies in the right situation, but in this blog I'd like to explore Kelleher's philosophy.

Here are three important questions we need to answer about the "hire for attitude, train for skills" strategy if we're going to make it work in practice.  In particular, how do you identify:

• Where your skills are deficient?
• The skills that you need to focus on right now?
• Topics to begin exploring now so as to prepare for the future?

Identifying Where Your Skills Are Deficient

This can be easier said than done.  Some organizations will have a robust People Management, often called Human Resources (HR), strategy in place that actively helps people to develop and then execute on a personalized learning journey. This is great if you have access to such a program, but even when you do there is still the challenge of identifying the skills and knowledge that you need to learn. Sometimes this is obvious, particularly if your organization already has strengths in the areas where you are currently weak, but not so obvious when a topic is relatively new to your organization or is rapidly evolving.

For example, let's assume that you're in a technical position on a solution delivery team and you need to expand your skillset around cybersecurity.  Unfortunately, you don't have easy access to someone with security expertise who would be able to guide you through how to learn more about security.  You could search online for some information, but what would you search for?  How can you tell which of the thousands of results you should focus on? A better option would be to start with the Disciplined Agile (DA) tool kit to see what it suggests regarding this topic so as to get you going in the right direction. 

Figure 1 shows two decision points, and their associated options, from the goal diagram for Disciplined Agile (DA) security process blade. Although there are many other decision points to consider, as you can see in Figure 2, let's focus for now on two that are directly pertinent to software developers: secure applications and secure data. You can see that there are several options that your team could adopt to develop secure applications, one of which, code review, you're familiar with but the rest you are not. At least now you have a short list of topics that you could explore in greater detail, narrowing your challenge down to something that is more manageable.  

Figure 1. Two decision points of the security process blade (click to enlarge).

Figure 2. The security process goal diagram (click to enlarge).

There is a much longer list of data security strategies provided, in fact this list is a bit daunting, because of the greater complexity of this aspect of cybersecurity. Quickly looking at the names it sounds as of many of the techniques are likely the responsibility of your data management team, although several sound as if they're more applicable for the solution delivery team that you're on.  In this case you decide to reach out to a friend on the data team to get their advice on where you should focus.

Identifying The Skills to Focus on Now

This decision is driven by the needs of your situation, the availability of options to gain the skill (training, coaching, and so on), and your preferences.  For example, if your team has an immediate need to improve their automated testing around security then learning about static code analysis techniques and tooling is likely what you need to focus on right now.  This may be quickly followed by learning about the other application security techniques in Figure 1.

Identify the Topics to Begin Exploring Now to Prepare for the Future

Many skills can't be learned quickly, or more accurately you need to understand the fundamentals of some topics before you can gain specific skills in them.  Once again, let's consider security.  It was a very big assumption on my part that you would have the background required to learn about static code analysis, penetration testing, or other application security strategies. What if you have very little knowledge about security or testing? Diving deeply into a specific skill likely isn't going to work out well in this case, your first step before doing so is to learn some fundamentals.  But how do you do that?

Luckily there is a lot more to the DA tool kit than just lists of techniques. When we describe process blades we work through four views:

1. People. There are specialized roles, and responsibilities for those roles, associated with each process blade. For example, the asset management process blade describes the roles of asset manager and asset engineer whereas data management has roles such as data manager and database administrator.
2. Mindset. The Disciplined Agile Mindset describes the principles, promises, and guidelines necessary for enterprise agility.  Each blade extends the DA Mindset with a collection of philosophies specific to that process area.  For example, Figure 3 overviews the mindset for disciplined agile vendor management.
3. Flow. Disciplined Agile captures the flow of work in several ways, including life cycles, the DA FLEX value stream, and work process flows. For example, Figure 4 depicts a context diagram which overviews the high-level flow of disciplined agile research & development and Figure 5 shows the internal workflow of disciplined agile asset management.
4. Practices. Practices are captured via goal diagrams such as the one for security in Figure 2 and described in tabular format, which you can read via the DA Browser.

Figure 3. The mindset of vendor management (click to enlarge).

Figure 4. The external workflow of research & development (click to enlarge).

Figure 5. The internal workflow of asset management (click to enlarge).

We Need to Learn Continuously

Given the rapid pace of change within our current environment, many skills appear to have a short shelf life. The implication is that you want to know how to identify skills that are relevant now for the situation that you face and then pick those skills up quickly.  You've seen in this blog that the Disciplined Agile tool kit can help you with identifying the skills to learn.