Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Scaling Scrum: What Big Players can learn from StartUps

When big players start introducting agile & lean, this is often seen as an software development issue. The huge potential to gain speed, efficience, flexibility and fun is left out for all sorts of reasons. Time for radical change!
by

Frank Janisch

on 13 June 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Scaling Scrum: What Big Players can learn from StartUps

About us
Myths
Reality
Big Player Reality
About me
Losing CONTROL?
Scalability in Software Architecture
-> Loose Coupling <-
Scalability in Organisations Architecture
Frank Janisch
Dipl.-Inform
42
married, two kids
1/2 year Novedia
7 years (VW-)gedas
8 years ImmobilienScout24
1 year CTO crealytics
5 weeks b!g consulting
have seen software development from different angles
...work day, night and weekends
Startup Guys...
...have no life and love outside their company
CONSTRAINTS!
Competition
Low Budget
Full Responsibility
for success and failure
OWNERSHIP
of everything
Low Experience
...just let go
What Big Players can learn from StartUps
Agile
Lean
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Principles behind the Agile Manifesto



We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity--the art of maximizing the amount
of work not done--is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
Agile Manifesto
Eliminate Waste
Build Quality In
Create Knowledge
Defer Commitment
Deliver Fast
Respect People
Optimise the Whole
10 years
>50 years
Transport (moving products that are not actually required to perform the processing)
Inventory (all components, work in process and finished product not being processed)
Motion (people or equipment moving more than required to perform the processing)
Waiting (waiting for the next production step)
Overproduction (production ahead of demand)
Over Processing (resulting from poor tool or product design creating activity)
Defects (the effort involved in inspecting for and fixing defects)
Startup
Background
Q&A
push to pull
Delegate Responsibility
...don't delegate work
Start small
...found your own startup
...offer a service
frank.janisch@borisgloger.com
budget
one great idea
a handful of great, dedicated people
small amount of funding
loads of trust
unlimited freedom
Ingredients
progress
Further Reading
Release the Breaks
don't force teams into the infrastructure harness
let teams pull
offer a choice
support communities - networks of experts
share a vision
define a budget
make expectations clear
let go
operational
tactical
strategic
transparency replaces control
pull information any time
burn rate
forecast
cost overview
story backlog
release plan
estimates
product/epic burndown
impediments list
review and retro outcome
business KPIs
Dunbars number
high level priorisation
market feedback
pivot or persevere
Summary
small fully independent "companies"
purpose
limited resources
full responsibility
full ownership
be bold!
Spot the Difference
SSD für Buildserver
startup way
big players way
-120€ developer buys SSD at local superstore
-150€ 4h developer - roundtrip to store and install SSD
+30€/day 1% speedup of 10 person team after 1 day
amortisation after 10 days
-10€ developer enters order in order system
-2 offers requested (1day)
training for oder system
-5€ developer chooses offer
-5€ procurement approves offer (1day)
-5€ convert offer to shopping basket
-10€ management approves order
- delivery (2 days)
-75€ 2h developer installs SSD
-100€ SSD cost
+30€/day 1% speedup of 10 person team after 5 days
amortisation after 13 days
Scalabilty
150
Conways Law
"Wir wollen mit unserer Arbeit etwas bewegen. Vor allem wollen wir Menschen Mut machen, selbst etwas bewegen zu wollen. Mein Team und mich treibt die Hoffnung an: Dass Menschen nach der Arbeit nicht fix und fertig, sondern mit einem Lächeln nachhause gehen. Dass sie Zeit für ihre Familien und Spaß haben können, mit dem guten Gefühl, etwas geschafft zu haben." Boris Gloger
Full transcript