Great engineering, failed product – a presentation by Marty Cagan

Marty Cagan gave this very inspiring talk called Great Engineering, Failed Product at the Craft 2015 conference. The talk is about the huge difference there is in how the best companies produces products compared to how most companies produces products.

The root causes of failure (the process used in most companies):
1. Ideas: comes from two sources: Customers or sales
2. “Biz Case”: informal or formal
– how much money are you gonna make
– how much money is it gonna cost
3. Roadmap: comes from focus on higher value and desire for predictability
4. Requirements: – someone is responsible for gather requirements and document them for engineering
5. Design: user experience design
6. Build: enter engineers, this often the very first appearance of the agile implementation
7. Test: some companies even use “hardening” phases where all bugs are fixed. Having testing sprints being different than development sprints is madness.
8. Deploy: the final step
The above is anything of agile, this is basic waterfall!

What’s wrong with this process?
1. The source of ideas – the best source of idea is not included in the process. The customer and the executives of the company don’t have the knowledge of what’s possible with the technology. Also none of us knows what we really want with a technology product before we have had a chance to play with it. Consistently the best source of new ideas are the developers! The reason for that is that the developers work with technology every single day and know exactly what is now possible to build. The chrime in most companies way of working is that the developers aren’t even invited to the party where they need to be. Another great source for ideas are collected data. Platforms enables our customers to use our products in ways we didn’t imagine, and this is one the best selling points for public APIs. (For more see the article The Power of Customer Misbehavior or the book with the same name). At eBay the best innovation came from creating an environment where the customers could use eBay in ways no one had anticipated and then observing the customers being creative.

If you’re only using your developers to code, you are only getting half the value.

2. Business Case Fallacy
Business cases if you them right are actually useful. Unfortunately most companies to them to create roadmaps. They are supposed to answer the two questions how much money will we make and how much money will it cost. The problem is that you have no clue at this stage in the process since we just have ideas and they could be good, but probably not. It’s also at this stage when a product or project manager comes to the developers and says we are concidering doing this feature, how long would that take you. The smart answer here is: GO AWAY! This is where story points or t-shirt sizes came from, which in this case is a stupid compromise  since we really don’t have enough information to estimate either cost or revenue.

3. The Roadmap
This is the biggest difference between the best companies and the others. Most companies thinks their job is to follow the roadmap and do the things in order of the roadmap. The best companies knows that it’s not. The problem with a roadmap are the two inconvenient trueth with a product: 1) at least half of the ideas that we build and deploy to our customers are not giving our customers any business value or the product is not usable, 2) the ideas that actually are good might take a long time to get to work inte product, might take several iterations to get the details right. Time to market is meaningless, time to deliver real value is really what we are after. A roadmap only helps us with time to market. Companies using roadmaps sees them as commitments and does not know how to handle the actual case of ideas beeing bad and not working or good ideas taking longer than expected to deliver value. A roadmap is actually dooming your team to get items out in your product that most of them don’t work or need more attention to get to work.

4. The Role of Product owner
Good product owner or product manager should have very deep knowledge of your customers and their users, they also have to have a good understanding of the data of your product, they need to understand your business, they need to understand the constraints of your product. In a modern team a product owner or manager is not the one who goes and writes requirements. User stories really aren’t very meaningful.

5. The Role of User Experience Design
Most organizations don’t staff the user experience design they need to. Most companies use some external agencies that give you mockups and wireframes. Companies like Amazon, Netflix and Google hires user experience design as fast as possible.

We need a team of missionaries and not a team of mercenaries. In the process described above, no one in the process get’s to add any ideas to the product development. Definition of insanity is doing the same thing over and over again and expecting different result, and the above process is insanity!

When Agile started to take form in early 2000 there seemed to be hope that developers demanded the insanity to stop and for them to get more involved in the process. But now it seems like the business people has outsmarted most of the developers by allowing them to have their standups etc. as long as you follow the roadmap🙂

The most important thing to change is to invite the developers to the ideation phase, not once every quarter, but every day! In good organizations, product owners, user experience people and engineers sit side by side and solves problems. That is what being Agile really means.

8. Deploy
The problem is that most organizations talk about projects and not products. They optimze for a process leading to a final deployment with a party. You don’t wanna think in terms of projects with issues that should be resolved. You wanna think in terms of results. Outcome and not output. An outcome would example be: decrease the time it takes for a new customer to actually go live from 10 days to 10 minutes. A good team is given objectives like that and are expected to figure out how to solve it.

The process above is the slowest most expensive way of validating an idea as opposed to Lean startup that is the fastest cheapest way to validate an idea. Two most is not fast evaluate a Minimum Viable Product (MVP).

Continuous Discovery and Delivery
Lean startup is about separating the good ideas from the bad, but not in months but hours or days. This is what Product Discovery is all about and the output is validated ideas. The four questions we want answered during product discovery are: 1) will the customer actually buy this (or will they choose to use it), 2) can they figure out how to use it, 3) can we actually build it with the time and skillset that we have and 4) can our stakeholders support it (does it work in the market with regards to law etc.).

Instead of roadmaps use product visions that states where you intend to take the product in the next 2-3 years. From the vision use objectives (OKR – Objectives Key Result) and the whole idea is to drive the team from results. Visions applies to the whole company and objectives to a specific team. The purpose of discovery is to run a number of rapid MVP tests. An MVP is a missunderstood concept but the real meaning is an experiment that gives you insights on your ideas, it is not a product. If you treat your MVP as a product you are wasting valuable time to get your ideas validated quickly. Use the terms MVP test or MVP experiment to underline that it is not a product that you are developing. A good time will do 10-20 MVP experiments each week. The ideas that are good, those are the ones that actually makes it to the product backlog. It’s from the product backlog that the real software is delivered from with all the engineering aspects needed for a product. The purpose with the MVP experiments is to get a Produc/Market Fit.

Why Documents Fail – a presentation by Jeff Patton

Jeff Patton gave the presentation Why Documents Fail And What You Can Do About It at the FlowCon 2014 conference. The slides for the presentation is available as a pdf here.

1. Shared documents aren’t shared understanding
2. It takes more than words to tell a story
3. Stories are about more than what to build
4. The whole story is bigger than a developer can build in a couple of days

Shared documents aren’t shared understanding
Specifying in writing doesn’t work well. When we share and sign off a document we might believe we understand allthough we have different interpretations. Kent Becks insight on the subject was that we should stop exchanging documents and start telling stories so we can figure out a solution together.
The original idea of a story was simple: use it to fascilitate a conversation.
Stories have a simple lifecycle: card -> conversation -> confirmation (Ron Jeffries coined the 3 C’s in Extreme Programming Installed).

It takes more than words to tell a story
Stories get their name from how we use them, not how we write them

With a shallow discussion we might all take away something different.
When we externalize our thinking with words and pictures, we detect differences.
When we combine and refine, we at something better.
Afterward, when we say the same thing, we actually mean it.

Jeff Patton and Luke Barrett’s cartoon on shared understanding

What you record during conversations works like a vacation photo, it helps you and others remeber the conversation. Documents should work like vacation photos, i.e. they should help you remember your discussions.

Effective story conversations are about building shared understanding. The best documents use words and pictures to help us recall our conversations, they don’t replace them.

Stories are about more than what to build
Talk about who does what, and why. Talk about the outcome, not just the output.
Focus discussion and collaboration around who will use and benefit, and how they will “later” after delivery.

The whole story is bigger than a developer can build in a couple of days
A Story Map helps organize discussion about user’s experience with our product. Build story maps in small collaborative groups.

Use story maps to understand your product or feature’s experience. Use mapping to break down big stories and to help find small viable solutions.1.

1. Tell stories, don’t just write hem.
2. Use simple visualizations to anchor the stories you tell.
3. Tell the whole story

Effective stories connect everyone to the purpose of your product.

For even more information on this subject read the book User Story Mapping: Discover The Whole Story, Build The Right Product by Jeff Patton

Implementing MicroService Architectures – a presentation by Fred George

Fred George gave this presentation called Implementing MicroService Architectures at ÖreDev 2013.

Summary Principles of MicroServices

  • Very, very small
  • Loosely coupled (including flow)
  • Multiple versions accetable (encouraged?)
  • Self-execution monitoring of each service – each service need to protest loudly of something goes wrong in their execution
  • Publish interesting “stuff” (without requirement), if something interesting is going on/happened in the service make sure to publish this so other services can act on this
  • “Application” seems to be poor conceptualization

Rapids, Rivers and Ponds.

  • Rapids – Every event
  • Rivers – Themed events
  • Ponds – Events or entities (State/History e.g. data warehouses)

High-Performance Bus

  • Kafka (LinkedIn) for Rapids (all events)
  • 0MQ for Rivers

Services have own persistence store!

Design Events, not Entities. Inspired by the book In The Plex by Steven Levy

Design History, not Current. Inspired by Clojure.

“Living Software” System

  • Long-lived system; short-lived services (human body)
  • Extremly dynamic with continuous deployments
    • 5-10 minutes between deployments typical
  • Accept it is complex (especially for testing)
    • Acceptance test on business outcomes instead
  • Radical impact to processes (anarchy)
  • There will be a learning curve for developers!

The principles of microservices – a presentation by Sam Newman

Sam Newman gave this presentation called The principles of microservices at NDC London 2014. Sam will also release his book Building Microservices in february 2015. For more info about Sam see his Lanyrd page where you can find the slides for this presentation as well.

Microservices are: Small Autonomous services that work together.

Sam mentions GILT, REA and Netflix as examples of companies that has adopted microservice to achieve scalable applications and fast development, and they all share their experiences on the respective tech blogs.

Sam mentions that there is a major difference in working with microservices compared to a monolithic system when it comes to architectural decisions that need to be made. In an monolothic system these decisions are often done in the beginning of the development of the system, while with microservices these decisions are done all the time new services are developed. This leads to the need for some principles to follow when creating these microservices. Sam refers to the Twelve-Factor App as a source that describes factors that should be considered when building scalable services.

Based on the experience of Sam’s and others work with Microservices he has come up with the following principles to consider when building microservices:
– Model Around Business Domain
– Culture of Automation
– Hide implementation details (otherwise we will end up with coupling between services)
– Decentralise all the things (everything)
– Deploy independently (services should be able to be deployed independently of other services)
– Isolate Failure
– Highly Observable

Modeled around business domain
Services should be created to follow the domain in your organization. More about this and bounded contexts can be found in the book Implementing Domain-Driven Design by Vaugh Vernon

Culture of Automation
The whole idea of microservices is to have a fairly large amount of small services and to be able to manage changes to these you need to have automated processes. This means that you will wan’t to have:
– infrastructure automation (provisioning of host environments)
– automated testing
– continuous delivery (for more info see the book Continuous Delivery by Jez Humble)

Hide implementation details
This means for starters that you need to hide your database. Bounded contexts (see Martin Fowlers blogpost for a good example) will give you a good understanding of the information that services share and what information that should be internal to a service.

Decentralize all the things
– Autonomy is about giving people as much freedom as possible to do the job at hand. Decentralization is all about freedom. Organizations that has embraced microservices have had their operations department to shift from “we are the ones who do stuff” to “we will provide you with tools to do it yourself” (see DevOps for more info). See also the GILT tech blog post Making Architecture Work in Microservice Organizations and how they handle architectural governance and autonomy in their service teams.
– Sam also mentions that with autonomy comes also responsibility which means that teams will be held accountable for their releases. This is the same responsibility that the operations department had before.
– Dumb-pipes and smart end-points, don’t move the business logic into a central service bus! Use your service bus as transportation pipes only.

Deploy independently
One service should be possible to deploy without taking any consideration to other services. If you need to co-ordinate release of one service with other services you need to get that resolved before introducing new services. Also Sam strongly recommends to have one service per host in order to not introduce more complexity to your architecture.
Consumer Driven Contracts is also a way to manage decoupling of services, for more information see Martin Fowlers article called Consumer-Driven Contracts: A Service Evolution Pattern. For an example implementation of consumer-driven contracts, have a look at Pact.

Isolate failure
Each service that consumes other services must have a strategy for handling scenarios when the other services are unresponsive, becomes very slow etc. Make sure to implement timeouts, circuit breakers and Bulkhead into your service application. See the book Release It!: Design and Deploy Production-Ready Software for more information on these patterns.

Highly Observable
Our services must provide us with information so that we can see what is going on. The services should push information (log events) to us. Use tools like fluentd or logstash together with Kibana for managing your log events. You also need to get stats from your services with tools like New Relic. You will need correlation id:s to be able to understand the whole flow through a number of services.

Related to this presentation is the presentation Scaling Microservies at Gilt that Yoni Goldberg gave at the Atlassian SUMMIT 2014 and the article Microservices by James Lewis and Martin Fowler.

Software Development in the 21st century – a presentation by Martin Fowler

Martin Fowler gave a presentation called Software Development in the 21st century at Agile Australia 2014.

The presentation was divided into two parts 1) Refactoring and 2) How to take responsibility as a developer

Presentation 1 – Refactoring (See http://martinfowler.com/articles/workflowsOfRefactoring/)
– Refactoring is about changing how the code is organized without changing the observable behvarior of the system. This means that you will be thinking in a different mindset while refactoring compared to when you are adding new capabilities to your system by programming a new function.

Different times when you might use refactoring:

1) TDD: The process of TDD (Red, Green, Refactor) helps you separate your mindset so you can focus on one thing at the time. Refactoring should only be done on a green codebase so you know if you’re refactoring introduces a bug.
2) Litter-Pickup Refactoring: When you run into a codebase that is not very well written you should try to apply the boy-scout rule and leave the codebase a litter better than when you found it.
3) Comprehension refactoring: Closely related to Litter-Pickup is comprehension refactoring that means that when you run into some code that you don’t understand and you take the time to get an understanding of what it does you should use that understanding to refactor the code in such a way that the next person seeing the code doesn’t need to go through the same thinking process.
4) Preparatory refactoring: Refactoring that you do in order to make the change that you are about to do easier. So you take a look at the code to see if it is a good fit, if it’s not you refactor it before getting started with the new functionality. This kind of refactoring most often makes it quicker to implement the new functionality that it would have been if you hadn’t done the preparatory step.
5) Planned refactoring: This is when you have refactoring cards/stories on your planning board. This often a sign of a team that hasn’t done enough refactoring in earlier stages. A problem with having refactoring cards on the board together with cards for new functionality is that the refactoring is prioritized against new functionality and in this discussion you will have you’re customer and product owner who really aren’t qualified to decide wether refactoring is needed or not.
6) Long term refactoring: When you have a larger mess in your system that need to be cleaned up but the work will take weeks, months or more. The strategi with long term refactoring is to take a lot of small steps torward a targeted solution instead of one big jump.

Is refactoring wasteful? See the article Design Stamina Hypothesis that is related to this subject. Refactoring is crucial to have a code base that can respond fast to change, and that is what agile is all about. Refactoring is not about professionalism, clean code or the “right thing” but it’s about economics, i.e. beeing able to deliver value quickly and continuously.

Presentation 2 – Frustrations about Agile (We should not be passive recipients of people telling us what to program, we ought to be taking a more proactive role in the world around us)

A lot of frustration today in the Agile world
– “Everyone” wan’t to be Agile but aren’t willing to do the work.
– Agile certifications and frameworks e.g. SAFe – Scaled Agile Framework (or as Martin called it Shitty Agile For Enterprises)

Martin frustration today regarding agile:
User – has needs (will tell you what the wan’t, but you should build what they need!)
Analyst – tries to figure out what the user needs which results in the intent of the software
Programmer – builds the features from the stories that the analyst has written

Martin’s frustration about this model is about the flow of information and that it’s seen as the analysts provides information about what to build to the developers. The intent with agile was to have conversational stories (place holders for discussions) that should be used for developers, analysts and users to have discussions about what to be built. If developers are not involved in understanding the users needs you will loose one important sourcce of ideas. Also you introduce a high risk of ending up with developers that don’t understand the users needs. Developers should not passively receive input from product owners/business analyst, they should participate in the discussions around the user needs!
In order to do this the developers need to have knowledge about the domain. The boundary between business and technology is where the real good ideas come from. Article Observed Requirement.
As a developer you also have responsibility, since you are creating software that affect how users do their work. (See also Jeff Pattons presentation Using Design Thinking to Stop Building Worthless Software) For examples on how to missuse this responsibility see dark patterns. As a developer you should ask yourself what kind of software you are willling to produce, and take responsibility for your decisions.

Business Modeling Canvas – a presentation by Peter Cohen

Peter Cohen gave a presentation about Business Modeling Canvas at Agile Australia 2014.

Book about Business Modeling Canvas: Business Modeling Generation or on Amazon.

Business Modeling Canvas:
1) Customer Segments – Who are we creating value for?
2) Value Proposition – What value are we delivering? What problem are we solving?
3) Channels –  How do we reach our customers?
4) Customer Relationships – What kind of relationship does each of our customer segments expect? How costly are they?
5) Revenue streams  – What do customers pay for? How do they pay?
6) Key resources – What key resources do we require to deliver value?
7) Key activities – What key activities are done to deliver value?
8) Key partners – Who are our key partners?
9) Cost structure – What are our key costs?

The right side of the canvas is more about the Market that you are in, and the left side is about the Product that you deliver.

In the Market side you should strive to Learn and Pivot, and in the Product side you should Optimise and Accelerate.

Other related canvases:
– Social Enterprise Canvas – based on Business Modeling Canvas but adds five more boxes: Enterprise structure, Key Resistences, Opportunity as Hypothesis, Intended Social Impact, Unintenden Consequences.
– The Experience Canvas by Atlassian that is based on user experience
– The Lean Canvas created by Ash Maurya

Links:
Business Model Generation (download A0 pdf of a empty Business Modeling Canvas)
Lean Stack

Back to the Future – a presentation by Emma Langman

Emma Langman gave the presentation Back to the Future: What Old Thinkers can teach us about making Innovation Succeed Today at QCon 2014.

Focus of the talk, 3 questions:
1. What are our 21st Century Problems?
2. What are the lessons from history?
3. How can we apply those ideas today?

Some systems thinking principles:
– Everything is connected to everything else
– When something happens, the impact of that event might pop up somewhere else in space or time
– We don’t nescesarily now the impact of what we do before we do it
-There is no such thing as a system, they don’t actually exists, and there are also infinite systems => the system is in the eye of the beholder. Any kind of system is actually part of a larger system. We are the ones who decide the boundary of the system. Many of the issues that we have (in life, at work, at home) is that we draw artificially small boundaries around our systems.

1. What are our 21st Centurt Problems?

– Precipitous: We try to find a solution quickly without really exploring the problem space
– Lack of divergent thinking: we stop asking why
– Ignorance of variation
– Denial of performance as a factor of more than one thing
– Insufficient analysis of the 5 why

2. What are the lessons from history?

3 thinkers:
1. W. Edwards Deming – System of Profound Knowledge
2. Russel Ackoff – Idealized Design
3. Dr. Kaoru Ishiwaka – The 7 Tools of quality

Deming: “94% of problems in business are systems driven and only 6% are people driven.”. Most of the performance of an individual has to do with the system that the are in.

Deming’s System of Profound Knowledge (SoPK):
Four concepts: Variation, Psychology, Learning (Theory of knowledge) and System.

Russel Ackoff Idealized design:
A way of thinking about change that is deceptively simple to state: In solving problems of virtually any kind, the way to get the best outcome is to imagine what the ideal solution would be and then work backward to where you are today.
This ensures that you do not erect imaginary obstacles before you even know what the ideal is.
See also the book called Idealized design and the paper A Brief Guid to Interactive Planning and Idealized Design.

Ishikawa’s seven tools quality (everyone should know these):
1. Pareto analysis: which are the 20% that cause the 80%
2. Cause and effect diagram (fishbone diagram): what are the root causes?
3. Stratification: how is the data aggregated?
4. Check sheets: how often does this happen?
5. Histograms: what do overall patterns look like?
6. Scatter charts: what are the potential relationships between factors?
7. Process control charts (capability charts): what is special, common – and what can we do about it?

Special variation and common variantion or (common cause and special cause).

How can we apply those ideas today?

– Process improvement
– End-to-end change across a system
– Involving teams and different departments
– Focus on the whole – not the parts
– Less fear and blame
– Daring to dream – Idealized Design

3 suggestions:
Expand the boundaries of our thinking/behaving about our ‘team’ and role
– Understand variation and use the quality tools where appropriate
– Dare to dream  and use idealized design and divergent thinking