Recap of Parts 1 and 2
Our first post in this Shadow IT series pointed out that in today’s environment, as technology becomes more sophisticated, more analytical, and more social, the skills required for success are changing more dramatically than ever. We argued that the very nature of the work we do is changing. Creating a successful technology-driven business solution is born from a blend of skills that don’t fit well into the standard corporate structure. We argued that this tension between the nature of the work and the departmental corporate organizational form is limiting the effectiveness of digital transformation efforts.
In our second post, we noted that the relationship between customers and vendors is increasingly a digital one. According to Gartner, by 2020 the customer will manage 85% of its relationship with enterprise having had no human interaction. Our analysis pointed out that the the coming wave of millennials, equal to ⅓ of the US population, are digital natives that expect to serve themselves with easy, efficient, and enjoyable technology experiences. The sheer scale of this cohort guarantees that as customers, as employees, and as consumers, we will all be doing it their way.
More than ever, winners and losers will be chosen based on the enterprise’s ability to create design-centered technology experiences for customers and employees. We observed that while 95% of organizations have begun to try Agile-based approaches, most do not make all of the changes needed to generate speed and effectiveness and therefore reap few rewards. More importantly, we demonstrated that while most enterprises are hiring product managers or business-IT liaisons, very few organizations integrate product management and all of its related disciplines.
Now that we’ve recapped the first two articles, let’s leap into the final installment of our Shadow IT series and discuss how to make the digital transformation.
Digital Transformation – Love it or Hate it, You’re Going to Live it
In trying to explain the extraordinary prosperity that marked most of the years of his presidency, former President Bill Clinton once remarked with a quivering lower lip, and just the rake of a little gravel in his voice: “if you see a turtle on a fence post, you know he didn’t get there by accident.”
Things are as they are for a reason.
As we’ve previously illustrated, traditional corporate structures do not readily lend themselves to managing innovation in a blended, multidisciplinary way. Instead, finance controls the budget, the PMO runs a stage gate process to measure progress, business stakeholders have goals, and IT has to make the trains run on time. They all serve different masters, with differing goals and measurement, often uncoordinated across the organization, except at the highest level.
For nearly two centuries, corporations have been organized this way with the goal of efficiency. Work was considered entirely divisible and specialization insured the lowest production cost. Though this model is baked into the culture of business, it’s exactly what has to change. Bold innovation isn’t found in the slow and steady whittling down of cost through efficiency, it’s in the giant leaps that come from changing the way we do things. With the rising need to be digital, leading companies must recognize that the turtle may be on the fence post for a reason, but that reason is not to spur rapid innovation.
In response, 95% of organizations have converted to Agile, with the hope of increased throughput and fewer obstacles to innovation. However, many firms are failing to reap the benefits that product management orientation and solid agility best practices can produce. The 10th Annual State of Agile Report, released in March 2016, outlines some of the reasons why agility efforts fail to produce the desired results.
The number one reason cited by 46% of respondents was that “company philosophy or culture is at odds with core Agile values.” Number two on the list at 41% was “lack of experience with Agile methods.” The rest of the items on the list, all at around 40%, included: lack of management support, lack of support for culture transition, and external pressure to follow waterfall processes.
Clearly the oft repeated refrain that we’re “moving to the cloud,” and “becoming Agile” isn’t enough. The change is deeper, more basic than that.
How does an enterprising CIO who wants innovation fast, make it happen?
Agility adoption and achieving a product orientation that drives speed and innovation, is not just changing software project delivery approaches. It’s about changing the whole culture. It’s about moving the turtle to a new fence post.
There are 4 stages to achieve the kind of cultural changes necessary to drive maximum results.
Project Delivery Methodology
The vast majority of firms we meet with think they are done or nearly done “adopting Agility.” In reality, as seen in both the 9th and 10th Annual State of Agility reports, less than half have adopted industry best practice. We often find what we call AINO conversions (Agile In Name Only), where firms have rebranded their traditional waterfall or stage gate processes with agility terms. Obviously changing the branding doesn’t change the result, so this can often be the source of neutral progress (talk about a euphemism!). Even if teams have adopted agility best practices, gains are often offset by the tug-of-war between traditional waterfall style service organizations that provide QA, or production support, or by the start and stop nature of the funding/budgeting process. The cognitive dissonance between these approaches can result in a reduction rather than an increase in delivered innovation.
More than ⅔ of all of organizations that have implemented Agile use an approach called SCRUM. This approach to Agile relies on a key person, the Product Owner, to know and understand the business value of individual features, their relative importance, and the linkage between features and desired business outcomes. The Product Owner is the omnipotent, omniscient person, who embodies the customer. Though this role is critical to the success of the approach, Agile/SCRUM does not provide much guidance for how this role gains that knowledge. Not surprisingly, even sophisticated users of Agile/SCRUM often struggle with this role.
In the traditional terms of a product company, the Product Owner is the equivalent of a product manager, and all of the traditional product management concepts apply to this person’s work (e.g. design thinking, usability, heuristics, analytics, cost, market factors, politics, customer demand, etc). When done well, the application of these product management disciplines to agility, clarifies prioritization and aligns business objectives with technology capabilities. You ensure that the features you’re building first have the highest business value. Combine that with an ability to routinely turn out new software every two weeks, and the team can constantly adapt to changing circumstances. Mastering best practices in this stage guarantees increased throughput, or decreased costs, and a shorter fuse to innovation.
Virtually every client we work with uses a traditional top down annual budget and planning process. Usually IT bubbles up a bunch of projects based on the demand from business stakeholders. Executive management meets during the annual planning process and selects the programs that will be funded. From this planning process, management objectives and goals (the criteria that will guide raises, promotions, and bonuses) are distributed across the organization. Afterward, most organizations have a secondary funding step, or stage-gate process, or some other PMO function that then allocates costs and resources to these programs.
Once funded, the “teams” are made up of people with regular day jobs (marketing, sales, finance, IT) and they have a proportional allocation to the project or program that’s been funded. These teams of partial people all have their own goals and objectives, and almost always, none of those goals or objectives include building the features that are envisioned by the program to which they are assigned. Then, shockingly, the team focuses on the objectives that will drive their career and not on generating new features every two weeks.
Owning the product, the whole team, and the budget combined with some Agile, product management, continuous delivery, and a team that is motivated to deliver features will enable teams to self organize on the battlefield. They inspect and adapt on a daily basis. Tasks are shared and collaborated on. Teams are motivated because they are empowered to remove obstacles. In short, the engine starts firing and teams are free to innovate at speed. People enjoy their work, and the speed continues to increase.
The core leadership principle in today’s corporate management is fundamentally command and control. Decision making is hierarchical. Executive leadership calls the stroke from the back of boat, and the crew pulls on the oars in time. When the rules of the game are clear, and efficiency is determinant of success, this style or mindset of leadership is often successful. But if you seek creativity, innovation, and change, then the organizational mindset must change.
Ideas grow from the green shoots and grass roots. There is a reason that great, innovative, companies such as Google, allocate meaningful time to experimentation, and to failing fast. Innovation cannot be ordered with a bullhorn. People need the freedom to solve problems free from useless obstacles. Senior leadership must view themselves not as calling the stroke, but rather running up and down the aisle to make sure that the team has what they need to succeed. Sometimes it’s referred to as servant leadership. In the choice between leading with questions or leading with answers. Executive management should be asking what can they do for you, not the other way around.
In our first post, we noted that digital transformation will be evolutionary not revolutionary. Top down command and control enterprises are not going to convert to servant leadership over night and changing the project delivery methodology to Agile doesn’t make your teams fast and innovative. The part that’s “like it or lump it” is that technology is going to play a more forceful and increasingly critical role in serving the changing needs of the millennial digital native customer for the foreseeable future. More than ever, winners and losers will be chosen based on the enterprise’s ability to create design-centered technology experiences for customers and employees. Change is in the air; breathe it in and get busy!