agile in non software non-software settings

Agile inAgile inNonNon SoftwareSoftwareNonNon--SoftwareSoftwareSettingsSettings

Hillel GlazerHillel Glazer

4/4/2011©2011 Entinex, Inc. | All rights reserved. No reproduction without prior approval. 1

AgendaAgendaAgendaAgenda

08:45-09:00 Welcome08:45 09:00 Welcome

09:00-10:00 Introduction and Foundation

10:00-11:00 Fundamentals of Agile Development and Management

11:00-11:15 Coffee Break

11:15-12:00 Agile Management challenges for non-sw products

12:00-12:45 Agile Development challenges for non-sw products

12:45-13:45 Lunch Break

13:45-14:30 Agile Engineering and Technical Debt13:45-14:30 Agile, Engineering, and Technical Debt

14:30-15:15 Real Options, Systems, and Agility

15:15-15:30 Refreshments

15:30-16:15 Enterprise and Architecture Considerations

16:15-16:45 Case study presentation

16:45-17:15 Q&A


Introduction and FoundationIntroduction and FoundationIntroduction and FoundationIntroduction and Foundation

Expectations

What do you believe is “agile”?What do you believe is agile ?

What do you believe is NOT “agile”?What do you believe is NOT agile ?

T th d M th b t A il Truths and Myths about Agile

Manifesto

Principles4/4/2011©2011 Entinex, Inc. | All rights reserved. No reproduction without prior approval. 3

ExpectationsExpectationsExpectationsExpectations

The discussion is more valuable than the slides Format

Introduce a topicp

Collect thoughts from youo oug o you

Discuss your thoughts Discuss your thoughts

Share my thoughts Share my thoughts

What are your expectations?What are your expectations?



Expectations




Manifesto


What do you believe is What do you believe is “agile”?“agile”?What do you believe is What do you believe is agile ?agile ?



Expectations




Manifesto


What do you believe is NOT What do you believe is NOT “agile”?“agile”?



Expectations




Manifesto


Truths and Myths about AgileTruths and Myths about AgileTruths and Myths about AgileTruths and Myths about Agile Agile doesn’t allow

documentation Agile is a solution to

bureaucracydocumentation Agile methods do not

scale

bureaucracy Agile doesn’t need up

front designscale Agile means no plan TDD covers all the unit

front designWe're doing scrum so

we don’t need to do TDD Refactoring Pairtesting needs

Pair programming always results in better code

TDD, Refactoring Pair Programming, etc.

One can learn Agileresults in better code Agile is a silver bullet

solution to software

One can learn Agile from a book

Agile only works for t i i l j tengineering problems

Doing agile practices means we’re agile

trivial projects Agile only uses “User

Stories”means we re agile Stories


Truths and Myths about AgileTruths and Myths about AgileTruths and Myths about AgileTruths and Myths about Agile Agile requires discipline Agile is more about culture

Visibility Communication Agile is more about culture

than anything else Adding agile to a wasteful

process does not make it an

Communication Iterations Increments Slicesprocess does not make it an

agile process Bad processes cannot be made

better with Agile

Slices Proximity of customer/user Highly focused on customer

valueg

Agile is a broad response to a specific set of issues affecting the software community in the late 1990’s early 2000’s

value High premium of delivering

visible value early and frequentlylate 1990’s early 2000’s

The only agreed-upon set of anything agile is the Agile Manifesto

frequently Brutally critical of

features/requirements/ specifications w.r.t. valueManifesto

“Confront people with reality.” (Jim Benson)

specifications w.r.t. value Heavy use of demonstrations When done correctly, generates

tons of datatons of data



Expectations




Manifesto


Manifesto for Manifesto for Manifesto for Manifesto for Agile Agile Software DevelopmentSoftware Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and toolsIndividuals and interactions over processes and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationCustomer collaboration over contract negotiationResponding to change over following a plan

That is, while there is value in the items on the right, l th it th l ftwe value the items on the left more.



Expectations




Manifesto


We follow these principlesWe follow these principles: (: (11))We follow these principlesWe follow these principles: (: (11))Our highest priority is to satisfy the customer through

l d ti d li f l bl ftearly and continuous delivery of valuable software.Welcome changing requirements, even late in

development Agile processes harness change for thedevelopment. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently from a couple of 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 t st them to get the job donetrust them to get the job done.


We follow these principlesWe follow these principles: (: (22))We follow these principlesWe follow these principles: (: (22)) The most efficient and effective method of conveying

information to and within a development team is face-to-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.maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicit the a t of ma imi ing the amo nt of o k not Simplicity-the art of maximizing the amount of work not done-is essential.

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

At regular intervals, the team reflects on how to become more effective then tunes and adjusts its behaviormore effective, then tunes and adjusts its behavior accordingly.



08:45-09:00 Welcome08:45 09:00 Welcome












16:45-17:15 Q&A


Fundamentals Fundamentals of Agile of Agile DevelopmentDevelopment

Extreme Programming (XP) (Kent Beck) Fine scale feedback Fine scale feedback

Test Driven Development via Programmer Tests and Customer Tests (were Unit Tests & Acceptance Tests)

Planning Gameh l ( ) Whole Team (was Onsite Customer)

Pair Programming Continuous process rather than batch

Continuous Integration Continuous Integration Design Improvement (was Refactor Mercilessly) Small Releases

Shared understanding Shared understanding Simple Design (Do Simple Things, You Aren’t Gonna Need It, Once And Only

Once, Simplify Vigorously) System Metaphor

C ll C d O h Collective Code Ownership Coding Standard or Coding Conventions

Programmer welfare Sustainable Pace (original name: Forty Hour Week) Sustainable Pace (original name: Forty Hour Week)


Fundamentals of Agile Fundamentals of Agile DevelopmentDevelopmentCrystal Clear (Alistair Cockburn) Frequent DeliveryReflective ImprovementReflective ImprovementOsmotic Communication

Personal Safety F Focus Easy Access to Expert Users A Technical Environment with Automated Tests,

Configuration Management, and Frequent Integration


Fundamentals of Agile Fundamentals of Agile DevelopmentDevelopment Collective Code Ownership

Continuous Integration Continuous Integration

Pair Programming Pair Programming

T t D i D l t Test-Driven Development

Increments

Demos4/4/2011©2011 Entinex, Inc. | All rights reserved. No reproduction without prior approval. 20

Fundamentals of Agile Fundamentals of Agile ManagementManagement

Declaration of Interdependence W it f j t l d th t hi hl We are a community of project leaders that are highly

successful at delivering results. To achieve these results: We increase return on investment by making continuous y g

flow of value our focus. We deliver reliable results by engaging customers in

frequent interactions and shared ownership. q p We expect uncertainty and manage for it through

iterations, anticipation, and adaptation. We unleash creativity and innovation by recognizing that We unleash creativity and innovation by recognizing that

individuals are the ultimate source of value, and creating an environment where they can make a difference.

We boost performance through group accountability for We boost performance through group accountability for results and shared responsibility for team effectiveness.

We improve effectiveness and reliability through situationally specific strategies processes and practicessituationally specific strategies, processes and practices.


Fundamentals of Agile Fundamentals of Agile ManagementManagement Scrum Retrospectives Planning Game/Poker Estimation Planning Game/Poker Estimation Burn-down Backlogs Backlogs Time-boxes or Continuous Flow It ti Iterations User stories Acceptance Criteria Kanban



08:45-09:00 Welcome08:45 09:00 Welcome












16:45-17:15 Q&A



08:45-09:00 Welcome08:45 09:00 Welcome












16:45-17:15 Q&A


Agile Management Agile Management Challenges Challenges & & OpportunitiesOpportunities Your input Planning & Budgeting Estimation Estimation Proximity Project size Project size Team size C i ti Communication Project risk Proximity of customer/user


Agile Management Agile Management Challenges & OpportunitiesChallenges & OpportunitiesWhat can we nonetheless learn from agile in non-SW

management/systems engineering?

Are traditional budget and planning expectations always really required?y y q

List: List:



08:45-09:00 Welcome08:45 09:00 Welcome












16:45-17:15 Q&A


Agile Agile DevelopmentDevelopmentChallenges & OpportunitiesChallenges & Opportunities Your input

TDD? TDD?

Pairs? Pairs?

P d t l it Product complexity

Product risk

Diminished role of architecture4/4/2011©2011 Entinex, Inc. | All rights reserved. No reproduction without prior approval. 28

Agile Agile DevelopmentDevelopmentChallenges & OpportunitiesChallenges & OpportunitiesWhat can we nonetheless learn from agile in non-SW

development/systems engineering?

Are traditional engineering approaches always the solution?

List: List:



08:45-09:00 Welcome08:45 09:00 Welcome












16:45-17:15 Q&A



08:45-09:00 Welcome08:45 09:00 Welcome












16:45-17:15 Q&A


Agile & EngineeringAgile & EngineeringAgile & EngineeringAgile & Engineering

Iterations and Increments are just Systems Engineering

The classic systems engineering life cycle is still alive and well in agile development.g p It’s just not the entire product going through the pipe

all at once. More like “modular” production.

However, too many “agile” proponents don’t know the first thing about engineering. The experienced g g g pexperts do, but they’re not the norm.


Technical Debt (Technical Debt (11))Technical Debt (Technical Debt (11))

The nature of technical debt The money required to pay back in order to fix quality

defects in the product. Quantitative measure of how well/poorly done,

expressed in financial terms of debt required to bring th d t t h it d t bthe product up to where it was supposed to be.

Complexity adds to technical debt; rule exceptions add; Short cuts add;add; Short-cuts add;

Technical debt is incurred when the “right way” to do something is deferredsomething is deferred.

Product decay Interest accumulates on unpaid debt Interest accumulates on unpaid debt.


Technical Debt (Technical Debt (22))Technical Debt (Technical Debt (22))

Tactical and strategic effects of technical debt Debt becomes a business decision at the highest

levels of the organization.

How the technical debt metric enables you to ycommunicate across levels and functions Like Russian dolls :: Debt accumulation is nested, from

the outside is seen as a total, and inside is further granularity.


Technical Debt (Technical Debt (33))Technical Debt (Technical Debt (33)) Toxic Code (product) and Net Present Value

Si il t t i t t th t l t it l Similar to toxic assets: an asset that lost its value How much you intend to make on the product, but reduced by

the cost of the debt The atrocious nature of code (product) with a high Error

Feedback Ratio While diffusing one mine you could be stepping on another While diffusing one mine, you could be stepping on another Working on reducing technical debt vs. working on actual bugs When working on reducing technical debt you're not working on

t l b d th t it t i t f th d btactual bugs and the opportunity cost is part of the debt. You're also likely to be introducing new bugs as you're working

on technical debt High technical debt products need a lot of attention, they can't be

leveraged as easily, or packaged and modularized to the cloud, mobile, or social networks.


Technical Debt (Technical Debt (44))Technical Debt (Technical Debt (44)) Cyclomatic complexity as a predictor of error-

proneness Higher-complexity == more technical debt

U f h t i d i t h i l d bt Use of heat maps in reducing technical debt Used for prioritization of mountain of debt.

U f d it f t h i l d bt i k i di t Use of density of technical debt as a risk indicator Using technical debt as a means of illuminating risks.

How and when to use technical debt to ‘stop the line’ How and when to use technical debt to ‘stop-the-line’ When continuously measuring the technical debt,

recognize when it's time to “stop the line” and reducerecognize when it s time to stop the line and reduce the debt rather than continue to build more product on top of the debt you've already generated.

Use technical debt in governing development.4/4/2011©2011 Entinex, Inc. | All rights reserved. No reproduction without prior approval. 36

Technical Debt (Technical Debt (55))Technical Debt (Technical Debt (55))3 Measures related to Technical Debt:

1. Quality of the product ( $ 0 h l d b / OC)(BAD = >$10 technical debt/LOC)

2. Production/delivery volume

3. Value, NPV, revenue stream

Concept Credit: Israel Gat, th il tiwww. theagileexecutive.com



08:45-09:00 Welcome08:45 09:00 Welcome












16:45-17:15 Q&A


Real Real Options, Systems, and Options, Systems, and Real Real Options, Systems, and Options, Systems, and AgilityAgility Real Options:

Last responsible moment Uses ranges

Recognize specifications and design masquerading as i trequirements

Mi i M k t bl F t ( )Minimum Marketable Feature(s)

L & S t Thi ki Lean & Systems Thinking

A ili i d l i Agility as a mindset, not a solution4/4/2011©2011 Entinex, Inc. | All rights reserved. No reproduction without prior approval. 39


08:45-09:00 Welcome08:45 09:00 Welcome












16:45-17:15 Q&A



08:45-09:00 Welcome08:45 09:00 Welcome












16:45-17:15 Q&A


Enterprise and Architecture Enterprise and Architecture ConsiderationsConsiderations Architectural decisions often take a complete system

view which prevents slices of delivery. Also, prescribed architecture often unnecessarily

drives more technical decisions beyond where it's useful to be driven at a given point in time.

hi i f i f i d i Architecture is too often getting to far into design. Lack of familiarity with the actual product (code

base) allows the software architect to hold fast to a specific design when doing so isn't in the best i t t f th d tinterest of the product.

Enterprise Architecture plays a value-role, but often bl d i t ft hit t i h l f lbleeds into software architecture in an unhelpful way.



08:45-09:00 Welcome08:45 09:00 Welcome












16:45-17:15 Q&A



08:45-09:00 Welcome08:45 09:00 Welcome












16:45-17:15 Q&A


agile in non software non-software settings

Documents