InfraXstructure: Mirosław Dąbrowski "Zmiany w organizacji a gotowość na metodyki zwinne"
1. Mirosław Dąbrowski
infraXstructure, 20.04.2016, Warszawa
In two categories:
• Best DSDM/AgilePM team in the world
• Outstanding contribution to promoting DSDM methods
„Zmiany w organizacji a
gotowość na metodyki
zwinne”
2. Dlaczego projekty nie udają się?
Other
1%
Lack of Qualified
Resources
3%
Communication
Problems
14%
Inadequate Risk
Management
17%
Poor Scope Definition
15%
Poor Requirements
Definition
50%
Other
Lack of Qualified Resources
Communication Problems
Inadequate Risk Management
Poor Scope Definition
Poor Requirements Definition
ESI International survey of 2000
business professionals, 2005
4. Chaos Resolution by Agile vs Waterfall (2015)
Size Method Successful Challenged Failed
All Size Projects
Agile 39% 52% 9%
Waterfall 11% 60% 29%
Large Size
Projects
Agile 18% 59% 23%
Waterfall 3% 55% 42%
Medium Size
Projects
Agile 27% 62% 11%
Waterfall 7% 62% 25%
Small Size
Projects
Agile 58% 38% 4%
Waterfall 44% 45% 11%
The resolution of all software projects from FY2011-2015 within the new CHAOS database segmented
by the agile process and waterfall method. The total number of software projects is over 10.000
5. “Wytwarzając oprogramowanie i pomagając innym w tym zakresie,
odkrywamy lepsze sposoby wykonywania tej pracy.”
Agile
(empiryczny model procesu)
Tradycyjne
(deterministyczny model procesu)
Ludzie i interakcje ponad procesy i narzędzia
Działające oprogramowanie ponad obszerną dokumentację
Współpracę z klientem ponad formalne ustalenia
Reagowanie na zmiany ponad podążanie za planem
Powrót do podstaw…
6. Plan-Driven Projects vs Change-driven Project
Waterfall Agile
Wartość biznesowa
czas
czas czas
czas
Możliwość zmiany
Ryzyko
(nieodpowiedniego produktu)
Zaangażowanie klienta/biznesu
7. PART 1 – REDUCING WASTE AND PROJECT
FAILURE, AND STIMULATING ECONOMIC GROWTH
12. Government will ensure that technology
requirements are considered earlier in the
policymaking process. This approach will be
supported by the application of lean and agile
methodologies that will reduce waste, be more
responsive to changing requirements and reduce the
risk of project failure.
13. Where possible, government will move away from
large ICT projects that are slow to implement or pose
a greater risk of failure. Additionally, the application of
agile ICT delivery methods, combined with the newly
established Major Projects Authority, will improve
government’s capability to deliver projects
successfully and realise benefits faster.
UK Government ICT Strategy / Marzec 2011
https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/85968/uk-government-government-ict-strategy_0.pdf
9. Lekkie oraz pełniejsze metody zwinne
AGILEScrum Nexus
Scrum-of-Scrums
Evidence-Based Management (EBMgt)
Scrum at Scale (Scrum@Scale)
PRINCE2 Agile (P2A)
Large-scale Scrum (LeSS) / LeSS Huge
Scaled Agile Framework (SAFe)
Disciplined Agile Delivery (DAD)
Enterprise Transition Framework (ETF)
Agile Programme Management (AgilePgM)
Agile Project Management (AgilePM)
Dynamic Systems Development Method (DSDM)
Agile Unified Process (AUP)
Open Unified Process (OpenUP)
Crystal Clear
…
Scrum
Lean software development
Kanban (process + method)
Extreme Programming (XP)
Continuous Integration (CI)
Continuous Delivery (CD)
Feature Driven development (FDD)
Test Driven Development (TDD)
Acceptance Test Driven Development (ATDD)
Crystal Clear
…
Pełniejsze metody (ponad 1 zespół)Lekkie metody
10. Pozycjonowanie metod zwinnych
Portfel
Inwestycyjny
Program
Projekt
Zespół
Wytwarzanie
AgilePM
Scrum
Non Agile
(just for
comparison)
AgilePgM
Disciplined
Agile
Delivery
(DAD) ScaledAgileFramework(SAFe)
Management
of Portfolios
(MoP)
Managing
Successful
Programmes
(MSP)
Large-Scale
Scrum(LeSS)
Large-Scale
Scrum(LeSS)
Huge
Scrum@Scale
Lean Software Development / eXtreme Programming (XP) / Regular Refactoring / Document late /
Pair programming / Sharing Codebase / Coding standards / Test Driven Development (TDD) /
Feature Driven Development (FDD) / Behavior Driven Development (BDD) / Continuous Testing
(CT) / Continuous Integration (CI) / Continuous Delivery (CD) / Continuous Deployment (CD) /
DevOps / Rugged DevOps …
DSDM
AgilePF
AgileBA
PRINCE2
ScrumNexus
Kanban
ScrumBan
PRINCE2
Agile
11. Narzędzia do badania kondycji projektów zwinnych
DSDM/AgilePM Project Health Check Questionnaire by Mirosław Dąbrowski
Squad Health Check Model By Spotify
Agile and Lean Forrester’s assessment framework by Forrester
Evidence Based Management (EBM) by Ken Schwaber
Agile Realized Benefits & Improvements (AgileRBI) by DavisBase Consulting
Comparative Agility by Cohn
Scaled Agile Framework assessments by Dean Leffingwell
SAFe Release Train Health Assessment AgilityHealth
SAFe Portfolio Health Assessment AgilityHealth
Agile Adoption Index by Ahmed Sidky
Agile Journey Index (AJI) by AgileBill Krebs
XP Evaluation Framework (XP:EF) by AgileBill Krebs, Laurie Williams
Agile Coach Health Assessment by Agile Transformation Inc.
TeamHealth Retrospective Assessment by Agile Transformation Inc.
12. Metryki w celu zrozumienia (nie oceny)
Agile Coach Health Radar Agile Team Health
14. Ludzie
In the title, [of his article] I refer to people as
"components". That is how people are
treated in the process / methodology design
literature. The mistake in this approach is
that "people" are highly variable and non-
linear, with unique success and failure
modes. Those factors are first-order, not
negligible factors […]
Alistair Cockburn
First-Order Components in Software Development
15. Zrozumieć ludzi…
Myers-Briggs Type
Indicator (MBTI)
Five Factor Model
(FFM)
DISC Assessment
Thomas Personal
Profile Analysis (PPA)
FIRO theory LIFO Method
Social Style Model INSIGHTSBalbin Roles
Gallup Q12 employee
engagement survey
Tuckman model
Douglas McGregor XY
Theory
Virginia Satir’s Model
Maslow’s Hierarchy of
Needs
The Gestalt Cycle
Strengths Finder
Strength Inventory
Model (SDI)
Strong Interest
Inventory (SII)
Country Navigator
Uncertainty Avoidance
Index
Holland Hexagon