From Progress to Product – a presentation by David Hussman

This is a summary of the presentation “From Progress to Product” that David Hussman gave at the ACE Conference in Krakow april 2016.

“Just because it’s done, doesn’t mean it’s right.”

Product Discovery session at DevJam, together with their customers they ask the following questions:
WHY:
– Frame – why are you doing this, what does success look like 3-6 months from now
WHO:
– Simple personas – to talk about who the product is for
WHAT:
– Trying to make interesting product guesses – this could be putting things in a backlog, but putting things in a backlog does not need to mean you are making interesting choices
– Stories, arranged from left to right in a design interaction way, and top to bottom in some kind of decomposition (story mapping)

Development:
– A product developer at DevJam first and foremost care about the product, second they care about maybe their skill. It’s like a guitarist in a band, unless you are a solo player you are part of something bigger than yourself and people come to see the band and not the guitarist.
– We are measuring the impact we are having, and not the progress we are making. Without progress you will have no impact, but if you think progress equals impact you are fooling yourself.

Sketching is a great way to break the chasm between development and discovery.

See also David Hussmans upcoming book “Products over process”.

1900 – Projects – Certainty – We just have to get it done, and then we will be successfull. Parameters: Time, Scope and Budget, and that’s what projects and project managers we’re revarded on (even if what was delivered was a piece of junk)
2000 – Process – Less certain
2010 – Product – Uncertain. Parameters THING, TEAM and TECH.

Context and continuum: (Where does your product sit?)
Two sides: (Not Should we use Scrum or Kanban)
* Uncertainty, things are unknown, dynamic, learn and experiment
* Certainty, things are known, static, construct and build

Product and team models:
– One product, one team
– One product, many teams
– Many products, many teams

Riffed of the Agile manifesto
– Measuring impact over Counting Story Points (Context and impact, who are we doing what for)
– Validated Learning over Getting Things Done (On the kanban board the column to the right is not “done” but “validated”.)
– Learning over Commitments
– “Too Big” over “How Big?”

One product, many teams
Scaling product development:
– more product learning, not more process
– don’t conflate scaling and spreading and don’t accidently increase process
One product, many team mappings
– Two axes: 1) Product, Market, Uncertainty 2) Structure (process, architecture…)

More riffs from the Agile manifesto
– Product Developers over Software Engineers
– Story maps over Epic Stories
– User Experiences over Single stories
– Customer journeys over Iteration Buckets
– Product Learning over Technical Constraints (you intentionally take on technical debt, not accidently. You can’t strive for zero technical debt)
– Learning faster over Getting More Done
– Discovery (KPIs) over Delivery (Pts)

Focusing on delivering stories instead of a user journey is like getting a list of groceries at the end of a sprint instead of a small meal.

How do we blend discovery and delivery? What can we learn outside of production?

Most of the time when we are talking about agile stuff we are talking about a delivery cycle. A better name for grooming is discovery. We as a team can choose before we start a sprint if we should focus more on delivery (getting more things built) or on discovery, trying to figure out what to build. As a developer, how well can you absorb customer empathy? How well can you tell stories? How brave are you to talk about things that aren’t programming?

Cross team validation tools, what can we learn outside the code?
Mixpanel is a web based tool that helps measure how users use your product
What do they need to learn in production? How wrong were they (product arrogance).

See also the story map tool CardBoardIt developed by DevJam

How doing the little things well makes the big things possible


This is a summary of the presentation “How doing the little things well makes the big things possible” that Jeff Patton gave at YOW! Nights, Agile Sydney in august 2016. This is a link to the slides of this presentation that was given at another time but I guess most of the slides are intact.

The presentation covers 9 simple things that make hard things easier.

1 – Show me what you’re thinking
– when we externalize our thinking with words and pictures, we detect differencies
shared understanding and alignment are the objectives of collaborative work
– shared documents are not shared understanding
– good documents should work like a vacation photo, looking at them makes you remember details about the discussions
– agile user stories have a simple lifecycle (3C’s, coined by Ron Jeffries, Card, Conversation, Confirmation)
– It doesn’t really matter what you put on the card, it’s the conversations that are important
– if you replace conversations with documents, you’re stopped using stories
– many organizations put the information from conversations into JIRA and then send it to developers who tries to understand what to build by reading. It’s no wonder that the software doesn’t match the expectations
– effective story conversations build shared understanding
– the best documents use words and pictures to help recall our conversations, the don’t replace conversations
– the next time you have a conversation at work, move it to the whiteboard or grab a stack of sticky notes

2 – Flare
– Flare is about getting everyone involved contributing with ideas and together consider everones ideas. It’s not about having one persons idea win, but about as a group collaborate to get new insights.
Stanford’s Design Thinking Process (Emphatize, Define, Ideate, Prototype, Test) talks about flare in the ideate and prototype phases. See Stanford’s Virtual Crash Course in Design Thinking for more information on the Design Thinking Process.
01-stanford-design-thinking-process
– GameStorming is also about flare in the exploring phase when you try to get everyone to collaborate.

– A Design studio is one approach to get the whole team ideate. The way it works is that the group agrees on the problem they are trying to solve. Then people go off and spend some time independently sketching on ideas. The next step is for everyone (not just UX or UI designers, but everyone!) to meet and share their results and the group tries to find the best ideas (not the best sketches). See the Google Venture video where Jake Knapp talks about their design studio approach. Jake has also written the book Sprint that goes into the design studio approach in more depth.

For more info about design studio see Jeff Patton’s Design Studio Recipe and his Design Studio Quick reference.
– deliberately widen your field of choices before making a decision. When arguing, stop, take a few minutes to sketch your ideas and then make time to hear each others ideas.
– the best idea isn’t mine or yours but it’s a little bit of everbodys ideas

3 – Shut up
– stop talking and let the model do the talk
Tom Wujec noticed that talking doesn’t help in collaboration, see his TED Talk “How to make a toast”.
– talk less: reorganize simple models to help describe your ideas without all the discussion. Replace brainstorming out loud with silent brainstorming.

4 – Focus
– set goals, then use pace-keeping signals to stay focused on them. Jeff showed an example of how they used coffee muggs with messages written on them (“Sold”, “Too much detail” etc.) that were used to keep the discussions in a work meeting focused.
– save document creation and maintenance for later
– focus on specific outcomes. Keep checking in on those outcomes and “time out” when the team drifts

5 – Time box
– Use the Pomodoro technique to keep pace
– Time-box small and large activities. At the end of a time-box, stop, reflect and ask if you can satisfice (is it good enough for now)

6 – Un-invite someone
– The ideal decision making group is dinner-conversation sized (2-4, maybe 5 people)
– Use different strategies for different sized groups
– 2-4 people, set goals, time-box and keep pace
– 5-11 people, add a facilitator and structure the workshop
– A dozen or more: break into small groups, then integrate results
– Crowds don’t collaborate. To make decisions fast, keep groups dinner-conversation sized

7 – Get out more
– Go where people work and let them teach you how and why they do things
– Having one person with your team is not a substitute for going out to the users, meeting users builds empathy
– Don’t wait for permission to go see the users
– Notice the difference that make a difference (some stories might not be needed when you actually see and understand how people work)
– The best solutions come from passionate, motivated people. Empathy is the most powerful and positive motivator

8 – Act
– Tom Chi from Google X talks about rapid prototyping Google glass at TedX and in this presentation he says “Thinking is overrated. Doing is the best kind of thinking” or as Jeff titles it: Stop debating and act.
– JFDI (Just *** Do It)

9 – Take 5
– If you’re doing it right, this stuff is really exhausting. Get out, get coffee, close your eyes, and take 10 deep breaths

It’s doing the simple things well that makes the tough stuff possible

Letting go of Agile: Where agile thinking steers us wrong

This post is a summary of the talk “Letting go of Agile: Where agile thinking steers us wrong” that Jeff Patton gave at Agile Tour Vienna in 2015. Presentations and slides from the conference can be found at the Agile Tour 2015 github. The pictures in this post are screen shots of the presentation and they are all drawings made by Jeff Patton.

1 – Software development is about changing the world1-change-the-world-outcome
Software development is about changing the world to the better for our stakeholders (users, customers, their business etc.), it’s about solving real problems that people have. Great software enables people to accomplish things in a better way than before, or things that wasn’t even possible without the software. When creating new software it’s essential to understand the problems that our stakeholders have. The best way to get a real understanding of peoples problems is to take the time to sit together with them in their own working environment to understand what makes people sad, upset or angry. From this we come up with ideas (new products, features or enhancements) that could solve these problems. Whether the software we build is successfull or not depends on if we have solved the problems our users have, or as Jeff says “What ever people were doing before that sucked, they can do it differently now”. This is what we call outcome, and this is measured in how people change their behavior.2-change-the-world-business-impact
The effect of the product in the business is called impact and is measured in e.g. ROI (Return Of Investment) or change of market share.

Working software is NOT the primary measure of progress for your users, your customers or your business, the primary measure of progress should be outcome and business impact, and Agile is not enough to achieve outcome for users and impact on business.

2 – Outcome and impact is measured AFTER the software is delivered
The annoying thing about outcome is that it happens after the software is released, it can’t be measured in a sprint or in a sprint review. It might even take a long time after the software is released as described by the Pirate metrics AARRR by Dave McClure. AARRR stands for Acquisition, Activation, Retention, Revenue and Referral3-mcclure-aarrr

3 – Core product team
To understand the needs of the different stakeholders of a product and to be able to come up with great ideas you need to have more than just a product owner (product manager) that is responsible for this work. Marty Cagan suggests that you have a team of people with the roles product manager, UX and lead engineer and he calls this the core product team.
6-marty-cagan
The product manager is responsible for making sure the product is valuable, the UX person makes sure the product is usable and the lead engineer makes sure that the product is built in a feasible way. Atlassian calles this team “The triad” and Spotify sometime referers to this team as the “The trio”. This team is together responsible for the outcome and impact of the product and the team does this by orchestrating collaboration amongst the different stakeholders.

4 – Traditional agile development takes too long time to evaluate an idea
Nordstrom is an example of a company that used to do traditional agile development and it looked something like the following picture:
8-nordstrom-traditional-agile
The process for Nordstrom was to first create a business case with an estimate of cost and potential income for a product to get an ROI estimate. The next step (if the ROI was positive) was to initiate a “sprint zero” in order to create a backlog and update the estimates. After that the product was developed in a series of sprints until released.

The problem with the above process is that it takes quite long to evaluate a product idea. Concidering that our ideas are correct approximately 20-30% and we are wrong about 60-70% of the time it’s very wasteful to go through this whole process in order to evaluate a product idea. The process is really a “Paid to build” cycle and it should not be used before you know that the product idea is worth building.

5 – Discovery or “Pay to Learn”
What Nordstrom started doing to ensure they were only building the “right” products was to create a “Pay to learn” cycle as illustrated below:
9-nordstrom-payed-to-learn-cycle
This process starts with a hypothesis (a guess) that need to be evaluated in order to know if it works. The process follows the Lean Startup Build – Measure – Learn steps. This is Discovery work and the focus is to learn fast. This youtube video from Nordstrom Innovation Lab shows how their discovery process works.

10-discovery-work
In discovery the delivery is in form of protoypes and not in the form of potentially shipable software. The goal with discovert is to learn fast wether an idea is good or bad.

6 – Continuous discovery and delivery
Discovery and delivery are two types of thinking that complement each other. In Agile the discovery part is invisible, and making that kind of work “slows down” the delivery velocity. Allthough these are two separate tracks we want the same team to work on them. As a developer, getting involved in the discovery work is about getting interested in what is the right thing to build and not just passively accepting stories in a backlog.
xx-discovery-and-delivery
If the whole team is involved in both discovery and delivery work the team will get an “ebb and flow” rhythm where the focus changes between the two. When focus is more on discovery the delivery velocity goes down and vice versa. If you don’t look at the whole picture (both Discovery and delivery) the team will look unpredictable since the delivery velocity will vary a lot depending on where the focus of the team is.xx-discovery-and-delivery-one-team-ebb-and-lfow

jeff-patton-ebb-and-flow

7 – Summarizing points
– Organize teams around product vision
– Build customer empathy and understanding
– Test before you invest
– Balance continuous discovery and delivery
– Stop celebrating delivery and start celebrating learning and genuine product outcomes (these are true measurements of progress)

 

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.