More and more organizations and teams are adopting Agile, however most stay focused on just the development part. They maintain a Big Upfront Requirements/Design (BRUF) phase and still have a long test and deployment phase. This approach results in more of a mini-waterfall approach rather than an Agile approach where we actually place valuable products in our customers’ hands. The old risks and pain points are still there: are we building the right thing? Is it valuable and usable? Does it work? So the true benefits of an Agile approach in terms of quality valuable products and higher ROI is never achieved due to our long cycles and slow feedback loops. Come to this session to see how Lean Discovery and Agile Delivery combined with a DevOps mindset, can make actual delivery of customer value sustainable. We will look at how Lean Discovery replaces BRUF and ensures the team is constantly building the right thing. We will also see how applying Agile Engineering practices ensure that the team is building the thing right and how a DevOps mindset ensures that the product the team builds actually gets delivered to the customer early and often.
2. @FadiStephan | Kaizenko.comLean Discovery, Agile Delivery, and the DevOps Mindset
• 20+ years of experience in software development
• Technology Consultant, Agile Coach and Trainer
with Kaizenko
• Co-Organizer of the DC Scrum User Group
www.Kaizenko.com @KaizenkoLLC
@FadiStephan
Fadi Stephan
3. Releases that
are infrequent
Long and
painful
testing cycles
The quality of
your products is
poor
Solutions that
don’t satisfy
our customers
@FadiStephan | Kaizenko.com
Pain Points
Lean Discovery, Agile Delivery, and the DevOps Mindset
9. @FadiStephan | Kaizenko.com
Not Just About Development
Ops
Reqs
Design
Dev
QA
Release
Analyst and Customer
Architect
Developer
Tester
Years!
Waterfall
Lean Discovery, Agile Delivery, and the DevOps Mindset
14. @FadiStephan | Kaizenko.com
Agile Value Proposition
Lean Discovery, Agile Delivery, and the DevOps Mindset
Risk
Visibility Adaptability
Business Value
Agile Development Traditional Development
15. “Our highest priority is to satisfy the
customer through early and continuous
delivery of valuable software.”
“Deliver working software
frequently, from a couple of weeks to
a couple of months, with a preference
to the shorter timescale.”
- First and third of the Twelve Principles behind the Agile Manifesto
@FadiStephan | Kaizenko.comLean Discovery, Agile Delivery, and the DevOps Mindset
16. Build a
QUALITY
SOLUTION
ENGAGE end
users EARLY
AND OFTEN
DELIVER it
FREQUENTLY
and VALIDATE
@FadiStephan | Kaizenko.comLean Discovery, Agile Delivery, and the DevOps Mindset
24. “The big question of our time is not can it
be built, but should it be built?”
– Eric Ries
Lean Startup
@FadiStephan | Kaizenko.comLean Discovery, Agile Delivery, and the DevOps Mindset
26. BUILD
LEARN MEASURE
Days
Not
Months or years
REQUIREMENTS
DESIGN
DEVELOPMENTTEST
DEPLOY
@FadiStephan | Kaizenko.com
HYPOTHESIS
Lean Discovery, Agile Delivery, and the DevOps Mindset
27. @FadiStephan | Kaizenko.com
MMF & MVP
The Minimum Viable Product is
that version of a new product
which allows a team to collect the
maximum amount of validated
learning about customers with
the least effort.
Minimum Viable Product (MVP)
The smallest unit of functionality
with "intrinsic marketable value.”
Minimum Marketable Feature (MMF)
Lean Discovery, Agile Delivery, and the DevOps Mindset
Software by Numbers by Mark Denne Lean Startup by Eric Reis
40. @FadiStephan | Kaizenko.com
Viable Feasible
PAINFUL
SOLUTION
Usability
DESIRED
SOLUTION
Lean Discovery, Agile Delivery, and the DevOps Mindset
From Jeff Patton
41. LEAN UX
@FadiStephan | Kaizenko.com
Concept Validate
internally
prototype Test
externally
Learn from
user behavior
Days Not Months
Lean Discovery, Agile Delivery, and the DevOps Mindset
42. @FadiStephan | Kaizenko.com
Value Proposition Canvas
Lean Discovery, Agile Delivery, and the DevOps Mindset
http://www.businessmodelgeneration.com/
48. @FadiStephan | Kaizenko.com
Product Backlog
Lean Discovery, Agile Delivery, and the DevOps Mindset
https://www.flickr.com/photos/49942291@N06/6271934371/in/photostream/
49. LEAN DISCOVERY BUILDING BLOCKS
@FadiStephan | Kaizenko.com
VALUE PROPOSITION CANVAS
TEST CARD
PROBLEM/SOLUTION INTERVIEW
PERSONAS
SKETCHING / PAPER PROTOTYPES
MVP/MMF
USABILITY TESTS
JOURNEY MAPS
Lean Discovery, Agile Delivery, and the DevOps Mindset
50. @FadiStephan | Kaizenko.comACCELERATED AGILITY @FadiStephan | Kaizenko.com
Not a Phase
Hypothesis Driven Development
HDD
Lean Discovery, Agile Delivery, and the DevOps Mindset
53. “How long would it take your organization to
deploy a change that involves just one
single line of code? Do you do this on a
repeatable, reliable basis?”
– Mary and Tom Poppendieck,
Implementing Lean Software Development
@FadiStephan | Kaizenko.comLean Discovery, Agile Delivery, and the DevOps Mindset
56. Test Driven Development
@FadiStephan | Kaizenko.com
PASS
REFACTOR CODE
FAIL
FAIL
PASS
Automated Acceptance Test Automated Unit Test
User StoryAcceptance Criteria
Back
Lean Discovery, Agile Delivery, and the DevOps Mindset
58. @FadiStephan | Kaizenko.com
Automation - Continuous Integration
Build #1
compile
unit test
integration test
package
deploy/run
acceptance test
analyze code
Build
Report
Version
Control
change
#1
change
#2
Build
Server
Email
Failed Build
Build #2
compile
unit test
integration test
package
deploy/run
acceptance test
Build
Report
analyze code
Lean Discovery, Agile Delivery, and the DevOps Mindset
59. @FadiStephan | Kaizenko.com
Automation – Deployment Pipeline
Developer Tester
Product
Owner
Operations
Compile
Unit
Tests
Static
Code
Analysis
Integration
Test
Deploy Acceptance
Test
Release
Candidate
“Pull” Build
into Test
Approve “Pull” into
Production
Check-in
Trigger Archive
Automated Steps on Build Server
Deploy Manual
Test
Deploy
ApplicationApplicationApplication
Development Test Production
Version
Control
Binary
Repository
Database Database Database
Succeeding with Digital Service Delivery
61. @FadiStephan | Kaizenko.com
Automation – Deployment Pipeline
Developer Tester
Product
Owner
Operations
Compile
Unit
Tests
Static
Code
Analysis
Integration
Test
Deploy Acceptance
Test
Release
Candidate
“Pull” Build
into Test
Approve “Pull” into
Production
Check-in
Trigger Archive
Automated Steps on Build Server - Application
Deploy Manual
Test
Deploy
ApplicationApplicationApplication
Development Test Production
Version
Control
Binary
Repository
Database Database Database
OS
Security
Hardening
Common
Installs
Base
Image
Promote Application
Image
Automated Steps on Build Server - Infrastructure
Promote Promote
Succeeding with Digital Service Delivery
62. AGILE DELIVERY BUILDING BLOCKS
@FadiStephan | Kaizenko.com
SOLID CODING PRACTICES
AUTOMATED BUILDS
AUTOMATED CODE QUALITY CHECKS
AUTOMATED UNIT, INTEGRATION, ACCEPTANCE TESTS
CONTINUOUS INTEGRATION
AUTOMATED DATABASE MIGRATIONS
INFRASTRUCTURE AS CODE
CONTINUOUS DELIVERY
CONTINUOUS DEPLOYMENT
TEST DRIVEN DEVELOPMENT
Lean Discovery, Agile Delivery, and the DevOps Mindset
63. @FadiStephan | Kaizenko.comACCELERATED AGILITY @FadiStephan | Kaizenko.com
Not a Phase
HDD
ATDD
TDD
Lean Discovery, Agile Delivery, and the DevOps Mindset
65. GOAL
Continuously satisfy our customers by
delivering quality high value products in a
sustainable way.
@FadiStephan | Kaizenko.comLean Discovery, Agile Delivery, and the DevOps Mindset
67. @FadiStephan | Kaizenko.com
Team Structure
Business
Analysts
TestersDevelopers
UXers &
Designers
Ops
Lean Discovery, Agile Delivery, and the DevOps Mindset
68. @FadiStephan | Kaizenko.com
Team Structure
BA/QA
Dev
UX
Ops
GD
SM
Lean Discovery, Agile Delivery, and the DevOps Mindset
One Collaborative Team
With Shared Responsibility
73. LEAN DISCOVERY BUILDING BLOCKS
@FadiStephan | Kaizenko.com
LEAN CANVAS
VALUE PROPOSITION CANVAS
TEST CARD
PROBLEM/SOLUTION INTERVIEW
PERSONAS
SKETCHING / PAPER PROTOTYPES
MVP/MMF
USABILITY TESTS
JOURNEY MAPS
Lean Discovery, Agile Delivery, and the DevOps Mindset
74. AGILE DELIVERY BUILDING BLOCKS
@FadiStephan | Kaizenko.com
SOLID CODING PRACTICES (TDD)
AUTOMATED BUILDS
AUTOMATED CODE QUALITY CHECKS
AUTOMATED UNIT, INTEGRATION, ACCEPTANCE TESTS
CONTINUOUS INTEGRATION
AUTOMATED DATABASE MIGRATIONS
CONTINUOUS DEPLOYMENT
INFRASTRUCTURE AS CODE
CONTINUOUS DELIVERY
Lean Discovery, Agile Delivery, and the DevOps Mindset
Frustrated scared unhappy, settled with the way things are or we can only improve this much
So let’s talk about some of the common pain points that we were facing on our projects
Increasingly long testing cycles - we are almost done, and we put everything together and suddenly nothing works. We spend months doing integration testing, troubleshooting and debugging.
Going through painful production deployments - Once we are done with all that, we spend even more months prepping our production environment and trying to make what we just spent month on in our testing environment to get to work in our prod environment.
Solution that does not satisfy the client – and once it is finally in production, our customer/biz partner is unhappy with the final product as it does not quite meet their needs
Long concept to deployment cycles – and a combination of all of these pain points leads to long concept to deployment cycles, making our ability to respond to the market and the changing needs of our clients very very slow.
We are all familiar with the waterfall model (graphic).
***The direction this section takes should depend on what we are looking to sell. Probably need various options and pick-and-choose based on audience.***
***How do we tie this back to myUSCIS? Hypothesis - can we talk about the Find Your Doctor feature? Did we solve a real business problem?
OR
We have all these requirements, how did we get here? How did we get this Product Backlog? Talk about what IDEO did.***`
A lot of you have heard of Agile and iterative/incremental development as a way to address this problem. A lot of folks that decide to go that route focus only on the development part and end up with something like this (graphic).
We know that with this model we don’t get any value until the product is in production and that is usually measured in years (graphic).
More importantly, after the painful integration, test, deployment and quick hot fix cycles, when we finally get this out to production, we find out that the value delivered is something like this (graphic) because a lot of the features delivered are either not what the customer really wanted or they don’t need them anymore.
This might reduce some of the technical risk as we tackle development, integration and testing early on, but it does not address the end to end cycle and ensuring that what we are delivering is what the client actually wants and our value deliverable still looks like this because of the big upfront requirements phase and the big testing/deployment phase at the end (graphic)
More importantly, after the painful integration, test, deployment and quick hot fix cycles, when we finally get this out to production, we find out that the value delivered is something like this (graphic) because a lot of the features delivered are either not what the customer really wanted or they don’t need them anymore.
This might reduce some of the technical risk as we tackle development, integration and testing early on, but it does not address the end to end cycle and ensuring that what we are delivering is what the client actually wants and our value deliverable still looks like this because of the big upfront requirements phase and the big testing/deployment phase at the end (graphic)
Agile is about iterative and incremental delivery and not just development. Two principles from the manifesto state:
Principle 1: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Principle 3: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
***Need to change “build” in the last piece to something else***
We do that by building quality products, delivering them frequently to regularly validate our deliverables to ensure an outcome of a satisfied client.
We know that we’ve built the thing right – already in production, no website crashes, we’ve updated x number of times since we delivered it. But, how do we know we built the right thing?
***The direction this section takes should depend on what we are looking to sell. Probably need various options and pick-and-choose based on audience.***
***How do we tie this back to myUSCIS? Hypothesis - can we talk about the Find Your Doctor feature? Did we solve a real business problem?
OR
We have all these requirements, how did we get here? How did we get this Product Backlog? Talk about what IDEO did.***`
That is, we will use Lean Discovery to ensure we are building the right thing, and Agile Delivery to ensure we are building the thing right.
That is, we will use Lean Discovery to ensure we are building the right thing, and Agile Delivery to ensure we are building the thing right.
That is, we will use Lean Discovery to ensure we are building the right thing, and Agile Delivery to ensure we are building the thing right.
Agile Engineering and DevOps enables us to quickly go through our delivery cycle which in turn enables us to build something, measure it and learn from it.
So our original requirements are really hypothesis that we need to validate and build upon.
build the smallest thing possible to get value as soon as possible. This can be for release, discovery of what to build, or validation of the path you are taking
the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
he smallest unit of functionality with "intrinsic marketable value.
We have a target solution in mind, and through successive iterative deployments we reach a MVP.
We have a target solution in mind, and through successive iterative deployments we reach a MVP.
We have a target solution in mind, and through successive iterative deployments we reach a MVP.
We have a target solution in mind, and through successive iterative deployments we reach a MVP.
We got there by applying some qualitative analysis, but once we get our MVP we can now get real data and add some quantitate analysis which takes us to our next MVP and so forth until we reach our desired solution which will likely end up different from the original target solution based on our validated learning.
Using Lean Discovery and Agile Delivery we achieve validated learning that reduces our risk and ensures a high ROI.
Our goal is to build a solution that is technically feasible as well as be viable from a business perspective.
When these two intersect we come out with a working solution, however, it is a painful solution because we did not take the perspective of the user into account.
When these two intersect we come out with a working solution, however, it is a painful solution because we did not take the perspective of the user into account.
What we need to add is usability to ensure we are coming up with a desirable solution.
What we need to add is usability to ensure we are coming up with a desirable solution.
We then apply Lean UX practices to quickly go through :
Problem interviews, solution interviews, surveys, journey maps, sketches, paper prototypes, behavior tests, etc. to narrow our focus on an MVP.
Feature or business model
Zapos
Coin star
This will differ slightly based on the business that you are in, but each one of these is a hypothesis that needs validation. In our scenario, the most common one is deals with customers and value proposition so we can focus on the value proposition canvas.
Here we look into our product and features and consider our customers and end users to make sure we are building something the fits. We consider their pains points and delighters and make sure that the features we are building relieve these pain points and increase their product engagement.
Since this is a hypothesis, we create a test card so we can validate our assumptions
Step 1: Hypothesis: We believe that …,
Step 2: Test: To verify that, we will …,
Step 3: Metrics: And measure …,
Step 4: Criteria: We are right if…
Since this is a hypothesis, we create a test card so we can validate our assumptions
Step 1: Hypothesis: We believe that …,
Step 2: Test: To verify that, we will …,
Step 3: Metrics: And measure …,
Step 4: Criteria: We are right if…
Since this is a hypothesis, we create a test card so we can validate our assumptions
Step 1: Hypothesis: We believe that …,
Step 2: Test: To verify that, we will …,
Step 3: Metrics: And measure …,
Step 4: Criteria: We are right if…
Since this is a hypothesis, we create a test card so we can validate our assumptions
Step 1: Hypothesis: We believe that …,
Step 2: Test: To verify that, we will …,
Step 3: Metrics: And measure …,
Step 4: Criteria: We are right if…
Since this is a hypothesis, we create a test card so we can validate our assumptions
Step 1: Hypothesis: We believe that …,
Step 2: Test: To verify that, we will …,
Step 3: Metrics: And measure …,
Step 4: Criteria: We are right if…
Since this is a hypothesis, we create a test card so we can validate our assumptions
Step 1: Hypothesis: We believe that …,
Step 2: Test: To verify that, we will …,
Step 3: Metrics: And measure …,
Step 4: Criteria: We are right if…
Since this is a hypothesis, we create a test card so we can validate our assumptions
Step 1: Hypothesis: We believe that …,
Step 2: Test: To verify that, we will …,
Step 3: Metrics: And measure …,
Step 4: Criteria: We are right if…
Since this is a hypothesis, we create a test card so we can validate our assumptions
Step 1: Hypothesis: We believe that …,
Step 2: Test: To verify that, we will …,
Step 3: Metrics: And measure …,
Step 4: Criteria: We are right if…
Since this is a hypothesis, we create a test card so we can validate our assumptions
Step 1: Hypothesis: We believe that …,
Step 2: Test: To verify that, we will …,
Step 3: Metrics: And measure …,
Step 4: Criteria: We are right if…
Since this is a hypothesis, we create a test card so we can validate our assumptions
Step 1: Hypothesis: We believe that …,
Step 2: Test: To verify that, we will …,
Step 3: Metrics: And measure …,
Step 4: Criteria: We are right if…
We then apply Lean UX practices to quickly go through :
Problem interviews, solution interviews, surveys, journey maps, sketches, paper prototypes, behavior tests, etc. to narrow our focus on an MVP.
Since this is a hypothesis, we create a test card so we can validate our assumptions
Step 1: Hypothesis: We believe that …,
Step 2: Test: To verify that, we will …,
Step 3: Metrics: And measure …,
Step 4: Criteria: We are right if…
And the way we do that is by applying Lean Discovery and Agile Delivery.
That is, we will use Lean Discovery to ensure we are building the right thing, and Agile Delivery to ensure we are building the thing right.
We start by asking “How long would it take your organization to deploy a change that involves just one single line of code? Do you do this on a repeatable, reliable basis?”
To talk about this, we are going to look at a real-life example, myUSCIS.
Automation ensures the process is repeatable and reliable
That is, we will use Lean Discovery to ensure we are building the right thing, and Agile Delivery to ensure we are building the thing right.
So Agile Engineering and DevOps builds on these building blocks.
To get there we start by …
Applying SOLID coding practices and following TDD to build out clean loosely couple code, we automate our builds and run code quality checks with every build to maintain our clean code, we write tons of tests and these are tests written mostly by the developers and not a testing team that is using a very expensive testing tool. We continuously integrate our code, using only the main branch and checking in code multiple times per day and per hour. We automate our database scripts and constantly deploy the application onto our different environments up to test or stage and finally we automate our environments to reach a stage or continuous delivery.
These are all the technical components of Agile Engineering and DevOps that help us ensure that we are building the thing right by constantly delivery working software that is fully tested and production ready.
Since this is a hypothesis, we create a test card so we can validate our assumptions
Step 1: Hypothesis: We believe that …,
Step 2: Test: To verify that, we will …,
Step 3: Metrics: And measure …,
Step 4: Criteria: We are right if…
***The direction this section takes should depend on what we are looking to sell. Probably need various options and pick-and-choose based on audience.***
***How do we tie this back to myUSCIS? Hypothesis - can we talk about the Find Your Doctor feature? Did we solve a real business problem?
OR
We have all these requirements, how did we get here? How did we get this Product Backlog? Talk about what IDEO did.***`
So we want to move from this state and get to a place where we can continuously deliver customer value in a sustainable way with improved lead time, resilience and quality.
We started out with an experienced team that included members from USDS team, 18F, Excella and Stelligent.
That is, we will use Lean Discovery to ensure we are building the right thing, and Agile Delivery to ensure we are building the thing right.
That is, we will use Lean Discovery to ensure we are building the right thing, and Agile Delivery to ensure we are building the thing right.
We then apply Lean UX practices to quickly go through :
Problem interviews, solution interviews, surveys, journey maps, sketches, paper prototypes, behavior tests, etc. to narrow our focus on an MVP.
So Agile Engineering and DevOps builds on these building blocks.
To get there we start by …
Applying SOLID coding practices and following TDD to build out clean loosely couple code, we automate our builds and run code quality checks with every build to maintain our clean code, we write tons of tests and these are tests written mostly by the developers and not a testing team that is using a very expensive testing tool. We continuously integrate our code, using only the main branch and checking in code multiple times per day and per hour. We automate our database scripts and constantly deploy the application onto our different environments up to test or stage and finally we automate our environments to reach a stage or continuous delivery.
These are all the technical components of Agile Engineering and DevOps that help us ensure that we are building the thing right by constantly delivery working software that is fully tested and production ready.
We know that we’ve built the thing right – already in production, no website crashes, we’ve updated x number of times since we delivered it. But, how do we know we built the right thing?
Understand what people need
Address the whole experience, from start to finish
Make it simple and intuitive
Build the service using agile and iterative practices
Structure budgets and contracts to support delivery
Assign one leader and hold that person accountable
Bring in experienced teams
Choose a modern technology stack
Deploy in a flexible hosting environment
Automate testing and deployments
Manage security and privacy through reusable processes
Use data to drive decisions
Default to open
That is, we will use Lean Discovery to ensure we are building the right thing, and Agile Delivery to ensure we are building the thing right.