The document discusses embracing change through an agile approach to software development. It outlines some traditional software development approaches and their limitations in handling change. It then introduces agile methodologies which embrace change through short iterative development cycles, frequent stakeholder feedback, and flexibility. The document provides examples of how agile practices like sprints, daily stand-ups, and product backlogs can help teams adapt to changing requirements and deliver working software more frequently.
A Behavioral Interpretation of Resilience and AntifragilityVincenzo De Florio
In this presentation I discuss resilience and antifragility as behaviors resulting from the coupling of a system and its environment(s). Depending on the interactions between these two "ends" and on the quality of the individual behaviors that they may exercise, different strategies may be chosen: elasticity (change masking); entelechism (change tolerance); and antifragility (adapting to & learning from change). When the environment is very simple and only capable of so-called "random behavior", often the only effective strategy towards resilience is off-line dimensioning of redundancy as a result of a worst-case assessment of disturbances and/or threats. Much more complex and variegated is the case when both systems and environments are "intelligent" -- or at least able to exercise complex teleological and extrapolatory behaviors. In this case both system and ambient may choose among a variety of strategies in what could be regarded as a complex evolutionary game theory setting.
U.S. INTELLECTUAL PROPERTY
ENFORCEMENT COORDINATOR
ANNUAL REPORT ON
INTELLECTUAL PROPERTY
ENFORCEMENT
COVER TITLE HERE
FEBRUARY 2 01 2
CONSUMER DATA PRIVACY
IN A NETWORKED WORLD:
A FRAMEWORK FOR PROTECTING
PRIVACY AND PROMOTING INNOVATION
IN THE GLOBAL DIGITAL ECONOMY
A behavioural model for the discussion of resilience, elasticity, and antifra...Vincenzo De Florio
Resilience is one of those "general systems attributes" that appear to play a central role in several disciplines - including ecology, business, psychology, industrial safety, microeconomics, computer networks, security, management science, cybernetics, control theory, crisis and disaster management. Resilience thus seems to be "needed" everywhere; and yet, even in the framework of a same discipline, it is not easy to define it precisely and consensually. To add to the confusion, other terms such as elasticity, change tolerance, and antifragility, although clearly related to resilience, cannot be easily differentiated.
In this talk I tackle this problem by introducing a behavioural model of resilience. I interpret resilience as the property emerging from the interaction of the behaviours produced by two "players": a system and a hosting environment. The outcome of said interaction depends on both intrinsic and extrinsic factors, including the systemic "traits" of the system but also how the system's endowment matches the requirements expressed by the behaviours of the environment. I show how the behavioural approach provides a unifying framework within which it is possible to express coherent definitions for elasticity, change tolerance, and antifragility.
A Behavioral Interpretation of Resilience and AntifragilityVincenzo De Florio
In this presentation I discuss resilience and antifragility as behaviors resulting from the coupling of a system and its environment(s). Depending on the interactions between these two "ends" and on the quality of the individual behaviors that they may exercise, different strategies may be chosen: elasticity (change masking); entelechism (change tolerance); and antifragility (adapting to & learning from change). When the environment is very simple and only capable of so-called "random behavior", often the only effective strategy towards resilience is off-line dimensioning of redundancy as a result of a worst-case assessment of disturbances and/or threats. Much more complex and variegated is the case when both systems and environments are "intelligent" -- or at least able to exercise complex teleological and extrapolatory behaviors. In this case both system and ambient may choose among a variety of strategies in what could be regarded as a complex evolutionary game theory setting.
U.S. INTELLECTUAL PROPERTY
ENFORCEMENT COORDINATOR
ANNUAL REPORT ON
INTELLECTUAL PROPERTY
ENFORCEMENT
COVER TITLE HERE
FEBRUARY 2 01 2
CONSUMER DATA PRIVACY
IN A NETWORKED WORLD:
A FRAMEWORK FOR PROTECTING
PRIVACY AND PROMOTING INNOVATION
IN THE GLOBAL DIGITAL ECONOMY
A behavioural model for the discussion of resilience, elasticity, and antifra...Vincenzo De Florio
Resilience is one of those "general systems attributes" that appear to play a central role in several disciplines - including ecology, business, psychology, industrial safety, microeconomics, computer networks, security, management science, cybernetics, control theory, crisis and disaster management. Resilience thus seems to be "needed" everywhere; and yet, even in the framework of a same discipline, it is not easy to define it precisely and consensually. To add to the confusion, other terms such as elasticity, change tolerance, and antifragility, although clearly related to resilience, cannot be easily differentiated.
In this talk I tackle this problem by introducing a behavioural model of resilience. I interpret resilience as the property emerging from the interaction of the behaviours produced by two "players": a system and a hosting environment. The outcome of said interaction depends on both intrinsic and extrinsic factors, including the systemic "traits" of the system but also how the system's endowment matches the requirements expressed by the behaviours of the environment. I show how the behavioural approach provides a unifying framework within which it is possible to express coherent definitions for elasticity, change tolerance, and antifragility.
Change is inevitable and can cause fear of the unknown. But it doesn't have to—we can learn to master change and adapt to it quickly. These 5 tips will help you successfully cope with changes at work.
Choosing the right Agile innovation practices: Scrum vs Kanban vs Lean Startu...JAX London
Innovation can be a tricky thing: Not only does it means different things to different people, but creating a brand-new product requires different practices compared to updating an existing one. Some people claim that Scrum is best for innovation, some say Kanban, and others believe it's Lean Startup. If you want to understand better when to choose which agile method, then this talk is for you. The session introduces three innovation stages and explains how the process model and key practices are influenced by the amount of uncertainty present.
Change is inevitable and can cause fear of the unknown. But it doesn't have to—we can learn to master change and adapt to it quickly. These 5 tips will help you successfully cope with changes at work.
Choosing the right Agile innovation practices: Scrum vs Kanban vs Lean Startu...JAX London
Innovation can be a tricky thing: Not only does it means different things to different people, but creating a brand-new product requires different practices compared to updating an existing one. Some people claim that Scrum is best for innovation, some say Kanban, and others believe it's Lean Startup. If you want to understand better when to choose which agile method, then this talk is for you. The session introduces three innovation stages and explains how the process model and key practices are influenced by the amount of uncertainty present.
Introduction to Scrum presentation which outlines common issues in software development, what is Scrum, and an introduction to the Scrum framework. This presentation has been used for training and presentations to both technology and business audiences.
The aim of this presentation is to provide a brief overview of the SCRUM Agile Methodology, and to give organizations an idea of how SCRUM may affect the traditional development of requirements and deliverables.
26. Agile references (web sites)
Overview of Agile development -
http://www.versionone.com/Agile101/Agile_Development.asp
The Agile Manifesto –
http://www.agilemanifesto.org/
The Agile Alliance –
http://agilealliance.org/
The Scrum Alliance –
http://scrumalliance.org/
Agile Project Leadership Network (APLN) Houston chapter –
http://www.aplnhouston.org/
• You can also Google topics like Agile, Scrum, etc.
• There are also apps for iPhone, Android such as planning poker
27. Agile references (books)
“Agile Project Management with Scrum”
Ken Schwaber
“The Software Project Manager’s Bridge to Agility”
Michele Sliger
“Agile Project Management: Creating Innovative Products “
Jim Highsmith
“Succeeding With Agile: Software Development Using Scrum”
“Agile Estimating and Planning”
“User Stories Applied: For Agile Software Development”
Mike Cohn
“Agile Retrospectives: Making Good Teams Great”
Esther Derby, Diana Larsen, and Ken Schwaber
How PMs would like to control change on a project - change not likely, or change-proof the project!
How PMs would like to control change on a project - change not likely, or change-proof the project!
Change occurs (or threatens) through all stages of project – how to manage?
How we currently “manage” - Change processes, request forms, Impact assessments, approvals, add up to delays
Replace command and control mindset – with one of inspect and adapt
Agile was born out of software development industry based on difficult challenges including: getting your new software out before competitor does, making yours redundant or obsolete, and constant change due to internal/external factors such as not knowing exactly what the end result should look like, and what is happening in marketplace
Team is self-organizing around planning and executing work using guidelines and priorities (servant leadership) – they are not handed “tasks” to accomplish according to schedule.Customer should be engaged all during project instead of just start and endProgress (or lack of it) is made visible to everyone (no hiding or guessing % done) – post “burndown” charts showing work done/not doneEstimation done at high level initially to relatively “size” project effort without detailed estimation process (using story points, planning poker)Waste - Really just maximizes “work not done” (Standish CHAOS report)Would not deliver most of the Never and Rarely used featuresPlanning occurs at start, and at key events throughout project instead of all upfront
Team is self-organizing around planning and executing work using guidelines and priorities (servant leadership) – they are not handed “tasks” to accomplish according to schedule.Customer should be engaged all during project instead of just start and endProgress (or lack of it) is made visible to everyone (no hiding or guessing % done) – post “burndown” charts showing work done/not doneEstimation done at high level initially to relatively “size” project effort without detailed estimation process (using story points, planning poker)Waste - Really just maximizes “work not done” (Standish CHAOS report)Would not deliver most of the Never and Rarely used featuresPlanning occurs at start, and at key events throughout project instead of all upfront
Team is self-organizing around planning and executing work using guidelines and priorities (servant leadership) – they are not handed “tasks” to accomplish according to schedule.Customer should be engaged all during project instead of just start and endProgress (or lack of it) is made visible to everyone (no hiding or guessing % done) – post “burndown” charts showing work done/not doneEstimation done at high level initially to relatively “size” project effort without detailed estimation process (using story points, planning poker)Waste - Really just maximizes “work not done” (Standish CHAOS report)Would not deliver most of the Never and Rarely used featuresPlanning occurs at start, and at key events throughout project instead of all upfront
Team is self-organizing around planning and executing work using guidelines and priorities (servant leadership) – they are not handed “tasks” to accomplish according to schedule.Customer should be engaged all during project instead of just start and endProgress (or lack of it) is made visible to everyone (no hiding or guessing % done) – post “burndown” charts showing work done/not doneEstimation done at high level initially to relatively “size” project effort without detailed estimation process (using story points, planning poker)Waste - Really just maximizes “work not done” (Standish CHAOS report)Would not deliver most of the Never and Rarely used featuresPlanning occurs at start, and at key events throughout project instead of all upfront
Scrum is most well known and widely used, though there are many others which share many of the key aspects
Scrum is most well known and widely used, though there are many others which share many of the key aspects
Briefly describe roles
Product backlog – user stories on Post-Its or 3x5 cards (As a <> I would like to <> so that <>); use story points, planning poker to gauge relative size (time/cost) of project without detailed planning; product owner will prioritize Sprint planning – team plans work for next phase using priorities, feedback from retrospective, velocity for next sprint, etc.
When are we done? When owner says we are, not necessary at end of “schedule” or budget. Remember – maximize work not being done!
When are we done? When owner says we are, not necessary at end of “schedule” or budget. Remember – maximize work not being done!
How does this incorporate change?
Change only permitted at beginning of new sprint planning session. IF forced during Sprint, cancel Sprint, and re-plan a new Sprint instead of continuing current one.
Classic (“safe” projects) vs. Agile (“uncertainty” and changing projects) drivers
Cultural change – “not your father’s PM” – overcoming bias for traditionAcceptance of self-organizing team leadership, not PMTeam takes ownership of assignments, problem solving and is held accountable/visiblePlanning approach is tiered high level, then “just enough” detailed to keep movingDocumentation can be done as work is completed to capture what was done, not what should have been done before you start
Winds of change always blowing – use your creativity and imagination to find ways to use Agile in non-software projects – where appropriate