As we enter April, it’s time to celebrate the Agile Principle #4. The one that says:
“Business people and developers must work together daily throughout the project.”
Interesting, isn’t it? In general, Agile makes it clear that collaborating is the most powerful way of achieving great results. But why should we care to mention explicitly having people from the technology front and the business front work together?
The importance of the Agile Principle #4: synergy
Synergy is a word to describe that when you put A and B together you get more than just AB. You create value in the relationship as well.
Now, back in the 1990s, business people in companies were the suits and the developers were somewhere else, in a corner full of computers and coffee. They communicated with each other mostly via proxy, memos, messages, someone talks to a manager, and a manager talks to you.
As you can imagine, there were a lot of miscommunications, delays, and especially: business folks not understanding technology and developers having no clue about the business. It was even worse with the people doing the sales being entirely disconnected from how the product was being developed, promising features and dates that were simply impossible.
Sounds familiar?
That is because this situation unfortunately improved marginally to our days. I’ve worked, rather recently with organizations where not only those categories of people if you will, sit way apart from each other, sometimes in different buildings, but they also still don’t understand how each other works and sometimes have a problem understanding words and concepts that they use.
And I’m not talking about companies that are doing offshore models. Those are sometimes even worse at keeping people separated (although they shouldn’t be). But I am talking about companies that have in their staff people who understand the business (the clients, the market) and people who know how to use technology to create products. It’s like having the plug and the power and just not connecting them.
The danger of ignoring this synergy: a gap
This Agile principle warns us of the dangers of chasms in point of view if business and technology work separately. When you don’t have synergies happening between business and development you are missing out on opportunities for product quality and reputation, and also for improvement of your company processes as a whole. Not to mention, plain and simple, you are missing out on the opportunity of creating new business models.
It is inefficient to send an order to a request to the tech folks for them to build something as if they were a provider. It’s also inefficient to have the developers ask business folks to explain what’s really important in the delivery, the product, or the release and hear that “there are 5 priorities”. Not only are the folks in technology merely executors in the first case; in the second case, our folks in business also can’t do a good job on priorities when they don’t understand what technology can and cannot power for them.
Somehow this separation of concerns is how many important organizations still conduct their affairs today. Do you know the average tenure of a CEO goes around 7 to 10 years while the one of the CIO, is usually just 4? What do you think of it?
That happens because quite often CIOs are the scapegoats for failure and under-performance on strategy in organizations. Senior executives, stakeholders, and members of the C-suite expect the miracles of the technology, ignore what happens in that arena, underfund the technology departments, and then get surprised at the results they see.
This conversation is not just about a Product Owner not talking to the Developers in a Scrum team. Pay close attention as a coach, because it goes beyond that. It’s a model deeply ingrained in how some companies operate. And it’s disempowering and bureaucratic. And over 20 years ago some annoying smart developers were already saying “you can’t do that, it’s unhelpful!”.
Failure on the horizon
Forbes says that up to 84% of so-called digital transformation initiatives are failing in one way or another, despite over 3 trillion dollars in investment. To me, that’s proof that you can’t’ just throw money at the problem. And what’s most puzzling, with so much access to technology, what’s going on?
Try and remember that between McKinsey saying that over 70% of Agile transformations are failing (Scrum Inc says it’s only 47%, still half) because of culture and now the numbers on digital transformation… when you look deeper, the common element is culture, humans.
Digital transformations are failing because the digital piece can’t be ignored, but neither can the human: it’s about harnessing the technology at the service of the market of actual and potential customers. It’s a capability, not a sub-organization in the main organization. Technology is an investment, not a cost. So how can you develop strategies in that direction when your tech people and your business people all belong to different reporting lines and even orgs?
Technology IS the business. And so is the customer
I personally would go as far as to say that today technology IS the business. And there is no contradiction with that and being customer-centric because the customer of today and tomorrow does and wants everything online, fast, one click away. You can see those examples in companies like Tesla and Uber, where the starting point was using technology to create a new experience for their customers and create a totally new market for people. Some folks quit their jobs and are Uber drivers and deliverers. Today we have thriving companies that are very meta, with products… for creating products, like ProductBoard, AppStudio, or Asana. Or just pick your favorite consumer app, from Angry Birds to Google Meet.
You can also feel this point of technology being the business on a negative scale. For example, in well-established markets, such as banks. I mean everybody wants to use their phones to do everything; people want fewer steps and easier ways of doing things. Yet, for many banks we, the customers, still continue to complain because certain features still don’t exist in certain bank’s mobile apps or websites. Some banks are yet to offer free-of-charge accounts, have an ugly and cumbersome interface and some banks don’t even let you scan a cheque with your mobile.
And the technology can power this since before 2010. But when there is no partnership between business and technology, they are all basically fighting for their own separate roadmaps. They are literally competing inside of the organization. We’re going beyond inefficient this way: we’re going for ineffective. When a company can develop from scratch great interfaces and products such as the ones we see today with startups all over the world, how come companies with more people and more money are still lagging behind?
How can the Agile Coach help?
This is a hard principle to approach in my experience so far. I have not seen much growth in this partnership of business and technology in most companies I’ve helped. And while it’s easy to spot the problem and explain the impacts, somehow many executives and managers still remain paralyzed in this area.
But I don’t see reason for despair. Don’t be a disheartened Agile leader. Whether you are an Agile Coach, Scrum Master, a practice lead, or a manager, there are possible scenarios to try and experiment no matter the size of the organization.
My first take is: stay current with market data and let others know about them in your organization. Remember, one of the domains the Agile Coach is expected to grow their skills in is the Transformation and Business domains. Talk to all the managers and executives you can, in coffee conversations, but also don’t be afraid to be upfront a book a 30-minute interactive session where you show them these data and invite the conversation on what it means for the company.
Remember that the Agile Coach is a positive disruptor for high performance in teams and organizations and facilitating these difficult conversations is part of the menu you offer. Just make it a conversation, not a crusade in the name of Agile. You have a strong case to make, bring your perspective and listen. And provoke. And listen.
My second take is really fighting for cross-functionality in organizations. I wrote a blog post on just about that here.
But before you hop there, what is your take? What do you think can be done to bring business folks and technical folks to daily close collaboration?
Now, off you go to read that one.
