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.
Last December, I published three things I'd tell your CIO. Since then, I've spent time with dozens and dozens of sourcing and vendor management professionals, CIOs, and leaders of application development and delivery, including last week's Paris Forrester Forums. Most days, I share our ongoing research on what impact today's software-fueled, consumer-led digital disruption has on your ability to meet and exceed the expectations of your customers and the employees serving them. For some folks, software and software development remains a commodity. But for many, the need to deliver great software has taken hold of 2013 planning discussions. With July just around the corner, and as you start 2013 planning, focus on what you need to start delivering great software (remember, software is your business), and keep these three things I'd tell you and your CIO in mind:
Just over 3 months ago, I made note of three things I'd tell your CIO, all of which focused on your need to build a software development competency to help your firm thrive in this age of software-fueled, consumer-led disruption. Since then, we've heard from a number of clients stating that they're having a tough time convincing their executives, from COOs and CFOs through to CIOs, that they need to stop looking at software and app development as a commodity.
Vendors you work with aren't helping. System integrators and consultancies continue to tell your CFO and CEO to outsource your software development work to them, that they can deliver more quickly, and more cheaply, than you can. Software application vendors build their marketing around needing no customization, even "no software." This helps fuel the perception and myths many executives hold that software development, especially app dev, is a commodity.
Recent research published by Phil Murphy and survey data we recently collected in our Forrsights Software Survey, Q4 2011 can help you bust those perceptions and myths and help you show your executives the importance of software development.