Month: October 2019

Article originally posted on InfoQ. Visit InfoQ

Product thinking focuses on outcomes to maximize the success of your customers, argued Jeff Patton in the closing keynote at the Agile Greece Summit 2019. The things that make a product good are results of customers seeing, trying and using your product; they happen after you ship it. Product delivery is the beginning, not the end.

Patton explained that there’s nothing more satisfying than seeing someone use and love something that you worked hard to build:

The most satisfied developers I know feel like what they’re doing is meaningful. And, it’s always been my experience that the fastest way to motivate a team member is to get them in front of the people actually using what they’re building. It feels better than building stuff that meets requirements, or earns cash. Even though it may do both those things too.

If you’re a product thinker you’ll need to know who your customers are and how they’ll use your product, said Patton. Everything we do revolves around maximizing their success – the outcomes. Patton mentioned that the business leader bringing you requirements isn’t likely the one who will see, try, buy or use your product. We often get bound up trying to please the business stakeholder or the product owner who wants that output delivered on time, he said.

In the InfoQ article Becoming Outcomes Focused, Patton stated that we need to become focused on outcomes and adapt our way of thinking and our processes to continuously release small changes to our products and services. He suggested to talk more about outcomes and remember that ideally we want a product that’s built to last for as long as possible

InfoQ spoke with Jeff Patton, product design consultant and author of User Story Mapping, about product thinking after his talk at the Agile Greece Summit 2019.

InfoQ: How do you define product thinking?

Jeff Patton: Product thinking focuses on outcomes.

I’ll often start talks by asking people, “What are the characteristics of a good product?” You can predict the responses. Things like: easy to use, solves a problem, and makes us money. I’ll point out to people that no one said: delivered on time, or under budget. Everyone knows those aren’t product things – those are project things.

All the things that make a product good are the things that happen after the product ships. And they’re things that are results of customers seeing, trying and using your product. It’s up to them to tell you it solved a problem or that it’s easy to use. It’s only after enough of them buy and use your product and service that you’ll make lots of money. Those are the outcomes.

I’m not saying you don’t need to deliver something predictably and at high quality, but that that’s the beginning of your process, not the end.

InfoQ: What are the benefits from applying product thinking?

Patton: Your business will be more successful. And you’ll feel better about yourself.

You shouldn’t believe anything I say because I’m just a consultant. Instead, I’ll quote the richest person in the world, Jeff Bezos: “Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing.” Bezos didn’t say product thinking – he said we’re focused on serving the customers. Everyone at Amazon knows he means Amazon customers; not Jeff Bezos, not executives, not their immediate bosses.

And before you start thinking that Bezos is a wonderful guy who only cares about people, remember Bezos knows that he’s converting that customer delight into money his company spends – and he spends too, I’d imagine. It may not surprise you to learn that Bezos and Amazon don’t spend tons of time and money worrying about customers who they can’t earn money from. They understand the customer value converts to dollars. That’s the way product thinking works.

InfoQ: If using a product-centric approach is so beneficial, why don’t companies naturally do this?

Patton: Oddly, our natural desire to do a good job for our customers is what gets in the way.

Imagine going to a restaurant and having a really good waiter. The waiter gives you advice on what to order, and encourages you to order the things you love, and lots of them. The waiter is attentive and provides great service to you, his customer.

In business, and often in our processes, we work hard to provide good service to our customers the same way. Sometimes we see our customers as business stakeholders, sometimes as the users of our product. And we strive to give them what they ask for. But, go back to the waiter in the restaurant. The waiter isn’t the product owner, the waiter didn’t make the choices about the restaurant location, decor, or what’s on the menu. The waiter didn’t set the pricing for things on the menu. And the waiter doesn’t need to worry about the viability of the restaurant. The waiter isn’t the product owner – he’s actually part of the restaurant product.

In business, sometimes well-intentioned people switch into the good waiter posture and try to do their best for the people who are asking them for product features. And, even worse, sometimes business leaders switch into a demanding customer mode and treat their people like waiters. Sometimes we all lose sight of the business we’re trying to grow and move our focus to how fast we deliver on the promises we make to each other. Doing that is important – but isn’t necessarily what earns money for the organization.

Taking on a product-centric posture means you’re always balancing individual customer desires with the needs of a broad class of customers – most of which you’ll never meet. You’re balancing customer needs with the needs of your organization to serve customers who pay for its services, because your company likely thrives on the money your customers pay for those services. Sometimes the right answer is ignoring the needs of small groups of customers who don’t represent much benefit to your organization. This can feel wrong. Sometimes the right answer is questioning what a stakeholder asks for in order to better understand how it moves the organization forward. Not only can this feel wrong – it can feel a bit “career limiting.”

So who you treat as your customer, and how you choose to make them happy, can get in the way. Think more like the restaurant owner, and less like the waiter.

InfoQ: What can we do to test or validate a product hypothesis?

Patton: There are already heaps of stuff written on this. Look at books like Lean Startup and Lean UX, books on design sprints, books like Lean Product Playbook. By the time you read this, my friend David Bland will have released his new book Testing Business Ideas, containing 300+ pages and scores of ways to test ideas. This is the area where process and practice are evolving fast. We’re going way beyond “build a prototype” here.

It all starts with exposing your risks and assumptions, then making room in your process to test those. Those sorts of books will give you ideas on how to do that, and using a dual-track style process where learning carries equal weight with development will help.

Article originally posted on InfoQ. Visit InfoQ

Clint Checketts, core committer of Micrometer Project, recently spoke at SpringOne Platform 2019 Conference about Micrometer monitoring and alerting framework. Micrometer provides a simple facade over the instrumentation clients for different monitoring systems that allows developers to instrument JVM-based applications. Not only can it be used for recording metrics, but also a wide range of observability features when used along with other tools like Prometheus and Grafana to provide application resiliency.

Checketts discussed the importance of dimensional metrics in the overall monitoring of systems. Similar to other products like Google Prometheus and Netflix Atlas, Micrometer provides the support for managing dimensional time-series based metrics data.

He talked about the difference between dimensional metrics and hierarchical metrics. Dimensional metrics track metrics differently, in that they are tagged where each metric consists of a name and can contain multiple statistics. This allows for better querying flexibility and extensibility. It’s not just about monitoring for errors, but actually understanding the overall health of the system.

Observability is basically a tripod of three pillars:

• Logging: Detailed information about individual actions. Libraries include SLF4J, Log4J, Logback, and JUL.
• Metrics: Aggregate information about application features. Libraries include Micrometer, Prometheus, and Drop Wizard Metrics.
• Tracing: Sampled information across multiple services. Zipkin library falls into this category.

Checketts also discussed the key logging features and how Micrometer compares to traditional logging. It supports common logging with destinations such as Elasticsearch. It can also be used for adding cross-cutting metdadata like nested diagnostic contexts (NDC) to the log messages.

Micrometer terminology includes the following components: Meter (what is measured. Examples: counters, timers, and gauges), MeterRegistry (a meter store abstraction), Tag (a meter dimension) and Metric (an individual measurement).

Checketts showed how to use the monitoring framework in different applications, and gave the examples of Micrometer using Docker, and Kotlin using SimpleMeterRegistry and CompositeMeterRegistry classes.

He discussed the Micrometer integration in Spring based applications. The support is built into Spring, and the class just needs to be autowired. Another demo showed how to set up a Spring application with Micrometer and enable the Prometheus Actuator. Also, the Metrics Actuator is powered by Micrometer.

Resilience4J, a fault tolerance library, includes Micrometer support and can be used to monitor the statistics like circuit breaker state and success/failure rates. Checketts also showed how to get custom frontend metrics from an Angular application, sending metrics to Micrometer backend every five seconds.

You can download the sample code shown in the presentation from the Github project.

Article originally posted on InfoQ. Visit InfoQ

InfoQ Homepage Presentations More Than a Scrum Master?

• Related Editorial

Article originally posted on InfoQ. Visit InfoQ

InfoQ Homepage Presentations Design for Prosperity

• Related Editorial

• Related Vendor Content

Article originally posted on InfoQ. Visit InfoQ

Mario Areias presents a different way of engaging security, and, in doing so, he’ll make the case that security can deliver value without necessarily being a blocker.

By Mário Areias

Article originally posted on InfoQ. Visit InfoQ

Productivity decline and technical debt, as often seen in agile development, can be prevented by separating unsolved problems into premature and foreseeable. It shifts the discussion about unsolved problems from importance to likelihood. With small but essential adjustments agile can be kept sustainable. With this insight, developer-architect differences and team psychology gaps can be bridged.

By Bas Groot

Article originally posted on InfoQ. Visit InfoQ

In a recent paper published on Nature, Google researchers claim they programmed a quantum processor to perform a task that would require 10,000 years on a state-of-the-art classical supercomputer. Google’s claim did not entirely persuade IBM researchers, who proposed an ideal simulation of the quantum task which, they argue, only requires 2.5 days on a classical computer and provides greater fidelity.

The task Google chose to demonstrate quantum supremacy consists in sampling the output of a pseudo-random quantum circuit, which produces a set of bit-strings with a certain probability distribution. This task has an immediate application for the generation of certifiable random numbers. Using their 53-qubit Sycamore processor, Google researchers showed sampling one instance of a quantum circuit one million times required 200 seconds.

The same task carried through using a simulation of the same quantum circuit run on a classical computer would take, say Google researchers, 10,000 years.

This dramatic increase in speed compared to all known classical algorithms is an experimental realization of quantum supremacy for this specific computational task, heralding a much-anticipated computing paradigm.

Besides playing the role of a benchmark, the simulation on the classical computer was also used to demonstrate the correctness of the result produced by the quantum processor, as measured by its fidelity. The way Google set up the classical simulation was straightforward. Indeed, simulating a quantum computer is feasible in reasonable time for quantum circuits using up to 43 qubits. This is due to the possibility of simulating the 2⁴³ quantum states using a sufficiently large RAM memory. Once the limits of maximum available memory are reached, simulating a larger qubit number requires running the algorithm on a distributed system with a cost that inevitably, say Google researchers, grows exponentially. Furthermore, any future improvements in quantum simulation algorithms will be likely offset by hardware improvements on larger quantum processors, they say.

The relevance of Google experiment is not only theoretical, for its implications on quantum supremacy. In fact, fidelity is greatly affected by quantum gates error rates, which is a major issue in quantum computing since the lack of error correction techniques means noise can heavily affect measurements and induce errors. So, demonstrating the possibility of attaining high fidelity, i.e. low error rates, in a practical quantum processor is of fundamental importance to the future development of quantum computing. It also matters because of a number of a technical advances that were necessary for this experiment to work out successfully. In particular, the paper authors mention three fundamental breakthroughs: the development of fast, high-fidelity gates; a new technique to calibrate and benchmark the quantum processor based on cross-entropy; and the ability to accurately predict quantum information behaviour as it scaled to a larger system.

With their result, Google researchers claim they have proved two distinct results: that a quantum processor can perform a task in a sufficiently large quantum space and with sufficiently low error rates; and that a computation task can be devised that is easy for a quantum processor and hard for a classical computer. Those two intermediate results are what leads Google researchers to claim they proved quantum supremacy.

The second point is what IBM researchers are objecting to. In a second paper submitted to Quantum Physics, they show how secondary storage can be used to extend the range of quantum circuits that can be practically simulated on a classical system and proved their result using IBM Oak Ridge National Laboratories supercomputer. Specifically, they say, a Sycamore circuit with 53 and 54 qubits can be simulated with high fidelity in a matter of days.

When [Google researchers’] comparison to classical was made, they relied on an advanced simulation that leverages parallelism, fast and error-free computation, and large aggregate RAM, but failed to fully account for plentiful disk storage. In contrast, our Schrödinger-style classical simulation approach uses both RAM and hard drive space to store and manipulate the state vector.

In their paper, IBM researchers are also defending a more radical philosophical stance on quantum supremacy, though, claiming the term “quantum supremacy” is causing confusion due to its fundamental misinterpretation.

Quantum computers will never reign “supreme” over classical computers, but will rather work in concert with them, since each have their unique strengths.

IBM researchers are not the only ones to be critical to that term, as its original proponent, John Preskill, has summarized in a recent article. One of the ways the use of that term is not doing a great service to quantum computing is pointedly highlighted by Preskill with reference to Google’s successful experiment:

The catch, as the Google team acknowledges, is that the problem their machine solved with astounding speed was carefully chosen just for the purpose of demonstrating the quantum computer’s superiority. It is not otherwise a problem of much practical interest.

Others, though have been more positive.  Speaking to the New York Times Scott Aaronson, a computer scientist at the University of Texas at Austin who reviewed Google’s paper before publication, likened Google’s announcement to the Wright brothers’ first plane flight in 1903:

The original Wright flyer was not a useful airplane, But it was designed to prove a point. And it proved the point.

All in all, it seems it is definitely too early to say whether Google achievement will be recorded in the annals of quantum computing. What seems to be widely recognized, including by Preskill and IBM researchers, is that Google’s achievement represents a pivotal step in the evolution of practical quantum computers, opening the way to the creation and use of noisy intermediate-scale quantum computers for more cogent applications.

Article originally posted on InfoQ. Visit InfoQ

Recently, Amazon announced the general availability of the Anomaly Detection feature in Amazon CloudWatch, a monitoring and management service providing customers with data and insights from AWS, hybrid, and on-premises applications and infrastructure resources. With the new anomaly feature in CloudWatch, customers will be able to isolate and troubleshoot unexpected changes in metric behavior of their resources.

The tech giant announced a preview of the anomaly detection feature for CloudWatch earlier this year, in July. This new feature for CloudWatch applies machine-learning algorithms to continuously analyze system and application metrics, determine a healthy baseline, and surface anomalies with minimal user intervention. Moreover, the foundation of anomaly detection lies in an accumulation of over 12,000 internal machine learning models. However, according to a tweet by Corey Quinn, cloud economist at the Duckbill Group:

For the impatient, this feature is basically using Exponential Smoothing (https://en.wikipedia.org/wiki/Exponential_smoothing) buried under the umbrella of Machine Learning to develop confidence intervals around CloudWatch metrics.

CloudWatch users can enable the anomaly detection feature through the AWS Command Line Interface, AWS SDKs, or AWS CloudFormation templates. When activating the feature for a standard or custom CloudWatch metric, it will start analyzing historical values of the chosen metric using statistical and machine learning algorithms. These algorithms will determine predictable patterns that repeat hourly, daily, or weekly for the metric. Subsequently, anomaly detection will create a best-fit model to help users differentiate normal and problematic behavior for the metric, which they also can adjust and fine-tune, by for instance excluding specific time ranges from the data that is used to train the model.

 
Source: https://aws.amazon.com/blogs/aws/new-amazon-cloudwatch-anomaly-detection/

Finally, on top of the generated models, users can create alarms based on when a metric is outside of its set anomaly thresholds. Or the user can in the CloudWatch console go to Alarms to generate an alarm based on Anomaly Detection. Furthermore, users can specify the type of action when the alarm executes, for example, sending a notification to an SNS Topic, which will send an email to its subscribers.

Source (screenshot): https://www.youtube.com/watch?v=8umIX-pUy3k

Users who currently leverage third-party tools such as Datadog or Splunk for anomaly detection could consider using the CloudWatch Anomaly feature instead. A respondent on a reddit thread about the new feature stated:

This was one of the few reasons I used Datadog years ago. I was surprised it took them this long to add it.

Anomaly Detection is available in all of Amazon’s commercial regions, and more details of the feature are available on its documentation website. Furthermore, the use of this feature is free except for the use of CloudWatch alarms – pricing of CloudWatch itself is available on the pricing page.

Article originally posted on InfoQ. Visit InfoQ

The 2019 news cycle within the “cloud native” corner of the world has been abuzz with a word previously thought outmoded by the rapid rise of containers: “hypervisor.” This article explores the motivations behind this, focusing on security, user experience, and isolation flexibility, and concludes by speculating on the future direction of development within the cloud and container industry.

By Phil Estes

Article originally posted on InfoQ. Visit InfoQ

Team feedback meetings can help teams to define their own goals. Such meetings increase focus and motivation within teams, and with proper transparency they enable alignment between the teams’ and organizational goals. In his talk at Agile Leadership Day 2019, Michael Sommerhalder presented how Digitec Galaxus combined quarterly team feedback meetings and team missions with OKRs.

Sommerhalder mentioned that because of the annual performance review each team member had with their respective team lead, team members tended to focus on their own further development, as opposed to the development of the team as a whole. They should ideally be working together, instead of performing as a collection of people pursuing their own individual goals.

By moving the goals from a personal to a team level, they hoped to achieve better teamwork and more focus/alignment within the teams. By each team creating their own team goals, they also wanted to increase the autonomy of the teams. Sommerhalder stated that they aimed to increase transparency and alignment on a bigger scale by having team goals be visible across the whole company.

The CEO came up with the idea of giving OKRs a try. Sommerhalder said that they expected OKRs to increase focus and alignment within the teams, give them more autonomy, and at the same time increase transparency and alignment across the company.

At Digitec Galaxus, each team has a meeting at the end of each quarter. In those meetings, the teams assess their performance during the last quarter, and create new goals for the next quarter. The teams in the entire company carry this out, said Sommerhalder:

There are teams that measure their goal achievement in a binary way, others in percentages. The teams decide if they want to pursue a goal not met in the next quarter, or if they want to create completely new goals.

All team goals, including those of the board of directors, are recorded in a confluence space where they can be accessed by everybody within the company. To get long-term alignment throughout the company, they also created team mission statements. The statements are supposed to give the teams a more long-term focus, as opposed to a focus for the quarter, and should not be changed too often.

As a prerequisite to introducing OKRs in their company, they had to establish a feedback culture first. “It was very important for us that everybody in the teams could speak freely and didn’t have to fear repercussions,” Sommerhalder said.

“With OKR we chose the right means to our ends,” said Sommerhalder. “They helped us a great deal in getting alignment, transparency and motivation throughout the teams.”

InfoQ spoke with Michael Sommerhalder, teamleader software engineering at Digitec Galaxus AG, after his talk at Agile Leadership Day 2019.

InfoQ: How do you do team feedback meetings?

Michael Sommerhalder: The whole team gathers in a meeting room for a meeting that takes roughly four hours for an eight-person team. They have to come prepared, which means they took their time to think about the other team members’ contributions the past quarter. We have a template consisting of four questions each team member has to answer for all other team members.

During this meeting, the team goes around in a circle and everybody answers the four questions for themselves first, going on to the next person afterwards, beginning with the team lead. The team leads are meant to set an example on how to make an honest self-assessment and accept feedback gracefully.

Each team member receives the feedback and might ask questions if they don’t understand the feedback. But no discussions or justifications are allowed at this time. And of course, the feedback has to be according to our feedback rules (I-messages, concrete examples, etc.). Each hour we take a break of about 10-15 minutes. Some teams reserve extra time for questions they would like to ask personally after the meeting.

The four questions are:

• Where did you make a special contribution in achieving goals?
• Where could you have shown more commitment?
• What special skills do you have?
• Where do you still have potential?

InfoQ: What have you done to establish a feedback culture?

Sommerhalder: First, let me say that we are still on our way to achieving a feedback culture in the whole company, as we are very diverse in our fields of activity and maturities of the teams.

As our engineering teams were already familiar with frequent feedback due to the Sprint Retrospectives, it was quite clear that we needed to do pilots of the new feedback process with some of them. But one of the drawbacks of the feedback was that they were usually very general; about the IDE, dependencies to other teams, etc. We had to get the teams to go deeper and give feedback on a more personal level.

Each team had their own way of (trying to) achieve this, but many used a slow introduction to personal feedback and began using every second Retrospective for personal feedback, e.g we had a template of questions and you had to choose two other team members to give feedback to (not the whole team in the beginning). This way, people slowly got used to giving and receiving personal feedback.

In the end, the teams were holding feedback meetings with everybody on the team one to three times a year. Furthermore, all team members have the opportunity to ask other employees about personal feedback using our 360° feedback tool. And finally, our quarterly meeting on how we reached the goals for the last quarter are also a tool for giving and receiving feedback.

There were also several other cultural aspects that were already in place when we introduced OKRs; the teams were already enjoying a certain degree of autonomy and did not have to wait for management’s decisions. So creating their own team goals seemed a logical next step. Information flow in our company was already transparent before the introduction; everything we do can be found in Jira or Confluence and everybody can see what other people are doing.

Nevertheless, I have to admit that teams working in more operational parts of our company might not have been used to the level of transparency OKR required, and needed more time to get acquainted with the increased transparency as well as giving and receiving feedback. Last but not least, there was already a spirit of experimenting in our company. We largely depend on ideas of how to advance in a very competitive market, and therefore we had tried out a lot of ideas already. All three cultural aspects were the foundations of our introduction to OKRs.

InfoQ: Where do OKRs meet your expectations? Where don’t they?

Sommerhalder: In terms of increasing transparency throughout the company, by having employees more committed to company goals and having better alignment between teams, our expectations were certainly met. A three-month horizon is much easier to handle for teams than setting goals for a whole year.

Furthermore, we observed that setting goals on departments that are driven by operational activities can be quite tricky, and setting goals “the wrong way” can lead to frustration. The aforementioned “wrong way” is also a risk we observed with department leaders who use OKR as “just another tool” to set the goals the way they would like. It’s a fine line between giving the teams complete autonomy and nudging them in the direction of company goals while setting their own.

InfoQ: What have you learned on this journey of OKRs and team spirit?

Sommerhalder: We realized that we are still on our journey to being fully OKR-driven, as there are departments still missing their own goal as a kind of “glue” between the company’s goals and the respective team goals. Letting the teams set their own goals in contrast to “just getting the ones from a hierarchy level above” greatly improved the team’s perception of being autonomous, and thus increased the amount of ideas coming from the teams. This, ultimately, leads to more innovation in the whole company.