Modern digital companies are burdened by their past.
Creating digital products and services probably looks familiar to large companies, as they have been running software development projects for decades. These projects employed technology teams that often delivered late and over budget, but in the end, the project finished and the team dissolved.
In the digital age, one might think the experience of running and delivering corporate IT projects would be an advantage, but it’s actually a burden. The legacy mindset and practices of corporate IT projects are a hindrance when managing digital endeavors.
At first sight, digital product development looks like IT projects of old. While new technology is in play, Ruby has replaced Java (which replaced Cobol), the cloud has replaced in-house servers (which replaced mainframes), and agile has replaced waterfall. Such obvious technology changes mask a far deeper difference.
There is a fundamental change required in the way digital work gets managed. It is not just that the project model contains flaws. Rather, digital work needs to be ongoing. Digital work doesn't stop. That means it needs a different management approach.
A successful corporate IT project is one that does everything asked of it, preferably within budget and schedule, and then shuts down. But would anyone consider a Walmart with empty shelves a success? No Walmart manager has ever said, "Yes! We sold everything! Our job is done."
Not only do businesses need to restock the shelves and sell more of the same thing, they also need to periodically reinvent themselves. Even if their current products still sell, companies need to extend product lines, introduce new products, and retire older ones. If not, they end up selling products people no longer want, and before long, they cease to be.
Continuous Digital
Businesses that aim to be digital need the same continuity and growth mindsets in digital operations.
I call this model “continuous digital.” It differs from the old project model because it aims to continue rather than to finish. That doesn't mean costs can run amok, it doesn't mean there is no control or direction, and it doesn't mean nothing is ever stopped. It means the goal is to continue with success.
Businesses that approach digital with a project mindset are making a fundamental mistake. Business doesn't end, so digital business doesn't end. Digital products and services need managing for continuity and growth.
In the continuous digital model, the team is the unit of production. Teams contain all the skills and authority to work on a digital product or service, and team success is intrinsically connected to the success of the digital entity.
Success gets measured both in terms of value created and progress toward a higher purpose. Nobody gives the team a list of must-do features, there is no requirements document, and there are no must-haves or priority-one features. In the beginning, the team probably doesn't even have a backlog.
What the team does have is a higher purpose. Call it what you like: a mission, a goal, an aim, an objective, a BHAG (big hairy audacious goal), an MTP (massively transformative purpose), or a strategy. The team exists to both discover the need to reach that goal and create a solution to address the need (and make a little money).
Business Approaches to Quality
It goes without saying that the team embraces DevOps, so it contains release and deployment skills. But more than that, the team extends back into the business, too.
A continuous digital team is a business technology, or "BusTech," team: It contains business experts, product managers, business analysts, and even front-line delivery staff. BusTech teams are logical for digital business, where the business is technology and the technology is the business.
Unlike the project model, the teams are continuous. The same people work on the same products and the same code base over time. Teams are not disbanded or formed for specific projects.
But this doesn't mean the team never changes. A minimum viable team starts the exploration of need and solutions. Success with a minimum viable product leads to team growth. Alternatively, if, after several tries, the team can't find an MVP that works, they disband. Teams will continue growing while there is business justification. When sales fall, the team will shrink, or they may reinvent themselves with a new product.
People also will occasionally leave the team. They may transfer to another team, split off in a subteam, leave for a new job, or retire, so new people will join the team. A stable team does not need to be a static team.
Continuous digital teams take quality seriously because they know poor quality—buggy code, poor design, or a lack of refactoring—will quickly bite the team and slow them down. The team also knows that they will be living with the code for years, so if they don't fix it, nobody else will.
Creating Value
Active portfolio management gets applied regularly across teams and products. Poor performers need weeding out or reforming. Minimum viable teams create minimum viable products, and successful teams get more resources.
The portfolio process ensures the team is pursuing goals important to the wider business and is making progress against those goals. Ultimately, it is the market that will decide if the team is creating enough value, but within a company, an active portfolio process offers a fast feedback loop and a check on business alignment.
While teams are pursuing their higher purpose, they still need to create demonstrable value. Ideally, this is money in the bank, but it can be something else. A hospital might measure a team against patient outcomes. A university might measure a team against student results. The question is, what is valuable to this organization?
But there is another way the team is creating value: They are building an asset.
Software as an Asset
Traditional corporate IT treats software projects as a cost to minimize whenever possible. But software needs to be seen as an asset rather than a cost.
Software systems are as much assets to a company as a store is to Walmart, or a truck to FedEx. Walmart knows that if staff find it hard to work in a store, or if customers find the store weary, then it will take in less money. It might be cheaper for FedEx to patch up an old truck rather than overhaul or replace it, but when constant breakdowns mean missed deliveries and unhappy customers, penny-pinching is a false economy.
So software needs to be maintained to a high standard. It needs to remain soft. Soft software is flexible software, and flexible software retains its value for longer. Quality software breaks down less often and generates more value.
Just because developing a digital product or service looks superficially like a corporate IT project doesn't mean it is a project. From a management point of view, digital work should be seen as something very different.
Everyone involved in creating digital products and services needs to adopt a continuous mindset. Continuous digital should not have the same approach to it as the projects we’re used to.
