Friday, 10 January 2020

the business value of telemetry

Dynamic technologies and infrastructure allow server failures and network issues to be quickly addressed, easily mitigated and, in many cases, reliably predicted. As a result, there’s a new venue opening for IT: end-user telemetry, which enables IT to determine how its internal users are consuming business resources, what type of application issues they are experiencing and how it impacts business performance.

Gartner suggests that infrastructure and operations (I&O) leaders must change their approach and prioritize top-down business-oriented metrics. The research firm predicts that “60% of IT monitoring investments will include a focus on business-relevant metrics” by 2021, up from just 20% this year.

Changing The Game

Of course, it’s one thing to recognize the value of business-driven metrics and another to implement effective monitoring processes company-wide to overcome key barriers to effective digital transformation.

The first step is understanding the fundamental shift required. While current monitoring tools typically rely on application performance monitoring (APM), these metrics aren’t dynamic or granular enough to provide line-of-business value. For example, it’s valuable for IT to understand software issues experienced by end users. If one or more staff members encounter problems accessing specific applications, this data helps address and resolve specific problems and limits employee frustration. However, it does little to advance long-term business strategy.

Now consider the adoption of digital experience monitoring (DEM) tools, which collect a range of employee data in real time, allowing companies to create performance-driven analytics policies. In effect, DEM leverages granular metrics to produce big-picture strategies by employing analytic platforms capable of collecting and integrating data from multiple sources, giving real-time insight into business-critical KPIs.

So what does this look like in practice? Consider the company-wide collection of data pertaining to the use of CRM tools -- are there specific features missing or functions unused that can help businesses save money or increase revenue? Historically, collecting this data relied on user-response surveys or self-reporting, but this presents the double problem of inaccurate descriptions and unverifiable data. DEM tools let IT teams see exactly where apps are performing as intended and where business-driven alternatives can be implemented.

Getting Started

So how do companies just beginning the transition to being an end-user-focused business begin the journey? Below are four key strategies:

1. Start with a plan. Leverage both C-suite and IT insight to define business goals and identify necessary metrics to empower these outcomes.

2. Build out analytics capabilities. You can leverage cutting-edge platforms capable of providing clear, real-time end-user insight.

3. Listen to the end user. A recent Forrester Consulting study created for our company found that only 34% of end users think their satisfaction is a priority for IT. Get to know your internal customers, learn about their frustrations and understand how you can help to ensure that technology is their business enabler, not an obstacle to their productivity.

4. Focus on the big picture. The sheer amount of user data generated makes it easy to get bogged down; use autonomous processes to handle necessary infrastructure maintenance and make use of granular metrics to reduce IT costs, improve service delivery and identify new business opportunities.

It’s clear that IT departments can no longer afford to exist as cost centers but instead need to become strategic drivers of the business. Support and service must align with expected outcomes from the C-suite and the end point -- and it all begins and ends with improved business-user telemetry.
For IT monitoring, it’s business metrics that really matter.

In the past, if a server went down, it would often be catastrophic. Now, with today’s highly dynamic technology infrastructures, server, storage and network failures are no longer a death sentence.

Thanks to the cloud, virtual machines (VMs), containers and software-defined resources, new functionality can often be deployed without the end user knowing. The way the business consumes IT resources is via services or applications, without exposure to the underlying infrastructure.

By 2021, 60% of IT monitoring investments will include a focus on business-relevant metrics, up from less than 20% in 2017.

As a result, the IT monitoring efforts of infrastructure and operations (I&O) leaders should not start with collecting data from the infrastructure, but instead, should start with the business in mind.

Gartner predicts that by 2021, 60% of IT monitoring investments will include a focus on business-relevant metrics, up from less than 20% in 2017.

“Monitoring from the perspective of the business really means that enterprises should try to collect information that helps ascertain a business’ health,” said Will Cappelli, research vice president at Gartner. “Business performance is the only thing that really matters in terms of the goal of your IT monitoring activities.”
Kick Off an IT Monitoring Strategy

Many I&O leaders don’t know where to begin when initiating an IT monitoring strategy.

Approximately 25% of Gartner client inquiries about IT monitoring over the past few years have had some discussion related to where and how to implement it. However, during that time, the answer to this line of inquiry has changed.

Historically, the focus was on starting from the ground up — at the infrastructure “hardware level” of servers, storage and networks — then building up from there. What this starting point failed to deliver was business relevance. Due to the changing nature of infrastructure and application architecture, it no longer makes sense to begin data collection efforts from a perspective that is unlikely to provide insight into the end-user’s experience.

The good news is that with modern digital experience monitoring (DEM) and application performance monitoring (APM) tools, visibility into metrics that matter to the business is becoming easier to obtain.

For organizations just starting their IT monitoring journey, Gartner recommends:
Start the enterprise’s IT monitoring strategy by deploying technology that provides insight into the end-user perspective.
Implement custom instrumentation, where necessary, to integrate business-relevant metrics once basic end-user monitoring is deployed.
Focus on how IT aligns with the business — the initial business metrics should concentrate on the “stage” of the business-to-IT relationship.
Incorporate requirements from other monitoring stakeholders, especially line-of-business and application owners.
Build your IT monitoring approach to be delivered as a service by ensuring that non-IT operations personnel are able to select only the data that is important to them

Infrastructure and operations leaders must use a business-oriented, top-down approach and identify ways to improve overall monitoring costs and delivery.

“Remember that the goal of such a service is not so much for central IT to monitor digital business processes directly. Instead, it’s meant to give digitalized business units the power to do their own monitoring in a way that is effective and flexible, but, at the same time, cost-efficient,” said Cappelli.

Sunday, 13 October 2019

eyes wide shut

As a youngster one of my favourite authors was the American humorist, James Thurber. Of all the pieces of his I read, the one that I remember most concerned his English teacher′s obsession with the use of "the container for the thing contained" as a figure of speech. For example, we might say, "Today London elected a new mayor." Of course, London would do no such thing, it is an inanimate city of roads, parks and buildings and roads parks and buildings have not yet been given the vote. It is the people of London that elect mayors but the use of the container for the thing contained is a common trait with humans and everyone understands it.

Another similar manifestation of this type of behavioural trait concerns certification. We imagine that the owner of a certificate possesses not just the knowledge originally required to gain the certificate but also the talent and skill to use that knowledge effectively. The fact that a standard exists also implies that the standard is reputable. Take the driving license, most of us possess one and most of us imagine ourselves to be good drivers but then most of us usually only drive in safe conditions, in familiar surroundings where the behaviour of the vehicle and other road users are reasonably predictable. How well do we cope when faced with unexpected or extreme circumstances?

Which brings me on to management. How do you get groups of people, large or small, to successfully work together towards a common goal? Achieving goals as an individual is difficult enough. Managing a team must be nigh-on impossible and, strange as it may seem, the more intelligent the individuals in the team, the more of a problem it seems to be to manage them. The difficulties in managing teams of highly intelligent individuals are highlighted by the tremendous rate of failure of IT projects, as reported by industry analysts the Standish Group and others. I′m sure you′ve all heard it before but the usual figure quoted for IT project success ranges from the fourteen percent in 1994 to the thirty-two percent in 2002. Still only a third of projects are successful.

Earlier in the year I attended the BCS PROG-M conference "Getting Better Value from IT Investments" where much was made of the tremendous rate of failure of IT projects but the interesting thing for me was, although most of the speakers expressed shock over the incredible percentage of failed projects, none of them made any real attempt to probe the underlying reasons why this should be. There was little or no mention of how we approached the management of projects and whether that might have an effect on the success or failure of a project. In fact, I recall one of the speakers saying, "we know we′re doing them right, we′re just picking the wrong ones to do!" They have now started an initiative to help them discover which projects will succeed before they start them - good luck guys!

Getting back to the industry analysts though, anyone visiting any of their sites must be aware that they do much more than just research into the numbers of project failures, they also produce analyses of the cause of failure, something that seems to have been missed by the presenters at the conference. Since 1994 the Standish Group have been publishing the annual Chaos report, which presents the ten major factors that contribute to project success, listed here in order of importance:

  1. User Involvement
  2. Executive Management Support
  3. Clear Statement of Requirements
  4. Proper Planning
  5. Realistic Expectations
  6. Smaller Project Milestones
  7. Competent Staff
  8. Ownership
  9. Clear Vision & Objectives
  10. Hard-Working, Focused Staff

The lack of any of these factors will have dramatic effect on the success of a project but they are not technical factors, so we can′t look to technology for solutions. The competence of the staff is way down the list at number seven and staff productivity and focus is at number ten, so we can′t look to our subordinates for solutions either. This leaves us with only one avenue to examine - the way we manage the projects - but, as we saw at the project managers conference, they don′t believe that there is a problem with the way they do things.

This where governance comes in but, for reasons I′ll explore later, I don′t think it will make a blind bit of difference, although it does look as if it is going to overtake agility in the quest to be the new black.

The word governance is just a synonym for government and in that sense has to do with how we govern our organisations. It is a reaction from the shareholders to our inability to manage effectively. The industry has constantly failed to deliver on its promises, this has caused businesses to lose money, and market position and has damaged the reputation of some companies. In turn, groups of shareholders have become unhappy and are now insisting that the board of directors establish a set of regulations and standards that define their responsibilities and also provides a means of measuring their effectiveness at setting and implementing the strategies necessary for the survival of the organisation. Those responsibilities include certifying that risk and resources are managed properly and that due diligence is performed when critical decisions are being made. The board will also be expected to produce a maturity model showing the stages it will go through on its path to optimal effectiveness.

Governance is another standards movement but unlike previous ones - ISO, CMMI, etc, - this one is self certifying. The board itself will be responsible for setting the standard and assessing its performance against it.

On the face of it, you may well think that governance is no bad thing and most of us will probably agree that it not before time that management was made more accountable for their actions and decisions but how they imagine they are going to do this is where I see the problems arising. Don′t get me wrong, I think governance is a well-intentioned idea and where it succeeds it will be prove to be beneficial but where it won′t succeed is where it is needed the most. In other words, if you need governance then governance probably won′t work for you.

According to the IT Governance Institute the intention is that IT governance will:

  1. Align IT strategy with business strategy.
  2. Cascade strategy and goals down through the enterprise.
  3. Provide organisational structures that facilitate the implementation of strategy and goals.
  4. Insist that an IT control framework be adopted and implemented
  5. Measure IT′s performance.

Well "Duh!" Isn′t this management 101? If your managers are not already doing these things, why are you employing them and what the heck are you paying them to do? If your managers have neither the wit nor the wisdom to be following the most basic of management principles, I find it hard to believe that the implementation of a governance standard will improve their performance in either the short or the long-term. Good leadership is necessary for success but conformance to a management standard won′t give you good leadership, particularly when it′s your own standard. You may get your container but will you get the thing contained?

The theory behind governance is that it will improve leadership and create corporate cultures that enable organisational learning, thus improving likelihood of success. In practice what is likely to happen is that management will not be too interested in developing their own standard and will hire external consultants. Performance measurement will be done by simply picking whatever metric shows them in the best light. Any failures can be remedied by choosing a different metric or blaming the external consultants for delivering a faulty governance plan.

Do you think I sound a wee bit cynical? A recent report by management consultants Grant Thornton, showed that while the majority of large companies said they comply with the rules on corporate governance outlined in the Turnbull report, 80% have failed to truly embrace its principles. "Instead of wholly embracing the changes, companies are merely ticking boxes to ensure that they comply with the bare minimum rather than embracing the spirit."

Creating cultures and environments that foster innovation and creativity is what leaders do, you know a leader because you will see them in front with people behind, following. Managers, on the other hand, are usually found behind the team, shepherding them forward, inducing their progress with either a carrot or a stick, trying to keep them on the straight and narrow.

In my time I have been involved with companies all over the world, I have met and worked with many excellent leaders and I continue to do so. It′s one of the things I enjoy most about my job. I have learned much from them, they have motivated me to do good work that has surprised even me and I am truly grateful that I have had the opportunity to have been associated with them. Charismatic and passionate about the things they do, leaders are extraordinary people and usually found leading high-performance teams of enthusiastic and highly skilled individuals, which they attract and keep.

The lack of leadership in our industry is one of our biggest problems and we won′t solve it by instituting more management, particularly the command and control style that seems so prevalent today.

Though well intentioned, standards initiatives like governance, ISO and the CMMI are too open to abuse by the process mavens and are notorious as the surest ways to stifle innovation and creativity when applied ineptly.

Finally, a parting shot at the project managers: just to confirm that I′m not the only one that thinks there are problems with the way that we manage projects, the Project Management Institute released a paper last year entitled "The Underlying Theory of Project Management is Obsolete". Time to throw away your Gantt charts guys!



First published in Application Development Advisor

lazy agile developers

..said my colleague. "How so?" I enquired.

"Well!" he said, "when we do planning, I notice that one or two of the guys are always happy to suggest we only ever attempt to match our previous velocity, they never try to improve. If anyone suggests we aim for more points than we achieved before, they are quick to shoot them down. If that's not laziness, I don't know what is?"

"OK" I replied, "if we set aside the issues of point inflation and the like for the moment, I still don't see how Agile has made anyone lazy? If it's true that these individuals are, indeed, lazy, then what Agile has done is simply made this visible. I would guess that they were always lazy, it's just that nobody really knew before because work and the effort required to complete it were hidden. It's only now that we've introduced transparent methods that these issues have become apparent."

That is if, and only if, they really are lazy. My guess is that they are fully aware of the nature of velocity and the problems of story point inflation.

The reality is that Agile doesn't make you lazy but it does highlight the fact if you are.

Thursday, 13 July 2017

the death of tdd

Several years ago, Colin had the pleasure of working with Mike and his team as they embarked on their Agile journey. As with many teams, they went through stages of what might be termed maturity. First, they learned how to plan and work iteratively, later they learned incremental working. Finally, they reached a point where they wanted to improve their engineering practices and so Colin had introduced them to Test-Driven Development. Now he was sitting listening to Mike, the technical team lead for the team, explain to him why TDD wasn’t working for them.

"You see, TDD forces you to decouple everything” he said, “You taught us the SOLID principles, JSP and the Composed Method pattern?” He looked down into his cappuccino, “you introduced us to clean code, too. We’ve followed the rules in the book to the letter and now we’ve found it’s just too difficult to write code.”

I was curious about his statement, “What do you mean it’s too difficult?” I asked.

Mike was hesitant at first but eventually started to open up, “TDD forced us to produce a disintegrated codebase that is too decoupled. It makes it difficult to follow the flow of logic through it. We call it test-induced damage, caused by us sticking to the rules. Producing even the smallest piece of functionality seems to take an age now and has become a bit of a chore.”

Taking a moment to consider, Colin asked him, “Do you remember the seven deadly sins of design? Do you remember the deadliest sin?”

Mike looked at him in puzzlement, “Of course, not doing any is the biggest sin but we’ve been doing design as per the principles you taught us and it’s just not working.”

Colin explained, “You followed all my advice except for the most important piece: the principles are not rules; they are guidelines. TDD cannot and does not make design decisions, only people can do that. You and your team made the design decisions that produced your fractured codebase, not TDD.”

Mike considered this for a moment before responding, “I think you’re right, we’re all looking for a simple rule to follow and if following that rule leads to problems, we blame the rule, not the fact that we followed it blindly.”

“You’re not actually doing design!” Colin went on, “The mindless application of a rule, or even set of rules, is not doing design. Design is a mindful activity that requires the awareness of different, sometimes conflicting, drivers and the application of judgement to make appropriate trade-offs between them. It’s your ability to make those judgements and how well you make them that determines your competence as a professional.”

“I feel such an idiot,” said Mike, starting to look a bit sheepish, “I can see it now. We picked up the SOLID principles, used them as a Golden Hammer and saw every design opportunity as a nail.”

He looked Colin in the eye and said, “We’re going to stick with TDD but, in future, I’m going to make sure the team is more mindful, is aware of the decision making aspect of design and takes ownership of their decisions.”

“Mindfulness is what it’s all about,” said Colin. ”It’s underlies everything we try to teach. The principles and practices are there simply to make you think about what you’re doing and why you’re doing it.”

After making sure Mike would keep him updated about progress, Colin left the room and as he walked away, he heard a line from Paul Simon’s song, The Boxer, going round and round in his head, “A man hears what he wants to hear and disregards the rest.”

Tuesday, 13 September 2016


“RJ,” said Willy, the CEO, putting his arm around RJ’s shoulders, “we made you CTO because you said you could deliver. Foofle have launched a cloud product and it looks like we’ll lose our market share to them. We can’t wait a year, what’s the earliest we can launch Project Synergy? Change the team if they can’t deliver!”

Richard Jones (known as RJ to everyone except his mum) went back to his office to think about the situation. Willy was right; he was promoted because he promised to deliver Project Synergy within a year. Unfortunately, things weren’t going well. He had skilled engineers and he’d planned everything thoroughly but things weren’t working out. His DBA, Donald, had broken his leg snowboarding and couldn’t produce Synergy’s schemas, tables and queries. The middle-tier team were working on defects while waiting for Donald to recover. The UI team were finished with Synergy and had moved on but their team lead was worried about rework. He wouldn’t stay CTO for long at this rate. At his wit’s end, RJ picked up the phone and called Value Driven Software.

In their first meeting, Colin talked to him about incremental delivery explaining that, rather than working on different layers of the system, each team should work on a feature. This meant the product could be released incrementally, a feature at a time. Instead of waiting a year for the completion of every layer before releasing, they might release the first feature within weeks. RJ also learned that features needed cross-functional teams to deliver them.

When discussing it with the team Mike, the team lead, told him why they work the way they do, “We’ve considered working in cross-functional teams before but dismissed it because we don’t have enough DBAs and UI experts to have one of each in every team.” He paced in front of them, “We need to make sure that all DB and UI work complies with standards.” Colin relaxed back in his chair, “Don’t you have the tools and knowledge to do the work yourselves?” he asked. Mike stopped pacing and stared at him, “Of course we do but I’ve just told you SQL and UI work must be done by qualified people. Imagine if an engineer made a mistake and deleted a database table in production. It could bring the whole system down!” Colin held his gaze, “But what if you do the SQL and UI work yourselves but have Donald and Emelie validate it?” Emelie was head of UI. Mike and Donald were still dubious but RJ suggested they give it a try anyway.

Colin explained that a cross-functional team isn’t a bunch of specialist sub teams. “That’s no different from having separate teams. You’ll still have problems when someone’s overloaded or not available. You’ll also have people sitting idle when there’s not enough work for them.” Rising from his chair he continued, “What we need is a team of generalists that can turn their hands to anything. That way we can maintain the flow of work through the system.” Raising his voice slightly he went on “That doesn’t mean people can’t be experts. Of course they can! Think about it though, Donald. What percentage of the DB work requires all of your expertise?” a murmur went through the team but they didn’t respond, “Is it fifty? Is it ninety? Or is it more like five? Or maybe only one percent?” eventually, Mike spoke up again, “You’re right,” he said, “we do need Donald and Emelie but we don’t need them every minute of the day. We just need them to validate what we’re doing.”

Colin helped them re-organise so they could deliver incrementally. After some horse-trading between the stakeholders and developers, a plan emerged. It wouldn’t have everything they wanted but the first release would satisfy the market and the developers were confident they could deliver it. RJ thought the session was brilliant. Seeing all the work planned out, with commitment from the team put a bounce in his step. Now he was really looking forward to seeing Synergy delivered

“I don’t get it RJ,” said Willy, “six weeks ago we were a year from delivery but now you say you can deliver in six weeks.” He leaned forward with both hands on the edge of the boardroom table, “You haven’t changed the team as I suggested, what’s different? How did you do it?”

RJ smiled to himself, Willy might not think he’d changed the team but actually he had completely changed the team.

Tuesday, 13 October 2015

planetary system

Until 1781, humans had believed there to be only six planets (including Earth) in the solar system. Although many eminent astronomers had previously spotted the planet Uranus, they had always presumed it to be just another star and listed it as such.

In March 1781, William Herschel made a series of parallax observations through his telescope and believed he had discovered a comet. On 26th April that year, he reported his find. Only after feedback on his report from the Astronomer Royal and independent confirmation from European astronomers, did he finally concede he had discovered a new planet. After some discussion, Berlin astronomer, Johann Elert Bode, named the planet Uranus.

Herschel brought the number of planets in the solar system to seven. Later, Alex Bouvard noticed some unexpected perturbations in Uranus’s orbit and predicted the existence of yet another planet. Johann Galle visually confirmed Neptune’s presence in September 1846 and brought the number of planets to eight.

No, they didn’t! None of those people increased the number planets at all. They were simply the first people to see and catalogue the ‘new’ ones. For thousands, if not billions, of years, the number of planetary-sized rocks orbiting our sun has been eight. You might argue about the definition of ‘planetary-sized’ but according to the current definition, that number is eight, has always been eight, and is likely to remain eight until an astronomical catastrophe occurs.

Similarly, your project didn’t change from a six-month project into a three-year project. Herschel, et al didn’t launch new planets into space and nobody came along and invented new requirements for your project. All of these things existed from the beginning.

Your project is like astronomy. In its early days, none of the participants had the skills or technology to identify all of the planets. Sorry, I mean requirements. That doesn’t mean they weren’t there. It simply means you didn’t know about them.

Now, we have better knowledge and tools and we’ve used them to look at your project. We’ve discovered some stuff those early pioneers missed but thankfully, we’ve found it now.

Aside from the Geocentrics and possibly the Flat-Earth Society, I imagine most people of the eighteenth and nineteenth centuries welcomed the new knowledge that expanded the number of known planets. The discoverers of those planets reaped handsome rewards as heroes of science.

Compare this with the individuals that discover the hitherto unknown requirements in your project.

Will you treat them as the heroes they undoubtedly are and reward them for expanding your knowledge of the known requirements?

Sunday, 13 July 2014

stakeholder value

Willy the CEO slammed down his mobile after another ear bashing from his biggest investor. He took a breath, dialled the newly appointed CTO and explained the situation. “We’re in the last chance saloon, RJ. The board have given us six months to fix what we’re delivering from Engineering. We need to prove our value and fast!” Willy sighed and continued, “They’re pushing me to consider outsourcing everything.”

Sitting in his office, RJ took a deep breath and thought about his team’s performance, “My teams are solid. We deliver on time and we deliver high quality, well-tested code but still the stakeholders complain about the product. What’s going wrong?” He reached for the phone and called Colin, the coach.

Sitting in RJ’s office some days later, Colin explained to RJ about stakeholder value, “Stakeholders sponsor a product because they believe it will give them benefit or value, if you like. Your teams need to focus on delivering this value to the stakeholders.” “I thought we were doing that,” said RJ sounding confused. “You’re focussed on building things for end-users; you need to understand stakeholders are customers, too” said Colin.

He stood and moved to the whiteboard. He wrote one line,

“How Do You Measure Stakeholder Value?”

RJ looked blankly at him, “What do you mean?”

“Another way of putting it is; how do we know we’re building the right thing?” replied Colin. “But we place a very high emphasis on quality; we have thousands of tests to prove we’re building the right thing!” said RJ.

Colin took a deep breath, “What you have are thousands of engineering tests. Engineers created those tests for their benefit and they are extremely valuable but they can only tell you if you’ve built the thing right, they can’t tell you if you’ve built the right thing.” He paused while RJ thought about this. “Without stakeholder input you can never know if you’ve built the right thing, you’re just stabbing in the dark.”

“So we need to introduce stakeholder tests?” asked RJ. “That’s only part of it,” continued Colin. “We also need to make sure the thing we’re building right is the most valuable thing we can build. It’s no good building a perfect thing that nobody wants,” he said with a grin.

RJ arranged for Colin to meet with Lana, the Business Analyst and some key stakeholders at their own offices. With everybody seated round a table, Colin took a handful of features and got the group to rate them on scale of 1 to 5. After some bickering amongst the group, five features scored as highly valuable. Of these, the group picked ‘Clicks-to-Cash’ as their most valuable feature.

Colin then started to ask questions about the value of the feature. “According to our site analytics, about 30% of customers with more than three items in the basket drop out before payment.” said the Head of Marketing, “the checkout process has far too many clicks and is losing us sales. I can get you actual figures if you like.”

“Thanks, I’d appreciate that. We can judge the success of ‘Clicks-to-Cash’ simply by recording what percentage of customers with more than three items in the basket drop out before payment after the fix compared to the percentage before the fix.” Suggested Colin.

The meeting continued, dealing with every item on the feature list. Later, Colin discussed the outcome with RJ, “Now we know what the most valuable things to work on are. We’ve also agreed with the stakeholders what they will look like – acceptance criteria, if you will. Lastly, we’ve agreed how to measure the success of the features. All of these have to be known and agreed if we’re to deliver stakeholder value”

After re-scheduling the work, RJ’s teams continued delivering high-quality code but this time, he knew they were also delivering high-value features. If they continued with this approach, the board would soon change their minds about outsourcing them.

“It seems so obvious now,” said RJ to Colin. “I can see that before we were building high quality features we thought might be wanted and might be valuable. We didn’t ask the stakeholder’s opinion because they were too busy to come to us but now I realise we have to go to them.

the business value of telemetry

Dynamic technologies and infrastructure allow server failures and network issues to be quickly addressed, easily mitigated and, in many cas...