I had the good fortune of moderating a panel on the state of digital business at the Chief Digital Officer Global Forum in Singapore yesterday morning. The event showcased a who’s who of digital business leadership in the region, including my panelists Veena Ramesh of Johnson & Johnson, Jerry Blanton of Citi, and Veronique Meffert of Great Eastern Life.
Organizational issues are the greatest hurdle. There was not a single dissenting voice on the fact that organizational challenges represent the biggest impediment to digital business progress. The greatest organizational challenges are functional silos, business unit resistance, a lack of clear guidance from the CEO, rigid backward-looking mindsets, and a shortage of the skills needed to drive change. One approach — shared by Rahul Welde of Unilever — is to drive “digital experimentation funds” and “foundries” to drive co-creation innovation.
Media command centers are becoming critical marketing assets. Both representatives from Unilever and Philips spoke of the critical role that media command centers now play in their marketing campaigns. In the case of Philips, I was surprised to learn that its social media command center in Singapore employs 200 people — and that it is planning for expansion!
Unified information architecture, data governance, and standard enterprise BI platforms are all but a journey via a long and winding road. Even if one deploys the "latest and greatest" BI tools and best practices, the organization may not be getting any closer to the light at the end of the tunnel because:
Technology-driven enterprise BI is scalable but not agile. For the last decade, top down data governance, centralization of BI support on standardized infrastructure, scalability, robustness, support for mission critical applications, minimizing operational risk, and drive toward absolute single version of the truth — the good of enterprise BI — were the strategies that allowed organizations to reap multiple business benefits. However, today's business outlook is much different and one cannot pretend to put new wine into old wine skins. If these were the only best practices, why is it that Forrester research constantly finds that homegrown or shadow BI applications by far outstrip applications created on enterprise BI platforms? Our research often uncovers that — here's where the bad part comes in — enterprise BI environments are complex, inflexible, and slow to react and, therefore, are largely ineffective in the age of the customer. More specifically, our clients cite that the their enterprise BI applications do not have all of the data they need, do not have the right data models to support all of the latest use cases, take too long, and are too complex to use. These are just some of the reasons Forrester's latest survey indicated that approximately 63% of business decision-makers are using an equal amount or more of homegrown versus enterprise BI applications. And an astonishingly miniscule 2% of business decision-makers reported using solely enterprise BI applications.
The battle over customer versus internal business processes requirements and priorities has been fought — and the internal processes lost. Game over. Customers are now empowered with mobile devices and ubiquitous cloud-based all-but-unlimited access to information about products, services, and prices. Customer stickiness is extremely difficult to achieve as customers demand instant gratification of their ever changing needs, tastes, and requirements, while switching vendors is just a matter of clicking a few keys on a mobile phone. Forrester calls this phenomenon the age of the customer. The age of the customer elevates business and technology priorities to achieve:
Business agility. Forrester consistently finds one common thread running through the profile of successful organizations — the ability to manage change. In the age of the customer, business agility often equals the ability to adopt, react, and succeed in the midst of an unending fountain of customer driven requirements. Forrester sees agile organizations making decisions differently by embracing a new, more grass-roots-based management approach. Employees down in the trenches, in individual business units, are the ones who are in close touch with customer problems, market shifts, and process inefficiencies. These workers are often in the best position to understand challenges and opportunities and to make decisions to improve the business. It is only when responses to change come from within, from these highly aware and empowered employees, that enterprises become agile, competitive, and successful.
Our bi-yearly Forrester Agile survey suggests that Agile development (or simply "Agile") continues to see consistent, strong adoption. However, the same survey data shows that only a small percentage of firms are outsourcing Agile application development due to a lack of experience with the development sourcing approaches and governance models needed to make it work. Successfully outsourcing Agile development, either fully or partially, involves redefining roles and responsibilities, change management processes, metrics and SLAs, service descriptions, and other contractual elements. Merely using traditional outsourcing language and practices risks jeopardizing the benefits of Agile. There is no single way of doing this right.
Rather than going with the usual, ubiquitous, and often (yawn) repetitive “top 10 BI predictions” for the next year, we thought we’d try something different. After all, didn’t the cult movie Highlander prove beyond the shadow of a doubt that “in the end there will be only one”? And didn’t the Lord Of The Rings saga convince us that we need one prediction “to rule them all”? The proposed top BI prediction for 2014 rests on the following indisputable facts:
Business and IT are not aligned. Business and IT stakeholders still have a huge BI disconnect (after all these years — what a shocker!). This is not surprising. Business users mostly care about their requirements, which are driven by their roles and responsibilities, daily tasks, internal processes, and dealings with customers (who have neither patience nor interest in enterprises’ internal rules, policies, and processes). These requirements often trump IT goals and objectives to manage risk and security and be frugal and budget minded by standardizing, consolidating, and rationalizing platforms. Alas, these goals and objective often take business and IT in different directions.
Requirements are often lost in translation. Business and IT speak different languages. Business speaks in terms of customer satisfaction, improved top and bottom lines, whereas IT speaks in metrics (on a good day), star schemas, facts, and dimensions. Another consideration is that it’s human nature to say what we think others want to hear (yes, we all want our yearly bonus) versus what we really mean. My father, a retired psychiatrist, always taught me to pay less attention to what people say and pay more attention to what people actually do — quite handy and wise fatherly advice that often helps navigate corporate politics.
Early this year, on January 15, I published our first research on testing for the Agile and Lean playbook. Connected to that research, my colleague Margo Visitacion and I also published a self-assessment testing toolkit. The toolkit helps app-dev and testing leaders understand how mature their current testing practices and organization are for Agile and Lean development.
The Agile Testing Self-Assessment Toolkit
So what are the necessary elements to assess Agile testing maturity? Looking to compromise between simplicity and comprehensiveness, we focused on the following:
Testing team behavior. Some of the questions we ask here look at collaboration around testing among all roles in the Scrum teams. We also ask about unit testing: Is it a mandatory task for developers? Are all of the repeititive tests that can be run over and over at each regression testing automated?
Organization. In our earlier Agile testing research, we noticed a change in the way testing gets organized when Agile is being adopted. So here we look at the role test managers are playing: Are they focusing more on being coaches and change agents to accelerate adoption of the new Agile testing practices? Or are managers still operating in a command-and-control regime? Is the number of manual testers decreasing? Are testing centers of excellence (TCOEs) shifting to become testing practice centers of excellence (TPCOEs)?
DevOps is a movement for developers and operations professionals that encourages more collaboration and release automation. Why? To keep up with the faster application delivery pace of Agile. In fact, with Agile, as development teams deliver faster and in shorter cycles, IT operations finds itself unprepared to keep up with the new pace. For operations teams, managing a continuous stream of software delivery with traditional manual-based processes is Mission Impossible. Vendors have responded to DevOps requirements with more automation in their release management, delivery, and deployment tools. However, there is a key process that sits between development and operations that seems to have been given little attention: testing.
In fact, some key testing activities, like integration testing and end-to-end performance testing, are caught right in the middle of the handover process between development and operations. In the Agile and Lean playbook, I’ve dedicated my latest research precisely to Agile testing, because I’ve seen testing as the black beast in many transformations to Agile because it was initially ignored.
One-Size Software Development Methodologies Do Not Fit All
Dozens of software development methodologies exist, from waterfall to Agile to pure anarchy (Agile has always rubbed me wrong). Mark Kennaley speaks the truth when he says that “there is no ‘best’; there’s only contextual fitness for purpose.” Mark is the founder of Software Development Experts, a software development methodology historian, a consultant, and the creator of an expert system that helps organizations determine the best software methodology to use based on 10 factors: development team size, domain complexity, technical complexity, the geographical dispersion of the development team, time-to-market pressure, enterprise specialization, contract relationships, compliance, criticality, and culture. This makes perfect sense, and so does Mark. Unfortunately, entrenched dogma and high ceremony can obscure what really matters.
Composite, Dynamic Software Development Methodologies Are Best
TechnoPolitics speaks with Mark about how firms can choose the best methodology based on the 10 factors that matter. One size does not fit all. Listen to find out why and how to move forward.
Podcast: One-Size Software Development Methodologies Do Not Fit All
Agile and Lean transformations depend to a great extent on cultivating a good sourcing ecosystem. The decisions you make around the partners and providers supporting your transformation and projects will be at the core of a successful strategy. But sourcing strategy needs to go beyond just resource or services providers (read outsourcing) and address a larger ecosystem made of Agile SW development and delivery choices, collaboration and communication capabilities for distributed teams, and teams' physical work spaces, standard equipment, and office layout.
In September, I published a report on how to source your Agile strategy, that describes what the ecosystem looks like and how to navigate it effectively, the document is part of our larger research container on Agile - The Agile and Lean Playbook. The report gives an overview on how large vendors, SIs, and medium to small consulting organizations can (not) help you with your Agile journey but also what you need to do to be successful. Here are some of the takeaways from the research:
What you think about Agile and Lean might not be what your SI thinks. You need to take control of your own destiny with Agile and Lean. Change your application development and delivery sourcing strategy to embed the best talents around the world to help you make it happen. But be careful with the traditional SIs, because Agile is as disruptive to them as it is you, and if they have not been seriously transforming themselves, it will be hard for them to deliver Agile services to you. Some good alternative new fully Agile players exist, including highly specialized external consulting firms. You might want to start testing the ground with these options.
I just finished analyzing our Q3 2012 Global State Of Enterprise Architecture Online Survey, where we asked a number of questions at the end of the survey on how firms identify and introduce new technology – new technology that your firm is counting on for innovation and competitive advantage. The results underscore a conviction that is growing in me: IT’s “one-size-fits-all” approach to standardizing everything and general aversion to risk isn't cutting the mustard. Simply put, opportunities for competitive advantage through technology-fueled disruption get missed, and this means digital extinction. Some data from our survey of 207 enterprise architects:
58% reported that sales and marketing is among the top five most likely organizations to deliver technology innovations, and they are chasing windows of opportunity that close in months. IT typically takes at least a year to do anything.
52% say there is at least some business dissatisfaction with the level of new technology introduction. The top reason, given by 78% of respondents, is that IT is too slow.
70% of respondents admit their firms have trouble reacting to disruptions caused by emerging technology, and 60% admit to difficulty reacting to change in general.