Going to CA World? Join my Modern Business Management session Thursday, 16 Nov 2:30pm in the Agile Management Agility Zone/Tech Talk area.
Modern business management is about understanding, tracking, and managing the entire ecosystem of work in your organization. It doesn’t matter if the work is based in Scrum, Kanban, Six Sigma, Prince 2, PMBOK, or any other approach to delivery. This is much easier to say than do. Things can go off the rails for any number of reasons. One of the lessons we’ve learned at CA is, arguably, the most obvious and one of the hardest to overcome. It’s the words we use to talk about work.
When work is viewed and talked about differently by different delivery methods across an organization confusion and misunderstanding easily creeps into discussions. The most obvious example we see, we see it almost daily now, is how traditional methods view and speak about work compared to agile modes of work. That’s not to say the same challenges don’t exist when talking about methods based on bodies of knowledge like Prince 2 and PMBOK. Those challenges also exist. But, because the language between traditional methods is very similar, they don’t often surface as quickly or as visibly. These differences in how words are used to describe work can result in:
- Unique interpretations of data between and within BUs.
- Data with similar labels but different interpretations being consolidated inappropriately.
- Explosion of the number of reports in the business to accommodate unique interpretations.
- Sub-optimized business decisions due to differing interpretations.
Based on experience, I would suggest the differences between agile and traditional ways of work makes it easier to identify disconnects in how people talk about work within an organization. It also makes it easier to start to solve sooner when compared to differences between two or more traditional methods. This is because the stark differences in how agile talks about work compared to more traditional ways shines a much brighter spotlight on those differences. When looking at the differences between two different traditional approaches to work, like Prince 2 and PMBOK, the spotlight on differences often happens very late in the game and is not nearly as bright. By the time these differences between traditional methods are addressed damage is already done and decisions are being made with sub-optimal information.
The differences in how words are used to describe delivery makes it a challenge to have a holistic look at an enterprise portfolio. Different approaches to delivery of work can and do use similar language to describe similar concepts and ideas. In two traditional delivery approaches a ‘risk’ for you may not be the same as a ‘risk’ for me. Contrasted with a traditional view of teams (resources) against an agile view of teams (people) and it’s easy to see how easy the contrast is between newer agile and more traditional ways of working.
The obvious question is: How do you overcome this important difference in how people use words? While not yet a full blown agilest myself, I find the answer in some of the key elements of the Agile Manifesto:
- Individuals & Interactions
- Working Software
- Customer Collaboration
- Responding to Change
By valuing individuals and interactions people become more receptive to both hearing and accepting changes in how they use words. For example, I have been making a conscious effort to stop referring to people as “resources”. This is a direct result of my interactions with my colleagues in the Agile Central practice. As a result, I no longer think of people as numbers in a resource capacity and demand planning tab in CA PPM. To me, a team is no longer an abstract concept but is a collaboration of people with names and faces.
I equate the “working software” component of the manifesto to represent any work. In other words, I expand that definition to the context of business agility. The concept of working software is broadened to include all work related to achieving the business objectives. More specifically, any work needing to be done in a timely and quality fashion to achieve a specific business goal. In an ideal world: all work happening in an organization. So, in trying to change the language in your organization the emphasis needs to be on finding common language to describe work. Understanding and communicating effectively about how work is identified, defined, allocated, and tracked is only possible with a common business vocabulary for your organization. But, in adjusting your thinking to this approach you do need to be careful. As my friend and colleague Gene Mrozinski pointed out to me, a true agilist may not find this perspective very resonant. Without being clear the context of the conversation is expanding beyond software to include business agility you may introduce unintended resistance to this kind of conversation.
Customer collaboration is critical to overcoming these differences in words. Customer can represent both internal and external parties. When addressing this semantic challenge all parties must be willing to collaborate to a common end. The kind of collaboration needed helps define a positive working relationships between groups and individuals to achieve common goals. Without the willingness to collaborate to find a solution to this semantic problem the problem of ships crossing in the night will simply continue to perpetuate.
Lastly, responding to change is critical for success in any well-run organization. My favourite phrase learned from my colleagues in the Agile Central practice is “sense and respond.” To me, that statement says it all. The ability to sense and respond to change is the nirvana of business agility. In order for anyone to do this we need to be willing to accept information and then respond to that information in a positive way. This means that, when addressing the challenge of bringing different methodologies to the table, all parties need to let go of dogma to find a common business language. Letting go of dogma can be one of the most difficult things an individual does. An important part of being able to let go of a worldview is being presented with new information challenging the existing status quo. This means being open and able to sense when something legitimately counters a particular view you might hold dear. Once you’ve identified a challenge you can then respond with an open mind and a positive outcome as a goal.
Keeping these key elements in mind, an organization needs to work towards defining a meta-model to act as a translation layer between the different ways an organization works. This meta-model makes sure all parts of the organizations are communicating in a common business language while still retaining the strengths and uniqueness of each approach to delivering on work. There are no common meta-models in the market place one could consider to be “one-size-fits-all.” Therefore, each organization needs to look closely at their own specific needs to define a meta-model supporting its own unique needs. This is no easy task.
In the end, it is a lot of hard work to:
- Overcome methodological inertia
- Adjust individual points of view
- Embrace compromise around definitions
In CA Services, we’re concentrating on helping to avoid these kinds of challenges at our customers. We’ve put together our Modern Business Management team. As PPM’s VP of Product Management Kurt Steinle likes to say “We’re tying to help our customer eliminate the work about work.” Our team consists of people from Agile Central Services and PPM Services practices to collaborate with our customers to find new ways of addressing these types of challenges. Ultimately, a business needs to know what’s going on across the whole enterprise. That means having the ability to speak the same business language anywhere in the organization. Using the CA ecosystem of tools, we want to help our customers overcome this and other barriers preventing them from achieving maximum success in their organizations.